Observe, then enable changes

New autonomous actions in FDAI never turn on all at once. Every promotable rule, assignment, workflow, and ActionType starts in observation mode. It makes the same decision it would make in production, but the decision is only recorded, never applied. An action becomes eligible for enforcement only after a measured comparison against the baseline and a separate governance review.

What observation mode records

While a new capability is observing, every event flows through it as if autonomy were already on:

• FDAI computes the full trust-routing and safety-check decision.
• It stores the proposed action, meaning what would have executed.
• It captures the resolution people actually chose, taken from the audit log.
• The difference between those two is the observation accuracy signal.

Nothing about production behavior changes. Approvals still go to people, and fixes still ship the way they always did. The new capability is watching, not steering.

What promotion takes

FDAI promotes a capability only when its observation evidence beats a bar that was registered in advance against the Phase 0 baseline. The evidence packet names the frozen scenario set and the measurement window, so a reviewer can reproduce the comparison.

• Minimum evidence: the configured observation duration and sample size are met.
• Outcome quality: agreement, false-positive, and false-negative rates meet the action’s thresholds against the same scenario set.
• Zero would-be policy violations: no observed action would have slipped past a deterministic policy denial. The canonical policy_escapes guard metric has to be exactly zero.
• Safety readiness: preconditions, stop conditions, impact scope caps, idempotency, rollback rehearsal, and audit completeness all pass.
• Operational guard metrics: change-failure and rollback rates do not get worse than the baseline.

Evidence readiness does not change the lifecycle mode by itself. It opens a separate governance review for the exact target, scope, version, and evidence digest. A rule or assignment uses a reviewed catalog pull request. An ActionType or workflow uses a governed promotion-registry update. Neither is bundled with the capability’s first commit.

How lifecycle state changes

The authoritative promotion registry is the only source that changes an action from observation to enforcement eligibility. Deployment environment, execution venue, and local flags cannot perform this transition.

What exactly is promoted

Related controls move independently:

Control	Observation state	Enforced state
Rule effect	audit or do-not-enforce	deny or remediate for a bound scope
Assignment	Observes a rule set on selected resources	Applies the reviewed effect and parameters to that scope
ActionType	default_mode: shadow, and it changes nothing	The promotion registry marks it enforcement-eligible; each event still passes the risk and authority gates

Promoting a rule does not automatically promote every assignment or action that references it. Each control keeps its own evidence, review, scope, and rollback reference.

Who approves promotion

Promotion is a governance change delivered through the reviewed control that owns the target: a catalog pull request for rules and assignments, or a governed promotion-registry update for ActionType and workflow state. The request includes the evidence packet, target scope, action version, and rollback plan. The requester cannot approve their own promotion. The required role and quorum come from the governance action and risk decision, and the approval is recorded separately from execution outcomes.

What triggers a demotion

The same guard signals keep running after promotion. If a live enforced capability misses its promotion bar, records a policy escape, or loses a required dependency, the affected assignment or action drops back to observation mode and the on-call team is alerted. Fixing the regression starts a new evidence and promotion cycle.

A scoped override is not an automatic global demotion. It suppresses or narrows execution only inside its bounded scope while detection keeps observing. Overrides that repeat or last a long time become evidence for revising or retiring the rule, and that change still goes through the normal catalog quality gate.

Demotion is not rollback

Demotion prevents future changes by putting the capability back into judge-and-log behavior. It does not undo a change that already ran. Restoring the previous state is the job of the action instance’s rollback_contract, which has its own audit reference and recovery verification.

Example: a right-sizing action fails its rollback-rate guard -> the assignment drops back to observation mode -> no new right-sizing changes start -> anything already applied is restored through that action’s scripted or pull-request rollback path.

Why this matters to operators

Three consequences for anyone using the system:

• New autonomy never arrives without evidence. By the time an action starts running on its own, it has already been observed doing the same thing for the configured window and has passed a measurable bar.
• Stopping future execution is a standard control. Demotion uses the same catalog and assignment pipeline as promotion, so a regression has a defined response instead of an improvised emergency change.
• Executed state still has an explicit recovery path. Demotion and rollback are separate, observable operations, so you can see whether automation stopped and whether the previous state was restored.

Next steps

To learn about	Read
The tiers this observe-then-enforce flow runs on	deterministic-first.md
What auto and human approval mean for the resulting actions	risk-tiers.md
Safety invariants required for every action	../../../.github/instructions/coding-conventions.instructions.md
The phase exit gates that promote capabilities	../../roadmap/README.md
Rule effects, assignments, and scoped overrides	../../roadmap/rules-and-detection/rule-governance.md
Baselines and promotion guard metrics	../../roadmap/architecture/goals-and-metrics.md