PRD — Quorum + Health + Seed + Immune Layers

Document Status

Draft V1

Purpose

This PRD defines the V1 requirements for the core resilience and governance subsystems in Cambium: - Quorum — governed action and threshold decisions - Health (homeostasis, stress detection, and regulation - Seed)— checkpoints, replay, rollback, and recovery - Immune (anomaly signals, trust events, and protective response hooks)

These are grouped together because they form the difference between a workflow engine and an actual orchestration platform.

Hypha can run work. These layers decide when work is safe, healthy, recoverable, and acceptable to continue.

Product Summary

Cambium V1 should not only execute workflows. It should also: - know when a workflow needs approval - know when the system is under stress - know how to recover from failure - know when behavior s abnormal enough to pause or escalate

That is what these subsystems provide.

Together, they move Cambium away from simple automation and toward governed, resilient orchestration.

Problem

Most orchestration systems treat these concerns as afterthoughts: - governance is bolted on through manual review hacks - health is reduced to infrastructure metrics only - recovery means “rerun it and pray” - anomaly detection is externalized or ignored

That approach does not hold up when autonomous systems become more capable, more connected, and more expensive.

Cambium needs first-class systems for: - threshold-based approval - stress-aware behavior - checkpointed recovery - anomaly-aware intervention

Goals

Product goals

1. Prevent sensitive actions from executing without appropriate governance.
2. Detect unhealthy operating conditions and trigger adaptive response.
3. Allow failed or interrupted runs to recover without starting from scratch every time.
4. Detect abnormal behavior early enough to pause or escalate before damage spreads.

System goals

1. Make Quorum, Health, Seed, and Immune consume the same underlying event and state model.
2. Ensure all major interventions are auditable.
3. Keep these layers powerful enough to matter but scoped enough to ship in V1.

Non-Goals

This PRD does not require V1 to ship: - fully autonomous fraud defense across all integrations - advanced machine-learned anomaly scoring from day one - distributed consensus protocols beyond practical threshold gating - infinitely granular health simulations - full rewind of every side effect in every integration

We need real capability, not science-fair overreach.

Section A — Quorum

Purpose

Quorum governs sensitive actions through threshold-based decision policies.

It answers questions like: - should this action proceed automatically? - does this require approval? - does this require multiple signals or reviewers? - should this action be denied or escalated?

Quorum Goals

1. Classify actions by sensitivity or policy class.
2. Require approvals for protected actions.
3. Record decisions and their basis.
4. Expose pending approvals clearly to operators.
5. Integrate directly with Hypha execution flow.

Quorum User Stories

• As a platform operator, I can define policies that mark certain actions as requiring approval.
• As a reviewer, I can see pending approvals with context.
• As a reviewer, I can approve, reject, or escalate a pending action.
• As the runtime, I can block execution until a quorum decision is reached.
• As an auditor, I can inspect why a decision was made.

Quorum Functional Requirements

Policy model

• Policies can be attached to workflows, nodes, or action classes.
• Policies can specify approval requirements.
• Policies can specify escalation behavior.
• Policies can specify rejection behavior.

Approval model

• Actions can enter a pending approval state.
• Pending actions expose relevant context for review.
• Authorized reviewers can approve, reject, or escalate.
• Decisions are durable and auditable.
• The runtime can continue, fail, or reroute based on the decision result.

Decision record model

Each decision record should include: - action type - run/task context - triggering policy - current decision status - participants or signals involved - final outcome - timestamps

Quorum V1 Scope

Include: - threshold gate support - single-approver and multi-approver patterns - explicit approve / reject / escalate actions - decision record storage - UI visibility of pending and resolved approvals

Defer: - very advanced confidence fusion - rich automated voting agents - complex economic stake mechanisms

Section B — Health Layer

Purpose

The Health layer maintains system homeostasis.

It should detect when the platform or a run is under stress and trigger a response before the whole system cooks itself.

Health Goals

1. Track workload health beyond simple uptime.
2. Surface unhealthy patterns during run execution.
3. Trigger adaptive actions when stress thresholds are crossed.
4. Expose health state to Hypha and Loom.

Health User Stories

• As an operator, I can see when a run is degraded.
• As the runtime, I can slow, pause, or reroute work when thresholds are crossed.
• As an operator, I can inspect why the system marked a run unhealthy.
• As a policy designer, I can configure threshold-based responses.

Health Functional Requirements

Inputs

The health layer should be able to consume metrics such as: - run latency - queue depth - retry frequency - error rate - token burn if applicable - context pressure if applicable - timeout frequency - blocked state duration

Health state model

At minimum, V1 should support health states like: - healthy - degraded - stressed - critical

Response behaviors

The health layer should be able to trigger: - alerts or visible warnings - throttling recommendations or actions - run pause actions - reroute/fallback recommendations where configured - escalation to Quorum or operator review when critical

Health V1 Scope

Include: - rule-based threshold detection - run-level health state - system-level stress indicators if feasible - visible degraded/critical status in Loom - hooks into runtime pause/throttle behavior

Defer: - advanced predictive forecasting - complicated reinforcement feedback loops - perfect energy accounting abstractions

Section C — Seed Layer

Purpose

The Seed layer handles recovery.

It exists so that a workflow failure does not mean starting from zero unless that is actually necessary.

Seed Goals

1. Create durable checkpoints for workflow runs.
2. Allow workflows to resume from valid recovery points.
3. Support replay or rollback pathways where configured.
4. Expose recovery options to operators.

Seed User Stories

• As an operator, I can see whether a run has checkpoints.
• As an operator, I can resume a failed or interrupted run from a checkpoint when allowed.
• As the runtime, I can create checkpoint records at defined moments.
• As an operator, I can trigger replay or recovery flows with auditability.

Seed Functional Requirements

Checkpoint model

• Workflows can define checkpoint policies.
• The runtime can create checkpoint records at key transitions.
• Checkpoints reference relevant run state and metadata.
• Checkpoints are queryable from the UI and backend.

Recovery behavior

• A run can resume from a valid checkpoint.
• A run can be restarted from a known point, subject to policy.
• Recovery actions are recorded durably.
• The system distinguishes full restart from partial replay or resume.

Recovery safety

• Recovery must respect governance and permissions.
• Recovery should not silently duplicate sensitive side effects when avoidable.
• Operators should be warned when replay safety is uncertain.

Seed V1 Scope

Include: - checkpoint records - resume/replay from defined states - operator-visible recovery entry points - audit trail for recovery actions

Defer: - universal undo across all integrations - perfect transactional rewind of side effects - deep disaster recovery for every external system

Section D — Immune Layer

Purpose

The Immune layer surfaces anomaly and trust signals.

It does not need to be magic in V1. It needs to be useful.

It should detect suspicious patterns and route them into pause, escalation, or review flows before a bad run causes more damage.

Immune Goals

1. Detect abnormal or risky behavior patterns.
2. Surface anomaly signals to Loom and Quorum.
3. Trigger pause, quarantine, or review hooks.
4. Establish the first real trust-event model in Cambium.

Immune User Stories

• As an operator, I can see anomaly flags on a run.
• As the system, I can raise an anomaly event when behavior crosses a defined threshold.
• As the runtime, I can pause or block a run based on immune signals.
• As an operator, I can inspect what triggered the anomaly.

Immune Functional Requirements

V1 anomaly inputs

At minimum, support rule-based anomaly detection on signals such as: - repeated unexpected failures - unusual retry patterns - abnormal tool or action frequency - policy violations or attempted violations - suspicious execution paths - unusual cost or latency spikes

Immune responses

The immune layer should be able to: - emit anomaly events - attach severity levels - recommend or trigger pause/block actions - route severe cases into Quorum review - expose anomaly state in Loom

Anomaly record model

Each anomaly record should include: - related run/task IDs - signal type - severity - summary - response taken - resolution state - timestamps

Immune V1 Scope

Include: - rule-based anomaly events - severity tagging - pause/block hooks - operator visibility - governance escalation hooks

Defer: - ambitious self-learning threat intelligence engines - complex probabilistic trust reputation systems - cross-ecosystem security federation

Cross-Cutting Requirements

1. Event Integration

All four subsystems must consume the common event and state model from Cambium Core and Hypha.

Requirements: - Quorum can react to sensitive action events. - Health can react to stress-related signals. - Seed can react to checkpoint-worthy transitions. - Immune can react to anomaly-triggering patterns.

2. Auditability

All major governance, health, recovery, and immune actions must leave an audit trail.

At minimum, audit records should capture: - who or what initiated the action - what triggered it - what policy or threshold applied - what the system did next - when it happened

3. Operator Visibility

Loom must be able to surface: - pending approvals - health state - anomaly state - checkpoint/recovery options - interventions and outcomes

If these subsystems exist only in the backend, they will not deliver the trust they are supposed to create.

4. Permissions

Sensitive actions across all four subsystems must be permission-aware.

Examples: - not everyone can approve everything - not everyone can replay failed runs - not everyone can override a critical pause

Success Metrics

Quorum success

• Sensitive actions are visibly gated.
• Decision records are inspectable.
• Operators can process approvals without backend hacks.

Health success

• Runs can be marked degraded or critical based on real thresholds.
• Stress signals trigger visible or functional responses.
• Operators can understand why a run was downshifted or paused.

Seed success

• Checkpoints are created and retrievable.
• Operators can resume or replay eligible runs.
• Recovery actions are auditable.

Immune success

• Risky patterns surface as anomaly events.
• Severe anomalies can pause or escalate execution.
• Operators can inspect what triggered a response.

Open Questions

1. What exact policy format should Quorum use in V1?
2. Which health metrics are mandatory for the first release?
3. What checkpoint granularity is practical without slowing the runtime too much?
4. Which anomaly signals are high-value enough to include immediately?
5. When should immune events auto-pause vs merely warn?

Build Recommendation

Implementation order should probably be: 1. Quorum gating and decision records 2. Seed checkpoints and basic resume/replay 3. Health thresholds and visible run-level status 4. Immune anomaly events and escalation hooks

Reason: governance and recovery are the sharpest early differentiators, and they also make the platform less reckless while the rest of the system matures.

Final Requirement Statement

Quorum, Health, Seed, and Immune must give Cambium V1 the governance, stress regulation, recovery, and anomaly-response capabilities required for resilient orchestration rather than brittle automation.