Release, Interrupt, Recover, and Learn

An agent release is not a switch from tested to trusted. It is a controlled increase in what the system can observe, decide, propose, and affect. Each increase buys evidence by accepting exposure. The engineering job is to purchase only the evidence needed for the next decision and to keep the price bounded when the hypothesis is wrong.

AR-11 supplies a privacy-minimal trace graph, consequence-aware operating envelope, tail signals, limits, degradation paths, and named signal owners. Those artifacts make a release observable, but observability does not authorize exposure. Chapter 17 turns them into AR-12 v1.0.0: a readiness record, staged exposure plan, reachable stop map, incident packet, verified correction, and explicit release disposition.

The underlying release idea is established outside agent systems. A canary is partial, time-limited exposure compared with a control before broader rollout. [CLM-033] Agent systems add another dimension: exposure is not only traffic. It includes available capabilities, effect classes, approval requirements, autonomy, retry ownership, state access, and the number of people or synthetic records that can be affected. This chapter therefore adopts canary practice, but does not pretend that a conventional deployment percentage completely describes an acting system.

The governing recommendation is stricter. Increase real-effect exposure only after the preceding stage answers a named question and while kill, rollback, containment, or autonomy-reduction authority is reachable. [CLM-034] Some effects cannot be rolled back. A message may already have been read. Inventory may have been physically moved. A reservation may have displaced another request. For those effects, the honest response is containment, reconciliation, compensation, disclosure through the proper owner, and prevention of recurrence. “Rollback” must never serve as magic language for erasing consequence.

FieldOps Relay remains fictional and local. Its records, approvals, reservations, clocks, dependencies, and incidents are deterministic fixtures. It has no credentials, network access, customer contact, equipment control, safety diagnosis, or real operational effect. The release method is realistic; the claimed outcome stays bounded to the sandbox. SRE, security, privacy, product, domain, and organizational incident owners retain their authority.

Replace the rollout plan with a release question

Many release documents begin with percentages: 1 percent, 5 percent, 25 percent, everyone. Those numbers can organize deployment, but they do not say why exposure is justified. A useful stage starts with a question whose answer can change a decision.

Examples include:

• Can the new artifact be reconstructed from frozen inputs under the release build?
• Does simulation preserve authority and effect invariants when faults are injected?
• Do shadow proposals agree with eligible live cases without causing any effect?
• Can read-only operation retrieve the correct tenant-scoped evidence within its budget?
• Can reviewers detect and reject invalid proposals before an effect?
• Does a bounded cohort remain within quality, tail, retry, support, and effect limits relative to its control?

“Is it ready?” is too broad. “Does the approval-required cohort avoid duplicate synthetic reservations during a dependency slowdown while preserving completion within the declared tail budget?” is answerable. It names the consequence, perturbation, control, stage, and decision.

Write a falsifiable hypothesis

Use a statement that permits failure:

For the North synthetic cohort, build fo-17.3 will complete eligible reservation tasks with no duplicate semantic effects, no approval bypass, and no critical tail-budget breach during the four-hour test window, compared with the frozen deterministic baseline.

The hypothesis does not promise global safety. It does not average away the two non-negotiable conditions. It identifies the build, cohort, effect, authority requirement, disturbance, duration, and comparison.

Record what would disconfirm it. One confirmed duplicate effect fails the effect claim. One effect executed without an exact valid approval fails the authority claim. A missing effect link makes the evidence insufficient even if no duplicate appears. If the test cannot tell pass from unknown, it is not a release gate.

Name the decision before collecting data

Every question maps possible evidence to dispositions:

Evidence state	Allowed disposition
Gate passes and evidence is complete	promote only to the named next stage
Quality improves but effect or authority invariant fails	contain and repair; do not promote
Invariants hold but tail or support budget fails	hold, reduce workload, or reduce autonomy
Results are noisy, control changed, or links are missing	hold and repair measurement
Material residual risk has no credible containment	retire the release candidate or capability
Incident occurs	stop affected exposure, reconcile, investigate, correct, replay, and decide again

Promotion is one outcome among several. Hold is not indecision when a gate lacks evidence. Retirement is not embarrassment when the system cannot earn bounded exposure.

Freeze the comparison

The control must be identifiable. Record control build, model adapter, tool contracts, policy, harness, task slice, state fixture, budget, and observation window. If the control changes during the stage, either restart or analyze the change explicitly. Comparing a new agent against a moving mixture of old and new behavior creates a persuasive graph with no stable claim.

Use paired replay when possible: the same versioned task fixture goes to control and candidate. For cohort exposure, allocate by a deterministic rule that cannot be influenced by the agent. Record exclusions. A control is not “last week” if demand, dependencies, policies, or task mix changed without measurement.

Define readiness before deployment

The readiness record is a signed decision input, not a ceremonial checklist. It includes:

• candidate and control component versions and hashes;
• claim and question being tested;
• task and consequence slice, exclusions, and transfer limits;
• allowed capabilities, effects, data, tenants, and autonomy;
• evaluation, adversarial, durability, trace, load, and recovery evidence;
• baseline and gate metrics with uncertainty;
• duration, maximum exposure, and promotion ceiling;
• stop triggers, mechanism, operator, backup, and reachability proof;
• rollback eligibility by effect class, reconciliation path, compensation owner, and residual harm;
• on-call, domain, security, privacy, product, and incident-command handoffs;
• current known risks and retirement conditions.

An item marked “not applicable” requires a reason. An item marked “pending” blocks only the claims that need it, but those claims cannot be quietly carried into the release description.

Choose the smallest exposure that can answer the question

Exposure has multiple axes. Traffic or task count is only one. A stage may widen environment realism while keeping effects disabled. Another may keep the cohort tiny while enabling one approval-bound effect. Describe the complete exposure vector:

exposure = {
  environment,
  task_slice,
  cohort,
  state_scope,
  data_class,
  capability_set,
  effect_class,
  autonomy_level,
  approval_mode,
  concurrency,
  duration,
  maximum_effects
}

Select the minimum vector that distinguishes the competing explanations. If replay can reveal a state migration defect, do not use a live cohort. If shadow can test proposal quality, do not enable reservation. If read-only access can test tenant retrieval, do not grant write capability. If an approval-required effect is necessary, cap count and consequence before widening cohort.

The ladder is not automatic

The FieldOps ladder uses replay, simulation, shadow, read-only, approval-required, and bounded cohort stages. A broader release may follow, but it is not an earned badge at the end of a mandatory sequence. Stages can repeat, branch, or end in retirement. A candidate can pass simulation and fail shadow because production-like inputs differ. It can pass read-only and fail approval usability. It can succeed in a cohort while remaining unsuitable for unrepresented tasks.

Replay and simulation are sometimes ordered differently. Replay uses recorded or constructed versioned trajectories and expected state. Simulation exercises an executable environment with controlled dynamics and faults. Choose the order based on the question, and record it. The invariant is increasing exposure only when needed, not allegiance to a universal diagram.

Long description: Six rooms form a left-to-right sequence. Replay tests frozen histories without executing capabilities. Simulate tests controlled dynamics and injected faults. Shadow receives production-like inputs but its proposed actions are isolated from effect adapters. Read Only can query scoped state but cannot mutate it. Approval can execute only an exact reviewed synthetic effect. Cohort permits that effect for a bounded slice, count, and duration. Each room has its own Stop control connected to a named operator, and every doorway lists a question, evidence gate, and maximum next exposure. A side exit from every room leads to Hold, Reduce, Repair, or Retire, showing that promotion is not inevitable.

Operate each exposure stage

Every stage uses the same record shape: hypothesis, environment, slice, allowed actions, effect boundary, authority, control, signals, uncertainty, duration, exit criteria, stop mechanism, owner, data handling, incident path, and evidence update. Consistency prevents a team from becoming precise only when effects are already enabled.

Replay

Replay asks whether a versioned candidate behaves acceptably on preserved tasks and injected histories. Inputs include initial state, evidence artifacts, approvals, fault schedules, clocks, and expected effects. External adapters are doubles. The candidate cannot alter the canonical fixture.

Compare outcome and trajectory, not only final text. Check action validity, authority, state transitions, semantic effect intent, recovery, efficiency, and unsupported segments. Inject lost responses, late callbacks, expired approvals, lease transfer, poisoned retrieval, and changed dependency timing. A replay pass proves behavior on those fixtures under those versions. It says nothing about unseen live tasks.

Exit only when critical invariants pass, unsupported slices are named, and differences against control have supported explanations. Hold if the harness is not representative enough for the next question. Retire if required behavior depends on an untestable assumption or repeatedly violates a hard contract.

Simulation

Simulation asks how the system behaves in an executable world with controlled state and timing. FieldOps uses synthetic inventory, service notes, slots, principals, approvals, effect ledger, and a dependency whose latency and responses can be scheduled. No network or real system is present.

Drive concurrent runs and state races. Slow the reservation dependency. Drop a response after commit. Return retryable and non-retryable errors. Make a stop operator temporarily unavailable. Advance approvals past expiry. Validate that deterministic enforcement, not prompt obedience, blocks forbidden effects.

Simulation earns confidence in mechanics under modeled conditions. It cannot establish production capacity, provider behavior, real reviewer response, or complete domain coverage. Its exit gate requires both observed results and a simulation-to-target gap statement.

Shadow

Shadow asks what the candidate would propose on production-like inputs while an existing path remains authoritative. The candidate may read an explicitly prepared projection and produce sealed proposals. It cannot call an effectful adapter, reserve a slot, notify a person, or write authoritative state.

Enforce shadow at the capability broker and credentials boundary. A prompt saying “do not execute” is insufficient. The shadow runtime receives no effect capability. Any attempt generates a control event and stops the run. Shadow output cannot silently influence the control operator unless the stage explicitly studies decision support and records that influence.

Compare eligibility, proposed action, abstention, evidence use, policy result, quality, latency, and operator-review burden. Beware hindsight grading: an existing decision is evidence, not automatically truth. If the shadow system identifies a plausible alternative, send it through the established evaluation process rather than marking disagreement wrong.

Exit only if no effect path exists, proposal evidence is useful enough for the next stage, and the candidate’s unsupported or high-risk segments are excluded. A shadow system that performed one write did not have a minor metric failure. It violated the stage definition.

Read only

Read-only operation asks whether the candidate can retrieve and synthesize authorized current state in the target path. The capability catalog exposes scoped queries but no mutation. Returned content remains untrusted evidence, not instruction.

Test tenant isolation, query bounds, freshness, pagination, rate limits, redaction, caching, and dependency degradation. A read can still create risk through sensitive access, load, misleading output, or downstream human action. Data and privacy owners define allowed views. Rate and concurrency budgets from AR-11 remain active.

Exit when correct scoped retrieval and abstention meet the gate, access denials are contained, and support load is acceptable. Reduce scope if only one task segment is supported. Do not infer that read success proves write safety.

Approval required

This is the first FieldOps stage that may create a synthetic reservation. The system proposes an exact effect with proposal hash, tenant, part, slot, quantity, consequence class, evidence references, expiry, and idempotency key. A verified reviewer sees the material facts and can approve, reject, request information, or take over. Approval binds the exact proposal and one validity window.

The product-specific Operator and ChatGPT agent system-card cases illustrate confirmation and supervision layers for browser-acting agents. They support the existence of such patterns, not universal safety or formal authority. FieldOps uses its own deterministic approval contract. Confirmation can add friction, arrive too late, or become habitual. It remains one layer, never a substitute for capability scope, validation, effect verification, and reachable intervention.

Measure approval correctness, rejection quality, evidence sufficiency, expiry, queue delay, reviewer load, takeover, and post-approval mutation rejection. If reviewers approve because the interface hides uncertainty, a high approval rate is a warning, not success.

Bounded cohort

A cohort stage is partial and time limited, evaluated against a control. [CLM-033] Define cohort membership deterministically, state the comparison, cap duration and semantic effects, and prevent candidate-selected routing. FieldOps may allow only North synthetic reservation tasks classified low consequence, one reservation effect per run, maximum twenty confirmed effects, two-hour duration, concurrency two, and approval required.

Observe completion, invalid action, approval bypass, duplicate semantic effect, unresolved effect age, p95 elapsed time, retry count, queue depth, operator load, cancellation latency, and support events. Segment critical invariants rather than averaging them into a score. Zero observed duplicates across twenty effects does not establish a universal duplicate rate. It establishes only what happened in that bounded fixture.

Compare with the frozen control, but do not require the candidate to win every metric. A slower candidate may be acceptable if it reduces invalid actions within budget. A faster candidate is unacceptable if it widens effects or hides uncertainty. The gate encodes those priorities before results arrive.

Make stop authority reachable

A stop rule on a document is not a control. Reachability means a qualified person or automated mechanism can detect the trigger, authenticate, invoke the correct containment action, and verify the result within the allowed time while the system is under load.

For each stage record:

1. Trigger: a deterministic condition, evidence source, severity, and uncertainty policy.
2. Detection path: signal, alert routing, and maximum detection delay.
3. Authority: primary owner, backup, and organizational incident handoff.
4. Mechanism: capability revoke, cohort gate close, queue pause, lease cancel, credential disable, adapter quarantine, or deployment rollback.
5. Reachability proof: acknowledgement drill and authenticated execution test.
6. Verification: evidence that new effects stopped and in-flight effects were reconciled.
7. Residuals: requests already committed, late callbacks, stale workers, and affected records.

The person who can edit a dashboard may not have authority to halt effects. The person with authority may not have credentials. The credentials may work only through a failed dependency. Test the whole path.

Trigger classes

Hard triggers stop affected exposure immediately. Examples are approval bypass, cross-tenant access, confirmed duplicate semantic effect, effect outside allowlist, stale-owner write accepted, stop mechanism failure, or missing authority/effect evidence for a consequential action.

Soft triggers start a bounded review or reduce exposure: rising p95 latency, repeated retryable errors, reviewer backlog, elevated abstention, or trace-link gaps in low-consequence read-only tasks. Define time window and escalation. A soft trigger becomes hard when it threatens an invariant or consumes the remaining error budget.

Use absolute ceilings as well as rates. One duplicate out of one is not comforted by insufficient denominator. Ten unresolved effects are dangerous even if the percentage is below threshold during a traffic surge.

Prove reachability before the cohort

Run a stop drill in the exact stage configuration. Inject STOP_TEST, verify alert delivery to primary and backup, have the authorized operator close the cohort gate and revoke the reservation capability, then attempt a new run. It must remain read/propose only. Inspect queue, workers, leases, and effect adapter. A disabled UI button with active backend capability is failure.

Measure detection, acknowledgement, containment command, effective containment, and verification times separately. Record missed alerts and manual work. If the backup cannot operate the mechanism, the stage does not begin.

Reduce autonomy before total shutdown when appropriate

Containment can preserve useful service without preserving the risky effect. FieldOps degradation levels are:

• D0: bounded cohort with approval-bound synthetic reservation;
• D1: proposal plus approval, but effect dispatch disabled;
• D2: read-only evidence assembly;
• D3: deterministic workflow only;
• D4: intake paused and queued work cancelled or handed off.

The trigger maps to a level. Dependency slowdown may move from D0 to D1 while preserving reads. Approval-integrity failure moves directly to D2 or D4. Cross-tenant behavior revokes the affected capability and transfers to security authority. Reduction must be enforced outside the model and visible in trace/state.

Distinguish rollback, roll forward, compensation, and retirement

Deployment rollback restores a prior software/configuration version. State rollback restores a compatible prior state only when the state model permits it. Neither reverses an external effect already committed. Roll forward repairs the current version and reconciles state. Compensation creates a new authorized effect intended to address an earlier one. Retirement removes a candidate or capability from future use and archives its evidence.

Write the effect matrix:

Effect state	Available response
proposal only	cancel safely and record disposition
queued, not dispatched	revoke/cancel and verify no adapter call
dispatched, outcome unknown	freeze retry and reconcile by semantic identity
committed synthetic reservation	preserve record; perform separately authorized compensation if required
invalid or duplicate committed effect	contain new effects, reconcile all related records, compensate if permitted, retain residual consequence
incompatible state after code rollback	quarantine and migrate or roll forward; do not force old worker

Never label compensation as undo. It has its own identity, authority, failure modes, cost, and evidence.

Compute gates without hiding uncertainty

A stage gate combines hard invariants, comparative measures, absolute ceilings, and evidence-quality requirements. Keep those categories separate. If they are collapsed into one weighted score, a latency improvement can numerically cancel an approval bypass. No amount of efficiency compensates for a violated authority contract.

Evaluate in this order:

1. Evidence integrity: are candidate, control, versions, cohort assignment, event links, denominators, and observation windows valid?
2. Hard invariants: did any forbidden effect, approval bypass, tenant breach, duplicate semantic effect, or stop failure occur?
3. Absolute ceilings: did unresolved effects, tail time, attempts, cost, queue, or reviewer backlog exceed the declared maximum?
4. Comparative measures: how did the candidate differ from control by task and consequence segment?
5. Uncertainty and coverage: which estimates are noisy, which critical cases are sparse, and which target slices were absent?
6. Operational burden: did alert, triage, review, reconciliation, or support demand exceed available capacity?

Failure at the first two layers stops promotion. A ceiling breach produces the predefined hold, reduction, or stop even if average comparison is favorable. Comparative improvements matter only inside the invariant envelope.

Treat false release decisions as consequences

Automated canary analysis has false-positive and false-negative trade-offs. A gate that is very sensitive may halt a healthy candidate frequently, slowing delivery and training operators to ignore alarms. A permissive gate may miss a rare but material failure. Choose the balance from consequence, not dashboard aesthetics.

For FieldOps, duplicate effect and approval bypass use zero-tolerance fixture triggers because a single confirmed case refutes the bounded claim. Latency uses a windowed threshold with minimum samples because one scheduler pause should not cause unsafe thrashing. Unresolved effects use both a rate and an absolute count because incident work grows with count even when traffic grows faster.

Write what happens when evidence conflicts. If trace reports success while the authoritative effect ledger reports unknown, the effect remains unknown. If the monitor is unavailable but independent broker and ledger invariants remain observable, the stage may reduce to read only under a predeclared rule. If cohort assignment or effect links are corrupted, hold; do not impute favorable values.

Use promotion ceilings

A gate authorizes a specific next exposure, never all later stages. Passing simulation can authorize shadow for one task slice. Passing approval can authorize five synthetic effects, not a broad cohort. Record the ceiling as machine-readable policy so deployment tooling cannot interpret PASS as unrestricted release.

decision = CONDITIONAL_GO
authorized_next_stage = approval_required
authorized_task_slice = north_fixture_low_consequence
maximum_semantic_effects = 5
maximum_concurrency = 1
expires_at = 2026-08-16T18:00:00Z
requires = [stop_drill_17_04, approval_contract_06_12]
excludes = [unsupported_low_inventory_segment]

Expiry matters. Evidence can age when dependencies, models, tools, policies, staff coverage, or incident systems change. An old readiness signature must not reopen a closed gate after its assumptions drift.

Make hold operational

HOLD needs an executable state. Close candidate assignment, leave already committed effects in reconciliation, preserve the tested build and evidence, assign the missing evidence owner, and set a review condition. Do not leave a release half enabled while waiting for a meeting.

A hold record states why promotion is unsupported, what remains safe, what work is blocked, what new evidence could change the decision, when the record expires, and who can resolve or retire it. If no feasible evidence could change the decision, the honest disposition is retirement rather than indefinite hold.

For the unsupported FieldOps shadow segment, hold means no routing for low-inventory substitution tasks, no effect capability, preserved proposal/evaluation artifacts, and an owner for expanding the representative fixture. North read-only and the separately supported approval slice may continue only if their routing cannot admit the held segment.

Prevent decision races

Release decisions are state transitions with expected versions. Two operators must not simultaneously promote and stop the same cohort. Use a revision guard, append the decision event, and require deployment gates to read the current signed revision. A late promotion command created before an incident must fail after the stop revision.

The state machine can be small:

PREPARED -> RUNNING -> PASSED -> AUTHORIZED_NEXT
                    -> HELD
                    -> REDUCED
                    -> STOPPED -> RECONCILING -> REPAIRING -> REPLAYING
                    -> RETIRED

Not every transition is legal. STOPPED cannot jump directly to AUTHORIZED_NEXT. RECONCILING cannot complete with unowned ambiguous effects. REPAIRING cannot become PASSED without the preserved failure and replay evidence. An organizational incident commander may impose a stricter state; the local release controller cannot override it.

Pre-mortem the release

Before any effect stage, ask how the plan could create harm while dashboards still look healthy.

Average success hides a critical segment

Normal reservations pass while low-inventory cases produce invalid substitutions. Segment by consequence and hidden constraint. A global completion rate cannot promote an unsupported critical slice.

Stop authority disappears during the incident

The primary operator is unavailable, the backup lacks permission, or the control plane shares the failed dependency. Run drills across shifts and failure domains. A phone number in a runbook is not reachability evidence.

Shadow performs an effect

The candidate is deployed with production credentials but instructed not to use them. One tool call mutates state. Prevent this structurally with absent capability, deny policy, synthetic endpoints, and an assertion that no effect ledger event can originate from shadow.

Rollback restores code but not semantics

New workers wrote state the old build cannot interpret. Rolling back code creates failures or repeats actions. Gate rollback on state compatibility, quarantine incompatible checkpoints, and preserve one owner for reconciliation.

Monitoring becomes the release rationale

The team says risk is acceptable because it has many alerts. Detection is incomplete, alerts are noisy, and response is slow. A monitor supports a decision path; it does not replace prevention, containment, or authority.

The correction has no replay

A developer patches the obvious retry site and closes the incident. Another retry layer still multiplies calls. Require a failing fixture, a passing correction, adjacent regression cases, and bounded re-release. A code diff alone is not verified learning.

Run the FieldOps retry-storm incident

The incident is deliberately synthetic. Its purpose is to show how an acting system inherits ordinary distributed-systems ambiguity and adds agent-specific authority, state, and trajectory concerns.

Release configuration

Candidate fo-17.3 is in the approval-required North cohort. Maximum twenty synthetic reservation effects, concurrency two, four total attempts per run but one effect-owner retry layer, one semantic key per approved intent, and no autonomous compensation. The reservation service double normally responds in 80 milliseconds. Its fault schedule slows responses beyond the client timeout and drops selected responses after commit.

The runtime, capability broker, adapter, and service double each contain legacy retry configuration. The readiness review claimed the adapter was the sole retry owner, but the runtime fallback remained enabled. This inconsistency is the latent defect.

Detect

At 10:02:00, dependency p95 crosses the stage limit. At 10:02:04, the unresolved-effect signal rises. At 10:02:07, the effect ledger reports two confirmed effect IDs linked to the same approved semantic intent for fixture REQ-N-17. The hard duplicate_semantic_effect trigger fires.

Do not infer duplicates from tool-call count alone. Multiple attempts can reconcile one effect. Here the authoritative synthetic effect ledger confirms two committed records with one intended semantic key family. The incident declaration records confirmed fact, detection source, consequence, affected cohort, uncertainty, and incident owner.

The first operational question is not “why did the model retry?” It is “are new effects still possible, and which prior outcomes remain unresolved?”

Contain

The automated cohort gate denies new candidate assignments. The on-call operator invokes reduce_to:D1, removing reservation dispatch while retaining proposal and read paths. The capability broker revokes [email protected] for build fo-17.3. Queue intake pauses. Active workers receive cancellation epoch 9.

Containment verification checks the broker, adapter, queue, leases, and effect ledger. One old worker holds epoch 8; its late dispatch is rejected by the adapter. Two requests remain SENT_UNKNOWN. The incident stays open because stopping new assignments does not resolve in-flight ambiguity.

The domain fixture owner reviews duplicate synthetic reservations. In a real operation, domain and incident authorities would decide customer, inventory, safety, contractual, or communication actions. The Agentic AI Engineer supplies effect identities and system state, not those decisions.

Reconcile

For every affected semantic intent, query authoritative service state by request identifier and approved intent hash. Classify:

• no effect found;
• one confirmed intended effect;
• duplicate confirmed effects;
• conflicting intent under reused key;
• still unknown because the service cannot answer.

Freeze blind retries. For REQ-N-17, two distinct service request IDs contain the same approved part, slot, and quantity. The first call committed then lost its response. The runtime retried the entire adapter operation while the adapter also retried its HTTP call. Each layer generated a new service request identifier instead of preserving the approved semantic identity. Server-side duplicate detection therefore could not collapse them.

AWS engineering guidance on idempotent APIs supports explicit client request identifiers, semantic validation, duplicate handling, and attention to late arrivals. It also makes clear, within its provider engineering context, that idempotency needs service support and does not undo a completed effect. Retry guidance supports bounded attempts, backoff, jitter, retry classification, and coordination of retry layers. It does not provide universal FieldOps limits. Those limits remain workload-specific.

Preserve the timeline

Build an append-only incident timeline from authoritative state and minimal traces:

Time	Evidence	Classification	Decision
10:01:58	fault scheduler starts dependency slowdown	confirmed synthetic fixture	observe stage signals
10:02:00	p95 exceeds gate	observed metric	soft trigger review
10:02:04	unresolved effects exceed ceiling	confirmed ledger projection	block promotion
10:02:07	duplicate semantic effect confirmed	authoritative effect record	hard stop
10:02:09	cohort gate closes	control event	no new assignments
10:02:12	capability revoked	broker event	reduce to proposal only
10:02:18	late epoch-8 dispatch denied	adapter control event	containment verified for stale worker
10:03:10	two unknown effects enter reconciliation	ledger state	retry frozen
10:05:42	all cohort intents classified	reconciliation report	begin repair scope

Preserve observation, inference, and decision as separate fields. “Dependency slowdown caused duplicates” is an initial hypothesis. The verified mechanism is layered retry ownership plus regenerated request identifiers after ambiguous commit. Slowdown activated the flaw; it did not by itself create the duplicate.

Identify contributing conditions

The direct technical flaw is split retry ownership. Contributing conditions include a readiness record that named no executable assertion for retry-owner uniqueness, a load fixture that slowed before dispatch but did not drop responses after commit, and a dashboard that counted successful runs without a semantic duplicate invariant.

The model proposed one approved reservation. It did not choose either retry loop. Blaming model unpredictability would misplace ownership and leave deterministic defects intact.

Repair

Assign one retry owner at the runtime boundary. The effect adapter performs one dispatch per attempt with the original stable semantic key and client request ID. After timeout it returns SENT_UNKNOWN, never a retryable generic error. Recovery must reconcile before redispatch. Server double rejects same key with different intent and returns the prior result for same intent.

Add a retry budget shared across layers. Backoff and jitter belong to the owner. Cancellation and lease epoch are checked immediately before dispatch. The capability broker denies revoked builds. The effect ledger records intent, dispatch, ambiguous response, reconciliation, and terminal disposition.

The patch also changes the release contract: any effect adapter that cannot reconcile ambiguous outcomes is excluded from autonomous redispatch. It may remain approval-bound with manual/domain reconciliation or be retired.

Verify

First reproduce the defect on the preserved candidate and fixture. A regression test that never fails against the old build proves little. Then run the patch through:

• commit-then-response-loss with same semantic intent;
• timeout before commit;
• late success response after cancellation;
• same key with changed intent;
• dependency slowdown with concurrent runs;
• stale lease owner dispatch;
• stop during unresolved effect;
• reconciliation service unavailable;
• compensation proposed without fresh authority;
• trace link removed from one effect.

Expected results are one or zero semantic effects according to fixture, no blind redispatch while unknown, conflict on changed intent, rejection of stale owner, reachable stop, explicit unresolved terminal state when reconciliation is unavailable, and no compensation without separate approval.

Replay the complete critical task slice and compare trajectories against the frozen control. Re-run load and tail gates because the repair may increase latency. Re-run privacy checks because incident instrumentation may have added fields. Re-run authority checks because new reconciliation and compensation actions are capabilities.

Decide bounded re-release

Verified correction does not restore the previous exposure automatically. Return to the smallest stage that tests the corrected mechanism. FieldOps repeats simulation with the exact fault schedule, then approval-required operation capped at five synthetic effects and concurrency one. The old cohort is not reopened until that stage passes.

If the correction cannot preserve a stable semantic key through the target service, disposition is REDUCE_AUTONOMY or RETIRE_EFFECT_CAPABILITY, not “accept and monitor.” If reconciliation remains unavailable, no amount of prompt tuning repairs the effect contract.

Long description: The scene starts at a Detect beacon connected to signal and effect evidence. Contain closes an effect door while a reachable owner marker remains at the control. Repair changes one retry owner and stable request identity at a workbench. Replay sends the preserved failing fixture and adjacent cases through the patched path. Update places new versions of code, tests, capability contract, threat/fault model, evaluation set, operational envelope, and release packet on a shelf. A rollback rail stops at already committed effects. A separate compensation rail begins with new authority and ends with residual-cost evidence. The main verified-correction rail reaches bounded re-release only after every preceding station has recorded evidence.

Connect monitoring to response without importing a vendor promise

OpenAI’s report about monitoring its internal coding agents describes a bounded provider case: layered automated monitoring, human review, investigation, and operational response around a high volume of agent actions. It is useful because it connects a signal to a response workflow rather than treating collection as control. It does not establish that monitoring eliminates misalignment, that reported monitor performance transfers to FieldOps, or that an internal coding environment authorizes surveillance elsewhere.

Use the case as a response-map prompt:

Layer	FieldOps question	Required response
structural signal	did a typed invariant or threshold fire?	route to named owner with minimal identifiers
automated classification	which run/effect/control class is implicated?	bound priority; never execute broad punitive action from score alone
human triage	is evidence sufficient and is consequence active?	contain, request evidence, dismiss with reason, or escalate
investigation	what is confirmed, inferred, disconfirmed, and unknown?	reconcile authoritative state and record access
system response	what must stop or degrade now?	revoke capability, close cohort, cancel lease, or preserve read-only mode
learning	which code, test, contract, control, or operating rule changes?	assign owner, replay, verify, and version artifact

Bound the monitor

Define target behavior, input fields, sensitivity, threshold, validation slice, known blind spots, false-positive and false-negative consequences, reviewer capacity, first action, escalation, retention, and retirement condition. A broad “suspicious agent” score without a bounded action can produce surveillance and alert fatigue without safer operation.

FieldOps monitors deterministic structural events: approval hash mismatch, effect outside scope, repeated denied capability, duplicate semantic effect, unresolved effect age, stale owner dispatch, and stop-control failure. It does not ingest full prompts or hidden reasoning. An incident may authorize sealed evidence retrieval under the Chapter 15 process, but that is a separate logged action.

Test the response path

Inject true positive, benign edge case, missing context, noisy burst, monitor outage, reviewer backlog, and compromised emitter. Measure detection and response separately. Verify that a false positive can be dismissed without corrupting run state, that a false negative has another independent control where consequence demands it, and that monitor loss triggers an explicit exposure decision.

Monitoring does not transfer formal incident, security, domain, employment, or legal authority. The response map names those owners. Technical triage ends where their decision begins.

Close incidents with verified change, not narrative completion

An incident can produce a polished document while the system remains unchanged. AR-12 requires a traceable chain:

observation
  -> confirmed consequence
  -> containment and residuals
  -> mechanism and contributing conditions
  -> correction objective
  -> implementation change
  -> failing regression fixture
  -> passing replay and adjacent tests
  -> artifact versions updated
  -> bounded release decision
  -> residual risk and owner

The correction objective is more durable than a specific patch. “Prevent more than one committed semantic reservation for one approved intent under ambiguous timeout” can be satisfied and tested across implementations. “Add try/catch in adapter” describes a mechanism without proving the objective.

Update every affected artifact

The FieldOps incident changes more than AR-12:

• AR-04 capability contract gains stable intent identity, one retry owner, ambiguous outcome, and reconciliation requirements.
• AR-08 durability record gains the preserved layered-retry failure and stale-owner containment fixture.
• AR-09 task environment and evaluation evidence gain dependency slowdown, lost-after-commit, and duplicate-semantic-effect segments.
• AR-10 fault/control matrix gains retry amplification, stop failure, and independent broker revocation tests.
• AR-11 trace and operational envelope gain duplicate effect, unresolved age, retry multiplication, stop latency, and degradation evidence without new payload collection.
• AR-12 records readiness error, incident timeline, containment, verified correction, and re-release ceiling.

Do not edit superseded evidence to look as if the team always knew the right design. Preserve the old versions and the decision that replaced them. Learning requires visible revision.

Verify the learning loop

Ask an independent reviewer to start from the incident trigger and reach the changed test, contract, code, replay result, and new disposition. Ask a second reviewer to start from the corrected contract and find the incident that justified it. Both directions must resolve by stable identifiers and hashes.

Run the old defect fixture against the repaired build and a deliberately mutated build that regenerates the request ID. The repaired build passes; the mutation fails. Run the stop drill with the dependency degraded. Run the stage gate with missing monitor data and confirm disposition is hold, not guessed pass.

Permit retirement

Retire when the effect cannot be bounded, the stop path cannot be made reachable, the service cannot reconcile ambiguity, reviewer burden makes approval ineffective, critical segments remain unsupported, or the benefit does not justify operational exposure. Retirement records candidate, capability, state disposition, open effects, data deletion/retention, replacement path, owners, and evidence.

A retired release can still teach. Keep synthetic fixtures and safe structural evidence as regressions. Remove credentials, routing, capability claims, and deployment artifacts that could revive it accidentally.

Build AR-12 v1.0.0

AR-12 is a packet of decisions and evidence, not a screenshot of a rollout dashboard.

Readiness record

{
  "artifact": "AR-12",
  "version": "1.0.0",
  "candidate": "fo-17.4",
  "control": "fo-16.2",
  "question": "Does stable intent identity prevent duplicate synthetic reservations under lost-after-commit responses?",
  "stage": "approval_required",
  "scope": {
    "tenant": "north-fixture",
    "taskClass": "synthetic_part_reservation",
    "maximumEffects": 5,
    "concurrency": 1,
    "durationMinutes": 60
  },
  "effect": {
    "allowed": ["synthetic_reservation"],
    "approvalRequired": true,
    "blindRetryAllowed": false
  },
  "stop": {
    "triggers": ["duplicate_semantic_effect", "approval_bypass", "stop_unreachable"],
    "primary": "release-operator-fixture",
    "backup": "service-owner-fixture",
    "mechanism": ["close_cohort_gate", "revoke_capability", "cancel_epoch"],
    "drillEvidence": "EV-STOP-17-04"
  },
  "decision": "CONDITIONAL_GO",
  "promotionCeiling": "approval_required_five_effects"
}

The example is local and synthetic. Production records need organization-specific identities, access controls, signatures, retention, and incident integration.

Stage and gate table

For every row include question, environment, slice, action/effect boundary, control, metrics, uncertainty, duration, pass, hold, stop, owner, data policy, incident path, and artifact update. A compact operational view can link to the full evidence:

Stage	Question	Effect ceiling	Gate	Stop proof	Disposition
Replay	does patch reject layered retry fixture?	none	critical fixtures pass	local cancel test	pass
Simulate	does lost-after-commit reconcile once under load?	synthetic double only	one semantic effect; tails in envelope	broker revoke drill	pass
Shadow	are proposals eligible on held-out slice?	none	authority and proposal gate	no effect capability assertion	hold for one unsupported segment
Read only	can scoped state be retrieved within budget?	none	tenant/access/freshness pass	query capability revoke	pass for North only
Approval	can reviewer govern exact effect?	five synthetic effects	no bypass/duplicate; usable evidence	primary and backup drill	conditional go
Cohort	does bounded operation hold versus control?	not yet authorized	pending approval evidence	must be redrilled	not started

The hold in shadow remains visible. The approval stage excludes that unsupported segment. Scope is narrowed rather than averaged.

Stop and recovery runbook

The runbook begins with consequence, not debugging:

1. Confirm trigger from authoritative or declared observational source.
2. Close assignment gate and reduce autonomy at the capability broker.
3. Revoke affected effect path and cancel current ownership epoch.
4. Verify no new effects while listing in-flight and ambiguous effects.
5. Reconcile each semantic intent; do not blind retry.
6. Transfer domain/security/privacy/incident decisions to named owners.
7. Preserve minimal evidence and record uncertainty.
8. Repair objective, implementation, tests, contracts, and controls.
9. Replay preserved failure and adjacent cases.
10. Decide bounded re-release, continued reduction, rollback, hold, or retirement.

Each command has preconditions, authentication, expected event, timeout, fallback, and verification query. Copy-and-paste commands without scope checks are dangerous. The operator confirms target build, tenant, capability, and cohort before execution.

Incident record

The record includes incident ID, declaration time, affected scope, consequence, facts, hypotheses, unknowns, timeline, evidence access, containment, residual effects, reconciliation, mechanism, contributing conditions, corrections, owners, tests, artifact updates, re-release decision, and closure criteria.

Closure requires no unowned ambiguous effects, containment verified, correction evidence complete or a documented retirement, and residual risks accepted by the proper owners. A patch deployment is an event in the timeline, not closure.

Verified-correction record

Map every correction:

Objective	Change	Failing evidence	Passing evidence	Residual limit	Owner
one effect per approved intent	stable semantic key across attempts	FX-LOST-COMMIT-OLD	FX-LOST-COMMIT-NEW	depends on service dedupe retention	capability owner
no layered amplification	one declared retry owner	FX-RETRY-LAYERS-OLD	load replay RP-17-22	dependency can remain unavailable	runtime owner
stale worker cannot dispatch	epoch check at adapter	FX-EPOCH-OLD	FX-EPOCH-NEW	control-plane failure remains	service owner
stop remains reachable	primary/backup drill	missed-backup drill	EV-STOP-17-04	organizational coverage outside fixture	release owner

Residual limits do not disappear because tests pass. Dedupe retention, inaccessible reconciliation, unseen workloads, and real human response remain transfer gaps.

Counterexamples that should stop promotion

The perfect replay

Ten thousand preserved tasks pass, but the fixtures contain no timeout after commit. The team wants a cohort because sample size is large. Reject. Volume does not cover a missing consequence mechanism.

The clean shadow

Shadow proposals look strong, but the shadow runtime has write credentials and logs show no calls. Reject the stage design. Absence of observed use is not structural effect containment.

The fast approval

Reviewers approve 99 percent in seconds. Interface inspection shows the proposal hides expiry and alternative slot. Hold. Speed and agreement do not prove informed authority.

The successful canary without a control

The candidate completes 95 percent of tasks during a quiet hour. No control ran, task mix changed, and alert delivery was disabled. Result cannot answer comparative release question. Hold and repeat.

The reversible reservation

The team says every duplicate can be cancelled. Cancellation is a new effect, may fail, may occur after displacement, and needs authority. Reclassify as compensatable with residual consequence, not reversible.

The patched incident

Production code changed and the immediate symptom stopped. No preserved failure, no replay, no contract update, and unresolved effects remain. Incident is contained at best, not corrected or closed.

The monitor that catches everything

A provider report demonstrates monitoring in its own environment, so the team assumes its local monitor has complete coverage. Reject the transfer. Validate local fields, thresholds, blind spots, reviewer path, privacy authority, and fallback controls.

The unavailable stop owner

The trigger is precise and the runbook is correct, but only one operator can authenticate and they are not on call. Stage cannot begin. Reachable authority is part of the effect boundary.

The inevitable ramp

A roadmap promises broad release Friday, so each gate is tuned to pass. Separate schedule from evidence. If leadership accepts risk outside the engineering gate, record that authority and dissent; do not rewrite test results.

Trade-offs that remain real

Slower exposure delays benefit and learning. Faster exposure increases the number and diversity of consequences before correction. Neither extreme is automatically responsible. Choose stage size from uncertainty, consequence, detection, containment, and recovery capability.

More monitoring can shorten detection while increasing privacy, security, retention, cost, and reviewer burden. Use the minimal causal fields established in Chapter 15. New release questions do not automatically authorize content collection.

Smaller cohorts bound impact but can produce weak statistical evidence and hide rare segments. Compensate with targeted fault injection, critical-case enumeration, longer time within a fixed effect ceiling, or a decision that evidence is insufficient. Do not lower the gate merely because the cohort is small.

Approval reduces autonomous effect exposure but creates latency, fatigue, diffusion of responsibility, and support load. Measure reviewer behavior and provide takeover. Approval cannot make an invalid capability safe.

Aggressive automated rollback shortens exposure to bad code but can corrupt incompatible state or repeat ambiguous effects. Automate only preconditions that are mechanically verifiable. Otherwise reduce autonomy and reconcile.

Holding a candidate incurs engineering and opportunity cost. Retirement can be the cheaper and safer outcome when the effect contract cannot be made reliable. Record benefit assumptions alongside control costs rather than treating safety work as overhead outside the release decision.

Exercise: design the stage gate and incident packet

Use the following scenario. FieldOps candidate fo-ex-17 improves synthetic task completion in replay. It introduces a faster reservation adapter. The dependency can slow after receiving a request, approvals last five minutes, and the effect service retains deduplication keys for only ten minutes. The on-call release operator covers the first hour; a backup has read access but has never invoked revoke. A shadow deployment currently has the same service credential as the cohort deployment. One test observed two calls but could not link them to effect identities.

Part A: state the question

Write one falsifiable next-stage question. Identify the competing explanations, control, task slice, critical invariants, duration, maximum effects, and evidence that would produce promote, hold, reduce, stop, or retire.

Do not accept “test whether it works.” A strong answer asks whether stable intent identity and single retry ownership prevent duplicates under lost-after-commit responses while approvals and stop remain valid.

Part B: complete the ladder

Create rows for replay, simulation, shadow, read only, approval, and cohort. For each row specify environment, allowed capabilities, effect boundary, authority, control, metrics, uncertainty, duration, gate, stop mechanism, primary and backup owner, data handling, incident path, and evidence update.

The shadow row must remove the effect credential before it can run. The cohort cannot start until the backup completes a revoke drill. The ten-minute dedupe retention must be compared with maximum retry/recovery duration; if intent can reappear later, the design needs an application ledger or no autonomous redispatch.

Part C: inject the incident

At minute 18, latency rises. A response is lost after commit. The runtime and adapter each retry, generating new request IDs. Two synthetic reservations are confirmed. Write the first fifteen minutes of the incident timeline. Separate fact, inference, decision, and owner.

Contain new effects, reduce to proposal/read, cancel ownership epoch, reconcile every ambiguous intent, and preserve evidence. Do not start with prompt inspection. Do not call cancellation rollback.

Part D: define correction evidence

Write the correction objective, failing fixture, patch-independent contract, passing fixtures, adjacent regressions, operational rechecks, artifact updates, and bounded re-release ceiling. Include a retirement condition.

Part E: defend the boundary

Name decisions retained by SRE/incident command, security, privacy/legal, product, and domain owners. State what the Agentic AI Engineer supplies to each. Explain why a local synthetic pass does not authorize a real service deployment.

Assessment rubric

Score twenty points:

• Hypothesis and decision quality, 0-4: the question is falsifiable, control and scope are frozen, uncertainty is visible, and every evidence state maps to a disposition.
• Effect containment, 0-5: capabilities and effects are structurally staged, shadow cannot act, ambiguous outcomes reconcile before retry, and compensation is a new authorized effect.
• Stop authority, 0-4: triggers, primary, backup, mechanism, drill, timing, verification, and residual in-flight work are explicit.
• Correction evidence, 0-5: the old build fails a preserved fixture, the patch passes it and adjacent cases, affected artifacts change, and bounded re-release or retirement follows.
• Limits and handoffs, 0-2: synthetic transfer limits and organizational authorities are named.

A score below full credit on effect containment or stop authority blocks effectful release regardless of total. Twenty points does not prove production readiness; it shows that the exercise packet is internally complete.

Reviewer probes

Ask which exact observation would change the disposition. Ask how the stop works when the dependency and primary operator are unavailable. Ask which already committed effects survive code rollback. Ask what prevents shadow dispatch. Ask which test failed on the old build. Ask what was updated besides code. Ask when retirement becomes preferable.

Reject answers that use more traffic as the cure for missing critical coverage, call confirmation formal authority, treat monitoring as prevention, or close the incident at patch deployment.

Run a release tabletop before exposure

Seat a release operator, service owner, evaluator, platform owner, security representative, privacy representative, and domain fixture owner. The Agentic AI Engineer presents question, stage, contracts, trace, budgets, and stop map.

Round one: the p95 latency soft trigger fires but no effect is ambiguous. Participants decide hold, reduce, or continue from the predeclared rule. Round two: the primary stop owner does not acknowledge. The backup must authenticate and execute. Round three: a response is lost after commit. Participants freeze retry and reconcile. Round four: the monitor is unavailable. Participants decide whether independent effect-ledger signals suffice or the stage stops.

Observe authority confusion, missing commands, inaccessible evidence, and vocabulary mismatch. Time each transition. Correct the runbook and repeat the failed round. A tabletop without control execution is orientation; the drill requires the actual synthetic gate, revoke, cancellation, and verification paths.

Tabletop packet

Provide only what each role needs: release question, stage scope, trigger card, safe trace view, effect reconciliation query, control commands, authority map, contact route, and incident template. Sealed evidence access remains separate. Avoid distributing broad credentials in the name of preparedness.

Tabletop success

The team detects the trigger, names incident owner, stops new effects, verifies containment, classifies in-flight effects, rejects blind retry, distinguishes rollback from compensation, and assigns correction evidence. If any of these depend on one person’s memory, update the packet.

Durable knowledge and volatile adapters

Durable principles are minimum exposure, named questions, stable controls, consequence-specific gates, structural effect restriction, reachable stop authority, reconciliation of ambiguity, one retry owner, explicit residuals, preserved failure, verified correction, and retirement as a valid decision.

Volatile details include deployment services, product monitors, current system cards, provider trace defaults, alert products, model behavior, quotas, prices, and organizational contact systems. Pin and date them in adapters. The cited OpenAI monitoring report and system cards are provider-specific cases, not portable assurance.

NIST AI RMF 1.0 and the Generative AI Profile support lifecycle risk identification, measurement, documentation, ownership, management, and improvement at a broad level. AI RMF 1.0 is voluntary, non-sector-specific, and under revision as of the source check; the profile is cross-sector and not agent-specific authorization. Neither prescribes this runtime, certifies FieldOps, or replaces domain governance.

Audit the release packet

An independent audit samples one passed stage, one held stage, one stop drill, and the retry incident.

For the passed stage, trace question to hypothesis, control, exposure, observations, gate computation, authority, and decision. Verify that the decision never exceeds the promotion ceiling.

For the held stage, verify unsupported evidence remains visible and routing excludes that segment. A hold should not disappear from the executive summary.

For the stop drill, invoke primary failure and backup response. Confirm effect capability is absent after reduction, stale workers are denied, new assignments stop, and in-flight work is listed. A control-plane log without effect-ledger verification is incomplete.

For the incident, trace trigger to authoritative duplicate record, containment, reconciliation, direct mechanism, contributing conditions, correction objective, failing fixture, passing replay, artifact changes, residual risks, and bounded re-release. Verify no sensitive payload was added to general telemetry.

The auditor also searches for forbidden shortcuts: broad release dates presented as gates, rollback claims for committed effects, shadow credentials, untested backup authority, averaged critical failures, code-only correction, and implicit promotion.

Chapter checkpoint

You should now be able to explain why agent release is an exposure design problem rather than a deployment percentage. You should be able to name the question, select the smallest stage, freeze a control, bound actions and effects, define a gate, prove a stop path, and choose promote, hold, reduce, rollback, repair, or retire.

You should be able to respond to a retry storm without blaming the model or blindly repeating an ambiguous action. Detection starts from authoritative effect and tail evidence. Containment stops new effects and preserves safer modes. Reconciliation classifies every semantic intent. Repair assigns one retry owner and stable identity. Verification reproduces the old defect, passes the correction and adjacent cases, updates the dossier, and begins again at bounded exposure.

You should also be able to defend what this chapter does not prove. A canary pass does not cover unseen tasks. A monitor does not eliminate misconduct or authorize surveillance. Confirmation does not transfer organizational authority. Synthetic FieldOps evidence does not establish real service, customer, safety, or domain readiness. Some effects remain irreversible; compensation carries new consequence.

Handoff to Chapter 18

AR-12 v1.0.0 freezes local release semantics for the next chapter. It records candidate and control versions, approved exposure vector, stage questions and gates, capability/effect ceilings, authority bindings, stop triggers, degradation levels, reconciliation rules, incident schema, verified correction, residual limits, and current disposition.

Chapter 18 may place tools, context services, or remote agents behind protocol adapters. It may not treat protocol conformance, discovery metadata, or a remote capability claim as permission to widen exposure. The adapter must preserve AR-12 semantics locally:

• the same approved action and effect classes;
• the same identity, tenant, and authority bindings;
• the same cancellation, timeout, retry, idempotency, and reconciliation rules;
• the same trace and effect evidence requirements;
• the same budgets, cohort ceilings, and degradation states;
• the same reachable stop mechanisms and organizational handoffs.

If a protocol cannot express a field, the local adapter retains it. If a remote component cannot verify a required effect or honor cancellation, reduce autonomy or reject the capability. If capability metadata changes, close the release gate until compatibility is tested. Interoperability does not surrender semantics.

The final disposition for FieldOps is deliberately bounded: CONDITIONAL_GO for five approval-bound synthetic reservation effects in the North fixture after the corrected replay and stop drill. Shadow remains held for one unsupported segment. Bounded cohort and broad release are not authorized. No real effect, credential, system, person, or equipment is in scope.

That is enough. Release engineering succeeds when the next uncertainty is answered at minimum exposure, stop authority remains reachable, consequences are reconciled honestly, and incidents leave the system more testable than they found it. Broader exposure is a future decision, never the implied reward for finishing the chapter.