Harborlight People is a fictional workforce-management SaaS company. Its employer customers use the platform for payroll, scheduling, employee relations, support, and access administration. They can also configure a workflow through which current and former workers request copies of their personal data.

The employer customer defines the request policy, the source categories in scope, and who may make the final release decision. Harborlight operates the software and a managed privacy-operations team under that customer-defined policy. The process in this story is Harborlight's fictional design, not a universal legal requirement.

Harborlight handled about 3,800 worker-data requests per month. Most looked simple from the request portal: prove who you are, describe the employment period, wait while the records are assembled, and collect a package from an authenticated portal.

The work behind that path was not a single database query.

A worker might have a legal name, a preferred name, a former surname, several email addresses, and more than one worker identifier after a rehire or contractor conversion. A support ticket might mention a person without being about that person. An attachment might be linked to a ticket whose requester and uploader were neither its subject. A fixed join could recover the obvious records. It could not reliably resolve every free-text reference, copied attachment, or derived record.

That was why Harborlight built Lumen, a bounded AI privacy worker. Lumen read case-scoped records through narrow adapters, resolved aliases and free-text references, proposed which records concerned the requester, explained the evidence behind each proposal, and suggested redactions. Lumen could produce candidates. It did not own a person's stable identity, record-subject truth, case policy, approval, delivery credential, or the release of bytes.

Mara Chen, the Senior Privacy Operations Specialist responsible for defining request scope and resolving ambiguous record matches, supervised the managed workflow. Under each employer's policy, she could approve an exact release.

The distinction sounded conservative enough: Lumen proposed; Harborlight decided.

How a verified worker normally receives an export​

The normal journey crossed four responsibility groups:

1. A worker authenticated in Harborlight's request portal and opened a case.
2. The case service bound the employer tenant, requester, configured purpose, approved source categories, employment period, and current case status. Mara reviewed that scope and permitted candidate discovery.
3. Case-scoped adapters retrieved records and versioned metadata. Lumen proposed record inclusion and redactions from stable identifiers, aliases, references, attachments, and contextual evidence.
4. Redaction and export services built a candidate package inside an encrypted case staging area.
5. A delivery service published an approved immutable package version into a protected worker-portal namespace.
6. The portal reauthorized each read, and the worker received the package or an explicit ambiguity or delay notice.

Source permission answered whether a service could read a tenant, record class, or time range. Lumen's semantic judgment answered whether a record was a plausible candidate. Release authorization was a different question: whether the exact bytes in the package could go to the exact current recipient for this case and purpose.

The effect boundary was the component that made those bytes available outside Harborlight's internal review path.

The design the team trusted​

Harborlight's implementation looked like a careful separation of duties.

The request portal and privacy-operations console were React applications. A NestJS service called privacy-case-api stored cases in PostgreSQL. A Python lumen-worker ran in Temporal workflows on Amazon EKS. Case-scoped adapters could read only the approved tenant and source categories in the employer's HR database, payroll service, scheduling service, support index, access logs, and versioned S3 attachments.

A controlled PostgreSQL identity graph mapped typed, versioned identifiers across those systems. It treated primary_subject, mentioned_person, requester, author, approver, and manager_of_subject as different relationships instead of collapsing them into one person_id.

Separate containers ran the redaction service and export-builder. Candidate packages went into encrypted S3 prefixes isolated by case. A notification service could contact only the verified address or portal subject on that case. OpenTelemetry traces and an append-only event store recorded the workflow.

Each component enforced a narrow policy:

• Search could read only the current employer tenant, the approved source categories, and the approved employment period.
• Lumen received case-scoped source access, never a general publication or portal credential.
• Redaction ran under a versioned policy.
• export-builder could write only inside the requester's isolated case prefix.
• Notification could contact only the verified recipient bound to the case.
• The portal authenticated the recipient and checked access to the case package.

The initial human approval covered the purpose and discovery scope: which tenant, sources, and period the workflow could inspect. Lumen's selected candidate set then flowed into redaction and packaging as if selection had also established eligibility for release.

The package record stored the case and recipient. It did not store an authoritative record-subject decision for every included source. The delivery service checked the case and recipient before publication, but it did not ask which evidence allowed every source record's bytes to reach that recipient.

The team's mental model was reasonable:

Source read, package staging, and protected publication are each least-privileged. The workflow assembled from them is therefore least-privileged.

There was no broad email tool, public object-storage credential, or model-controlled portal session to make the flaw look obvious.

Tuesday at 09:00​

At 09:00, Jana Li, a verified former worker and the intended recipient, authenticated, completed Harborlight's fictional identity-verification flow, and opened case PR-2048 for her former employment.

At 09:18, Mara approved candidate discovery across payroll, scheduling, support, and access logs during Jana's employment period. She approved a search scope, not an exact package that did not yet exist.

At 09:31, Lumen loaded Jana's stable HR person ID, former worker ID, legal name, former surname, email history, and known source relationships. It began candidate discovery through the scoped adapters.

At 09:44, an allowed support ticket produced an ambiguous lead. The ticket contained “J. Li” and linked a versioned salary-adjustment attachment. It was in the correct employer tenant, an approved source category, and the relevant period. Its structured requester and attachment uploader did not identify the person the attachment described.

The attachment concerned Jian Li, a different current employee in the same tenant with a different stable person ID and worker ID.

At 09:46, Lumen combined name similarity, topic, date, and organizational context. It proposed that the attachment concerned Jana. That was a plausible semantic mistake, not an invented identity merge and not a bypass of a source control.

At 09:49, the support adapter correctly returned the allowed ticket and attachment. The redaction service removed bank details under its configured rule. It retained Jian's salary and performance explanation because the service assumed that candidate eligibility had already been established upstream.

At 09:55, export-builder correctly wrote the package into Jana's encrypted case prefix. The package stayed inside the correct tenant and case.

At 10:02, the delivery service confirmed that PR-2048 was open and that Jana's portal subject was its recipient. It published the package and sent a notification. Every local policy decision returned allow.

At 10:11, Jana authenticated in the portal and opened the exact package prepared for her case. Alongside her own records, she found Jian's salary-adjustment attachment. The bank details were gone. Jian's salary and performance explanation were not.

Jana reported it.

The package had reached the correct verified person. It contained the wrong person's sensitive employment data.

The ordered path was all green until the outcome:

1. Jana's identity was valid. That proved she could receive a package authorized for Jana; it did not prove every candidate concerned her.
2. The case scope was valid. That proved the tenant, sources, period, and purpose were approved; it did not define an exact release object.
3. Search authorization was valid. That proved Lumen could read the attachment as a candidate; it did not permit Jian's bytes to go to Jana.
4. Redaction was locally valid. That proved configured fields were removed; it did not prove the remaining record belonged in Jana's case.
5. Export storage was valid. That proved the package stayed in Jana's isolated case area; it did not authorize every byte inside it.
6. Portal authorization was valid. That proved Jana opened the case package; it did not prove that package was safe for Jana.

Six green checks and one unowned relationship​

At 10:36, Elias Ward, the Staff Security Engineer responsible for Harborlight's data-release control plane, joined the source, Lumen, redaction, export, and portal logs.

The trace was unusually complete. It proved which workload had called each adapter, which policy version had run, where the package had been written, and which authenticated portal subject had opened it.

It could not answer the question Elias cared about:

Which authoritative evidence permitted bytes derived from Jian's attachment to become available to Jana?

No component owned that relationship.

The first proposed fix was to improve entity resolution. The team could add more identifiers, tune Lumen's prompt and evaluator, raise a confidence threshold, and retrieve metadata before content. All were useful improvements. None repaired the authority boundary.

Suppose Lumen reached 99.9% accuracy on Harborlight's evaluation set. The remaining rare false inclusion would still travel automatically from allowed search, through allowed redaction and allowed case storage, to an allowed recipient. Model accuracy changed how often the system proposed a dangerous package. It did not change who was allowed to release it.

Elias redrew the workflow as a graph of reachable effects instead of a list of tool scopes.

Search alone could reveal records only inside Harborlight's case workflow. export-builder alone could stage only a case package. Protected publication and portal serving alone could expose only the package bound to Jana's case. Composed as read → stage → publish/serve, the three narrow permissions created a broader capability: select protected source bytes and make them available to a person. Notification changed discoverability; because email was only a locator, it was not the content-release permission.

No local credential had widened. The reachable path had.

That made the next control question unavoidable.

Harborlight had authorized each edge locally. It had not authorized the whole path from a protected source record, through transformations and staging, to the exact released bytes and authenticated recipient.

The rule Elias wrote at the top of the incident document was shorter:

Permission to find a record is not permission to release it, and three narrow permissions do not make a narrow path.

A candidate was not a subject decision​

The Jana/Jian collision exposed another overloaded word: “match.”

Lumen had matched text and context to Jana's case. It had not changed Harborlight's stable person identifiers. Nor had it established that the attachment's role relative to Jana was primary_subject rather than mentioned_person, requester, or no supported relationship at all.

For structured records, Harborlight could consume typed, versioned relationships from the domain that owned them. Core HR owned its person and worker identifiers. A payroll domain could own an explicit payroll-subject relationship. Object storage owned an attachment's bytes and version, but its folder did not establish who the attachment was about.

For unstructured “aboutness,” no universal automatic table existed. Lumen could supply a candidate relationship, confidence, rationale, conflicts, and stable source reference. Deterministic policy could reject known tenant or person contradictions. Where evidence remained uncertain, the workflow needed an explicit AMBIGUOUS_REVIEW state and Mara needed the canonical metadata, not only Lumen's summary.

Names, email addresses, and similarity scores remained evidence. They did not become stable subject keys because they looked convincing.

Harborlight also stopped reducing eligibility to SUPPORTED or reviewerApproved. A relationship assertion described how evidence connected a record to a person; it did not itself decide what this case and purpose could release. A separate typed ReleaseEligibility recorded the policy rule and version, ALLOW | DENY | UNKNOWN | CONFLICT, reviewer and rationale when needed, and whether the decision covered a whole immutable record, named fields or byte ranges, or one exact transformed output. Multi-subject records could therefore be partly eligible. Generated filenames, cover pages, summaries, archive metadata, previews, and redacted output carried lineage and eligibility too.

Approval had to name the effect​

Mara had approved a legitimate case and reasonable discovery scope. Asking her to “review more carefully” would repeat the same defect if the review screen still described a general intent instead of an exact future release.

Harborlight stopped calling several different records one “envelope.” It defined them separately:

• ReleaseProposalV1 was an immutable body containing schema and canonicalization versions; case, tenant, requester, recipient, purpose, and source scope; exact source and evidence versions; relationship assertions; typed, scoped release-eligibility decisions; transformation and redaction versions; immutable package object version, payload digest, length, media type, and package-format version; destination, channel, and validity constraints. It contained no digest, approver, receipt, nonce, or mutable status.
• The canonicalizer encoded that body as UTF-8 using RFC 8785 JSON canonicalization plus Harborlight's ReleaseProposalV1 schema. SHA-256 covered those exact canonical bytes. The schema defined omitted and default values; unknown fields, duplicate keys, aliases, non-canonical numbers, and unsupported versions failed closed.
• A separate ApprovalReceipt named the proposal digest, schema and canonicalization versions, approver and role, approval time, expiry, one-use nonce, and decision. The approval store separately owned current APPROVED, REVOKED, SUPERSEDED, RELEASING, or SPENT state and its revision.
• A ReleaseReceipt later recorded the operation, proposal and payload digests, immutable object version, gateway workload, task and tenant, employer-policy decision and revision, configured recipient subject, destination, publication event and result, and time. An AccessReceipt recorded the authenticated portal subject, proposal and payload digests, exact object version, served range and byte count, and whether access completed or stopped.

The reviewer UI and gateway deserialized the same canonical proposal bytes. Mara saw the exact package content—or a complete, byte-accounted rendering of it—rather than only Lumen's summary. Her approval attested to the separate proposal digest.

Approval of “process Jana's request” no longer authorized any package the workflow later assembled. It authorized one proposal, one evidence snapshot, one immutable package version, one recipient, one purpose, one redaction implementation, one delivery channel, and one validity window.

Adding or replacing a record was material. So was changing a source version, subject decision, redaction policy, payload, recipient, destination, or delivery channel. A material change moved the case to REAUTHORIZE unless an explicit reviewed policy said that particular change was immaterial.

The digest protected equality after Harborlight defined and canonicalized the fields. It did not prove that a relationship inside the proposal was true. A perfectly hashed mistake was still a mistake.

The proposal, complete review rendering, receipts, and preview also became sensitive derived artifacts. Harborlight had to restrict and monitor access to them, encrypt them, apply configured retention and deletion, and avoid copying raw records into logs just to make an audit convenient.

The release boundary in code​

Before the incident, publication code treated storage inside an approved case as sufficient evidence:

// Tempting: the package inherits release authority from its case.
async function publish(packageId: string, session: PortalSession) {
  const pkg = await packages.load(packageId);
  await cases.requireOpenForRecipient(pkg.caseId, session.subject);
  return delivery.publish(pkg.stagedObject, session.subject);
}

// Correct: reserve current authority, then publish one immutable version.
async function publishApproved(cmd: ReleaseCommand, caller: WorkloadIdentity) {
  await workloads.requireReleaseWorker(caller, cmd.taskId, cmd.tenantId);

  const proposalBytes = await proposals.loadCanonicalBytes(cmd.proposalId);
  const proposal = ReleaseProposalV1.decodeStrict(proposalBytes);
  const canonicalBytes = canonicalizeV1(proposal);
  const proposalDigest = sha256(canonicalBytes);
  const approval = await approvals.loadReceipt(proposalDigest);
  const approvalState = await approvals.loadCurrent(approval.nonce);
  const currentCase = await cases.load(proposal.caseId);
  const currentPolicy = await policies.load(proposal.tenantId);
  const object = await packages.headVersion(proposal.package.objectVersion);

  if (!bytes.equal(proposalBytes, canonicalBytes) ||
      approval.proposalDigest !== proposalDigest ||
      approval.schemaVersion !== proposal.schemaVersion ||
      approval.canonicalizationVersion !== proposal.canonicalizationVersion ||
      approval.decision !== 'ALLOW' || approval.expiresAt <= clock.now() ||
      approvalState.status !== 'APPROVED' ||
      !currentPolicy.canApprove(approval.approver, approval.role) ||
      currentCase.recipientSubject !== proposal.recipientSubject ||
      object.version !== proposal.package.objectVersion ||
      object.digest !== proposal.package.digest ||
      object.length !== proposal.package.length ||
      object.mediaType !== proposal.package.mediaType ||
      object.formatVersion !== proposal.package.formatVersion) {
    return cases.moveTo('REAUTHORIZE');
  }
  if (proposal.outputs.some((o) => o.eligibility.decision !== 'ALLOW')) {
    return cases.moveTo('AMBIGUOUS_REVIEW');
  }

  // One transaction authenticates policy authority, compares every current
  // revision, and moves this one-use nonce APPROVED -> RELEASING.
  const reservation = await releaseLedger.reserve({
    operationId: cmd.operationId, taskId: cmd.taskId, caller,
    proposalDigest, approval, approvalState, currentCase, currentPolicy,
    objectVersion: object.version, destination: proposal.destination,
  });
  if (!reservation.acquired) return cases.moveTo(reservation.nextState);

  // operationId makes publication retry-idempotent. Readers remain denied
  // until the ledger and ReleaseReceipt say this exact version is RELEASED.
  try {
    const publication = await delivery.publishImmutableVersion({
      operationId: cmd.operationId, objectVersion: object.version,
      proposalDigest, recipientSubject: proposal.recipientSubject,
      destination: proposal.destination,
    });
    return releaseLedger.confirmReleased(
      reservation, ReleaseReceipt.from(publication)
    );
  } catch {
    await reconciliation.enqueue(cmd.operationId);
    return cases.moveTo('RELEASE_PENDING');
  }
}

async function serve(grantId: string, session: PortalSession, range?: ByteRange) {
  const grant = await releaseLedger.loadReleased(grantId);
  const currentCase = await cases.load(grant.caseId);
  if (session.subject !== grant.recipientSubject ||
      session.subject !== currentCase.recipientSubject) throw new Deny();
  await portalPolicy.authorizeCurrentRead({grant, currentCase, session, range});
  return portal.streamExactVersion(grant.objectVersion, range, AccessReceipt.record);
}

The reservation was the authorization point, not a check followed by an unrelated write. In one authoritative operation-ledger transaction it authenticated the Harborlight release workload, preserved the employer-policy context, compared current case, policy, approval, recipient, evidence, redaction, destination, channel, and object revisions, and conditionally spent the single-use nonce. The workload acted under the employer's configured policy; it was not Jana, it did not receive her token, and this design had no further multi-hop delegated actor.

Object storage and the ledger did not share a transaction. Publication therefore used the operation ID as an idempotency key and the exact immutable object version named by the proposal. A timeout, successful object write followed by receipt failure, or uncertain response moved the case durably to RELEASE_PENDING. Reconciliation checked object visibility, serving-key/grant state, and any ReleaseReceipt before completing or retrying; it never blindly republished. Readers remained denied until the control plane marked that exact version RELEASED.

Harborlight chose protected publication. At publication, the gateway placed one immutable encrypted version into a protected namespace and emitted a ReleaseReceipt bound to the configured recipient subject. That was not proof Jana had authenticated or read it. The portal rechecked the current release grant, case, recipient binding, and revocation state on every full or range read, served only that object version without archive regeneration, re-encoding, redirects, share links, or CDN substitution, and emitted an AccessReceipt for actual bytes served. Notification was only a locator.

Approval could be correct when Mara clicked and stale when publication began. The atomic reservation closed replay and the authorize-then-publish race for current control-plane state; idempotent publication and reconciliation closed uncertain completion. Revocation stopped future reads or destroyed the serving key for an unretrieved package, but Harborlight did not claim it could retract bytes already served. Partial and interrupted ranges remained in access receipts.

A fail-closed gateway introduced an availability dependency. Missing policy, lineage, labels, proposal bytes, receipt, current approval state, exact object version, or gateway availability moved the case durably to AMBIGUOUS_REVIEW, REAUTHORIZE, or RELEASE_PENDING. No operator or service could fall back to the old delivery path or publish directly from staging. A future break-glass route would have to be a separate, dual-controlled effect with its own exact proposal, short-lived authority, receipts, and post-event review.

Two designs Harborlight could defend​

The incident did not produce a perfect identity graph or perfect data-flow labels. It left Harborlight with two credible architectures and different operating costs.

Design A: protected publication​

In the protected-publication design, source adapters returned versioned records, typed relationships where available, and provenance metadata. Lumen proposed candidates, relationship types, evidence, conflicts, and redactions. Deterministic policy created case- and purpose-specific ReleaseEligibility decisions, rejected known contradictions, and sent UNKNOWN or CONFLICT to AMBIGUOUS_REVIEW; no confidence threshold converted a proposal into authority.

The versioned transformer created one write-once package and complete output lineage, including generated metadata. The manifest service created ReleaseProposalV1. Mara reviewed the unresolved evidence, exact output, and proposal. The approval store issued a separate expiring receipt for its digest.

At publication, an authenticated release workload supplied task and operation IDs. data-release-gateway recomputed equality, verified the exact object version, rechecked current case state, employer policy, scoped eligibility, source and redaction versions, recipient, destination, channel, expiry, and current approval state, then atomically reserved the nonce and revisions. It alone held publication authority. Idempotent publication and reconciliation handled the non-transactional object-store boundary; the portal separately authorized and receipted exact-version access.

This design concentrated enforcement immediately before final release. It was legible to reviewers and could be introduced without teaching every source system a complete shared label language.

It was not free. Harborlight's fictional operating model had previously completed 86% of requests without ambiguous-match review. The corrected path sent an additional 9% of all cases to review and raised median completion time from 11 to 19 hours. Source changes caused reapproval. Proposals, renderings, receipts, and previews added sensitive data to govern. The gateway and reviewer queue became availability and capacity dependencies.

Those numbers describe Harborlight, not an industry baseline.

Design B: closed-world continuous information-flow enforcement​

In the continuous design, source adapters attached tenant, subject or relationship, classification, purpose, version, and provenance labels wherever authoritative evidence existed. Lumen could propose a new relationship, but the proposal stayed explicitly untrusted until policy or review resolved it.

Harborlight first declared a closed world of typed transformations and mandatory mediated sinks: redaction, OCR, summaries, archives, filenames, previews, logs, caches, notification bodies, protected publication, and portal service. These interfaces preserved input references, labels, transformation and policy versions, and output digests; uninstrumented connectors and outputs were denied. UNKNOWN was absorbing across joins and transformations until an explicit deterministic rule or scoped human decision resolved it. Lumen could not declassify its own output.

A deterministic controller evaluated every edge inside that declared boundary. Covert and unmodeled channels remained outside the claim, not silently assumed safe. The final exact-byte gateway from Design A still bound the immutable object version, recipient, case, purpose, destination, and expiry.

This design could reject a forbidden path earlier and maintain policy across more than one sink. Its cost moved outward. Every connector and transformation needed a shared relationship and provenance model. Labels were incomplete. Propagation through unstructured content was difficult. Conservative rules rejected some valid records. Connector integration, false rejection, and policy maintenance became permanent operating work.

Continuous enforcement did not promise perfect taint tracking or stand alone as a universal solution. It made unknowns explicit, denied new connectors without the contract, and added earlier defense around the same protected-publication boundary.

Both designs kept an ambiguity state. A system that silently omitted every uncertain record might prevent this disclosure while still failing the product obligation to deliver a complete, usable export or a clear ambiguity response.

The tests that separated a completed task from a safe one​

Before the incident, Harborlight's strongest visible success signal was a completed package opened by the verified requester. The incident satisfied that signal.

The new evaluation harness graded eight questions independently for each trial:

1. Candidate retrieval: Did Lumen propose the relevant records without drowning review in false candidates?
2. Scoped release eligibility: Did current evidence and policy permit every included whole record, field/range, transformed output, and generated metadata item for this requester, case, and purpose?
3. Redaction correctness: Did prohibited fields or third-party content remain in an otherwise eligible record?
4. Approval equality: Did the executed proposal, immutable object version, recipient, purpose, source versions, redaction policy, channel, and expiry equal what Mara approved?
5. Execution-time authorization: Were the workload, case, policy, recipient, eligibility, proposal, current approval state, and single-use reservation still valid at publication?
6. Prohibited-byte outcome: Did any unauthorized byte become available through a package, preview, archive, cache, link, or alternate channel?
7. Task outcome: Did the requester receive a complete, accessible export or an explicit ambiguity response?
8. Evidence reconstruction: Could Harborlight join source version, Lumen rationale, eligibility, policy or review, approved proposal, publication receipt, served bytes, and authenticated recipient without retaining bearer tokens or complete exports in logs?

Task completion never compensated for a prohibited-byte failure.

The fault matrix included namesakes, former names, rehires, reassigned email, quoted names, multi-subject and partially releasable records, reviewer error, OCR collisions, conflicting attachment metadata, and generated filenames, cover pages, summaries, and archive metadata. It changed source objects, scoped eligibility, redaction versions, recipients, purposes, channels, policy versions, approval status, and expiry after review.

Canonicalization property tests permuted field order and exercised omitted/default values, Unicode, aliases, duplicate and unknown keys, schema and canonicalization versions, and every material field. Release tests used a receipt for the wrong proposal, replayed or concurrently reserved nonces, wrong-task/tenant/deployment/purpose workloads, cancellation after approval, policy change during reservation, publication-before-pickup revocation, recipient rebinding, duplicate workers, receipt-write failure, and retry after uncertain publication.

Serving tests substituted an object under the same case and package ID, rolled back versions, regenerated archives, introduced post-check transformations and stale CDN/cache content, and issued partial and range requests. Closed-world tests omitted labels, joined multiple inputs, and exercised OCR, summaries, previews, logs, archives, notification-derived output, and newly deployed connectors. Dependency timeouts, stale control-plane caches, partial outages, and operator bypass attempts had to land in the named fail-closed states without making the old delivery path reachable.

The harness tested ALLOW, DENY, and explicit review outcomes. It also failed designs that denied every ambiguous record and quietly called the export complete.

Harborlight measured review rate and queue age, decision dwell time, false inclusion and exclusion, safe completion latency, reapproval, gateway availability, temporary-artifact lifecycle, audit reconstruction, accessible completion, cost per safely accepted export, bulk/override rate, reversal, and reviewer disagreement. Admission control protected a staffed queue-age objective, with forecasted capacity and a second-review escalation pool. Saturation returned an explicit delay or ambiguity notice; it did not raise a confidence threshold, enable bulk approval, or reopen direct staging publication. Retrieval quality remained a model metric. It no longer stood in for release safety.

The question Elias used next​

Elias tested whether the team had learned a privacy-export trick or a general authority model.

A manufacturing company's procurement agent could read purchase orders and supplier master data, write a settlement proposal to an internal case store, and ask a payment service to schedule an approved settlement. Each tool was narrow.

While resolving an invoice discrepancy, the model linked a valid factoring notice to the wrong supplier account. It proposed the correct amount to a different payee. A human had approved only “resolve the invoice discrepancy.”

Elias asked four questions:

1. What composed path turned read and proposal permissions into a payment capability?
2. Which authoritative evidence had to bind supplier, invoice, and payee?
3. What exact proposal had to bind supplier, invoice, amount, currency, payee, evidence versions, purpose, and expiry?
4. Which deterministic settlement boundary had to stop or execute the payment after checking the current world?

“Narrow the scopes,” “ask accounts payable,” and “improve the match” were useful supporting actions. None answered all four questions.

The surface had changed from employment data to supplier settlement. The rule had not:

A model may propose the path. Only a deterministic boundary with current, effect-specific authority may open the sink.

Where release authority lives​

The incident sequence showed how six correct local decisions formed an unauthorized path. The final topology separates proposal, evidence, approval, and effect ownership, and shows the direct path from Lumen or staging to external delivery as blocked.

The responsibility ledger for that topology is:

1. Source adapters own versioned retrieval and source provenance; they do not authorize delivery.
2. Employer domains and the controlled identity graph provide stable identifiers and typed relationship evidence where available; uncertainty stays explicit.
3. Lumen proposes candidates, linkage evidence, conflicts, and redactions; it cannot approve its own relationship or release bytes.
4. Deterministic policy and Mara's ambiguity review resolve supported, rejected, and unresolved relationships.
5. The manifest service produces versioned canonical ReleaseProposalV1 bytes and governs the sensitive proposal and review-rendering lifecycle.
6. The reviewer UI renders the exact proposal/output; the approval store issues a separate ApprovalReceipt and owns current revocation, supersession, reservation, and spend state. Approval evidence is not a delivery credential.
7. An authenticated Harborlight release workload carries task, tenant, purpose, and operation identity under the employer-policy context; it does not impersonate Jana.
8. data-release-gateway revalidates current authority, atomically reserves the one-use nonce and revisions, idempotently publishes the exact immutable object version, reconciles uncertain results, and emits a ReleaseReceipt. It alone owns publication authority.
9. The authenticated portal reauthorizes every read and range for the current grant, case, recipient, and exact object version, then emits an AccessReceipt for actual bytes served.
10. Audit and evaluation join source version, Lumen rationale, eligibility, policy, reviewer, proposal, approval, workload, publication, bytes served, and recipient while minimizing retained sensitive content.

Harborlight could now prove more than who called every tool. It could explain why the exact bytes released were authorized for the exact person who received them—or stop in ambiguity when it could not.

Harborlight People, Lumen, Jana Li, Jian Li, Mara Chen, Elias Ward, case PR-2048, the incident, and all operating metrics are fictional. The workflow is a customer-configured product design, not a universal statement of legal requirements. Technical grounding includes Anthropic's 2026 containment report, OpenAI's 2026 source-to-sink agent design, the NIST Privacy Framework, NIST SP 800-53 Rev. 5, NIST Digital Identity Guidelines, W3C PROV, OWASP authorization guidance, OWASP IDOR prevention, OWASP logging guidance, RFC 8707 resource indicators, and RFC 9396 rich authorization requests. These sources support system principles; they do not describe Harborlight, its incident, its metrics, or one universal privacy process.

Northstar Ledger (a fictional B2B commerce-infrastructure company) routes checkout and inventory updates for regional grocery chains. Its customers do not run one Northstar checkout page. They use Northstar behind their own mobile apps, self-checkout kiosks, and delivery sites.

At the Saturday peak, those systems send roughly 48,000 order operations per minute. A short outage creates queues. An incorrect recovery can create something worse: orders accepted through a path that the company no longer believes is authoritative.

Northstar stored checkout state in an Amazon Aurora PostgreSQL global database. The primary Region served writes. A secondary Region stayed ready for disaster recovery. The operating rule was strict: Northstar could advertise only the writer confirmed by Aurora's current topology.

Imani (the Staff Reliability Engineer responsible for Northstar's database-recovery control plane) had spent the previous six months reducing the time between an incident page and a safe recovery decision.

Her team built Relay, a bounded AI incident worker. Relay read approved telemetry, compared an incident with reviewed runbooks, and proposed a typed recovery plan. It could not promote a database or change traffic. A deterministic policy service checked every proposal. A human incident commander then approved the exact target and the maximum tolerated data loss before any effect was allowed.

This mattered because Relay was useful precisely where incidents were messy. It could gather replication lag, recent deployments, health probes, and runbook constraints in seconds. It could explain why one recovery target fitted the evidence better than another.

It could not make an ambiguous cloud operation unambiguous by thinking harder.

How a checkout normally reaches the writer​

Before looking at the failover, it helps to place Relay beside the customer path. A shopper's request normally passes through Northstar's regional endpoint and order services before Aurora accepts the write. Relay is not in that request path. During an incident, it feeds a separate recovery control path that can change the Aurora writer and the Route 53 target serving future requests.

The recovery path they trusted​

The system around Relay looked cautious.

The incident console was React. A NestJS service called incident-api assembled the request. A Python relay-worker called the language model and returned a typed proposal, not free-form shell commands.

A Temporal workflow on Amazon EKS owned the recovery sequence. Temporal activity workers sent heartbeats while they ran. Kubernetes Leases helped the team identify the current controller. PostgreSQL stored the incident, plan, policy result, and approval. A separate NestJS service called effect-gateway owned the AWS credentials and exposed narrow RDS and Route 53 operations.

No Relay worker held a general AWS credential. AWS STS minted short-lived credentials for the gateway's adapters. OpenTelemetry joined traces across the workflow, and CloudTrail recorded AWS API activity.

That was a competent design. The team had durable state, bounded tools, least-privilege credentials, deterministic policy, and a human approval gate.

The recovery activity still contained one quiet mistake. The naive workflow placed the promotion and its follow-on Route 53 update inside one coarse, heartbeating recoverRegion activity. That allowed overlapping activity attempts to perform both effects. If traffic had been a later workflow-scheduled activity, worker A could not have advanced to it independently after the first activity timed out.

When Temporal retried an activity, that attempt generated a fresh request key. The gateway checked whether the caller was permitted to invoke the adapter, but it did not keep one authoritative record for the logical promotion. It also did not reject an old worker by workflow epoch.

The team's mental model was:

Temporal remembers the step. Kubernetes knows which worker is current. If a call fails, retrying the activity will either recover the result or safely perform the same work.

They had discussed duplicate requests. They had not designed for a request that succeeded elsewhere while leaving no answer locally.

Saturday at 02:13​

At 02:12, the primary Region developed a network impairment. Checkout latency climbed. Health probes disagreed by source Region. Replication lag to the secondary remained inside Northstar's approved emergency loss bound, but the primary was becoming unreachable from enough application nodes to threaten the order queue.

At 02:13:00, Relay assembled the evidence. Its proposal named the secondary cluster, measured lag, included Northstar's digest and observation time for the Aurora topology snapshot, and stated the maximum loss bound. It recommended the reviewed regional-promotion runbook.

The proposal was correct.

At 02:13:18, Darius (the incident commander with authority to approve database recovery) reviewed the evidence and approved that exact digest. He did not approve “fix checkout.” He approved one target under one stated loss envelope.

The policy service accepted it. The Temporal workflow recorded it. Activity worker A began the promotion.

At 02:13:24, worker A's recoverRegion handler created local request key attempt-a and called the RDS adapter through effect-gateway. The gateway sent the approved promotion request to AWS.

At 02:13:27, AWS accepted the promotion and returned an acknowledgement to worker A's handler. Before the handler could persist that receipt or report its activity result to Temporal, its connection to Northstar's control services failed. The acknowledgement survived only in the still-running process's memory.

The workflow history now contained an honest fact: no result had been recorded.

It did not contain another honest fact: the promotion had already crossed Northstar's boundary and AWS had acknowledged it to the isolated handler.

At 02:13:33, Temporal's configured activity heartbeat timeout expired. Under the activity's retry policy, Temporal scheduled another attempt, which worker B polled. Independently, Northstar's controller Lease expired and B became the current controller. Neither mechanism terminated worker A's local activity handler.

At 02:13:40, worker B loaded the durable workflow history, saw the missing activity result, and created request key attempt-b. Its first Northstar-cached topology observation was stale: it still named the impaired original cluster as writer. Following the recovery code, B retried the coarse activity and prepared a “hold on the known writer” traffic fallback toward the original cluster.

The replacement worker was not ignoring the checkpoint. It was following it.

At 02:13:46, Aurora's authoritative topology identified the secondary cluster as the writer. The original promotion had happened. The missing response had concealed an accepted effect, not a failed one.

At 02:13:50, worker A's still-running recoverRegion handler regained control-service connectivity and continued to its embedded Route 53 call. It submitted change A-184, pointing checkout to the newly promoted secondary cluster. Temporal could reject A's late activity completion; it could not undo an external call the handler had already made. Nothing at effect-gateway rejected A's next action as stale.

Worker A and worker B now held different beliefs about the same recovery:

• worker A held the unpersisted AWS acknowledgement and intended to point traffic to the newly promoted secondary cluster;
• worker B held a stale snapshot naming the impaired original cluster as writer and intended to point traffic back there.

Both could still begin a new Route 53 action.

At 02:14:22, after change A-184 had left provider processing, Route 53 accepted B's sequential change B-771, pointing the same record back to the original cluster. At 02:21:08, after joining Aurora's writer topology with both change records, the incident commander approved repair change R-009 toward the promoted secondary. Route 53 processed the three batches in submission order; Northstar's contradictory controllers, not Route 53, had created the oscillation.

Long-lived application connections did not all move when DNS changed. Some clients held existing pools while others resolved the newer target. Checkout moved to the promoted secondary, back toward the impaired original cluster, then finally to the authoritative writer.

Aurora did not casually create two managed-database primaries. Its topology converged on one writer. The incident was in Northstar's recovery control plane: two workers were allowed to issue traffic-changing effects from different beliefs about that topology.

The checkout target changed Regions three times. The order service placed 11,842 operations into its retry queue. A total of 1,906 shoppers saw a temporary checkout warning.

At 02:23, the workflow reached a green terminal state. Aurora was healthy. The final traffic target matched the final writer. The top-level recovery dashboard called the run successful.

The customer path had still been unsafe.

Three histories, all telling the truth​

Imani did not start with the model transcript. She put three timelines side by side.

The first was Relay's proposal history. It showed the evidence Relay had used, the chosen secondary, Northstar's observed-topology digest and timestamp, the loss bound, and Darius's approval digest. Nothing in it explained the oscillation. Relay had recommended the right action.

The second was Temporal's durable workflow history. It showed the coarse recoverRegion activity scheduled, worker A's heartbeat loss, no recorded receipt, a timeout, and a replacement attempt. That record was also correct.

This was state persistence and checkpointing+: the workflow had preserved its own progress well enough to resume. A checkpoint could say what had been scheduled, observed, or recorded. It could not prove what AWS had done after the request crossed the network.

The third was external authority. Aurora's current topology established which cluster was the writer. CloudTrail later corroborated that the original API call reached AWS. Route 53 held three sequential change resources, each with its own status and timestamps. Those records showed effects the workflow had not understood when it retried.

The contradiction disappeared once the team stopped asking which history was wrong.

They were histories of different things.

The phrase from the design review—“durable means exactly once”—finally sounded as dangerous as it was.

Exactly-once semantics+ can exist inside a stated boundary when the participants cooperate through atomic state changes, deduplication, or idempotency. Temporal could durably record and replay workflow history. PostgreSQL could make one ledger transition atomic. Neither mechanism could silently include an arbitrary AWS operation that had already crossed the network.

The timeout meant only this: Northstar did not know the result yet.

The key had named the attempt​

The code review made the first bug painfully small:

// Tempting: every retried activity invents a new intent.
async function promoteActivity(plan: ApprovedPlan) {
  return effectGateway.promote({
    ...plan,
    requestKey: crypto.randomUUID(),
  });
}

// Correct boundary: allocate this record once, before dispatch.
async function resumePromotion(operationId: string, epoch: number) {
  const op = await operations.get(operationId);

  switch (op.status) {
    case 'CONFIRMED':
      return op.receipt;
    case 'DISPATCHING':
    case 'UNKNOWN':
      return reconcileWithAws(op);
    case 'AUTHORIZED':
      return effectGateway.dispatch({
        operationId: op.id,
        parameters: op.parameters,
        approvalDigest: op.approvalDigest,
        topologySnapshotDigest: op.topologySnapshotDigest,
        topologyObservedAt: op.topologyObservedAt,
        fencingEpoch: epoch,
      });
    default:
      return stopForReview(op);
  }
}

An idempotency key+ should identify one logical operation, not one transport attempt. Reusing a stable identity gives a cooperating receiver the chance to recognize a repeat within its documented scope and retention window. Generating attempt-b told the gateway that worker B had brought new intent.

But replacing randomUUID() with a stable value was not the whole fix.

Not every provider operation exposes the same idempotency or lookup contract. The RDS promotion path still needed reconciliation against Aurora's current topology and AWS evidence. Route 53 returned a change ID that Northstar could persist and poll from PENDING to INSYNC. Each adapter needed to respect the destination's actual contract.

An idempotency key could help suppress a duplicate dispatch. It could not tell Northstar whether an unobserved operation had completed, whether the world had changed since approval, or whether an old worker was still alive.

An operation could be unknown​

Imani's team added a PostgreSQL operation ledger in a failure-independent Region. Before any effect, the workflow created one stable operation_id and bound it to:

• the exact effect type and target;
• a canonical digest of its parameters;
• the policy version and approval digest;
• Northstar's digest and observation time for the Aurora topology snapshot;
• the current workflow epoch;
• any AWS request, audit, resource, or change identifiers returned later.

The ledger did not force every operation into SUCCEEDED or FAILED. A normal dispatch could confirm directly; an ambiguous one branched into an explicit uncertainty state:

PROPOSED → AUTHORIZED → DISPATCHING → CONFIRMED
                                  ↘ UNKNOWN
                                      ├→ CONFIRMED
                                      ├→ SUPERSEDED
                                      └→ MANUAL_REVIEW

It also allowed REJECTED before dispatch. SUPERSEDED and MANUAL_REVIEW were resolved outcomes for an uncertain operation, not mandatory stops on the successful path.

UNKNOWN was not an error message. It was a statement about evidence. The call might have failed before leaving Northstar. It might have been accepted and still be running. It might have completed while its response disappeared. Until reconciliation established more, all three remained possible.

For an unknown promotion, the replacement worker did not manufacture a new logical operation. It read Aurora's current global-cluster topology, joined CloudTrail and request evidence where available, checked the intended target, and recorded the observation time. Only then could it confirm the original operation, retry under the same safe identity when the contract allowed it, supersede it, or stop for manual review.

The next action faced a second barrier. Before changing traffic, the workflow re-read topology, policy, and approval. Northstar's topology digest supported this changed-world check; it was not an RDS ETag, resource version, or atomic API precondition. The checkpointed plan remained valuable historical evidence. It was not present authority.

The team gave each Route 53 change a separate operation identity. The gateway stored the returned change ID and polled GetChange. PENDING meant AWS had accepted a change that had not yet propagated. INSYNC established propagation through Route 53's authoritative DNS servers. Northstar still required regional DNS-resolution checks and connection-pool turnover before declaring the customer path complete.

A lease was not a fence​

The Kubernetes Lease had done its job. It helped the cluster choose worker B after worker A stopped sending heartbeats.

It had not revoked worker A's memory, stopped its process, cancelled an in-flight AWS request, or told Route 53 to reject its next call.

Northstar added a monotonically increasing fencing token+—called a fencing epoch in the implementation—to every claimed dispatch. The gateway atomically claimed the tuple {operation_id, epoch, effect} in the ledger. After a successful claim, the gateway—not the worker—owned that dispatch. A newer epoch prevented another claim but could not cancel a call already claimed or sent; an ownership change during dispatch moved the operation to UNKNOWN for reconciliation.

When worker B took epoch 240, a later request from worker A carrying epoch 239 was rejected at the gateway.

That boundary was deliberately narrow:

• it stopped a stale worker from initiating a new effect through Northstar's gateway;
• it did not cancel a request already sent to AWS;
• it did not turn Aurora or Route 53 into participants in Northstar's transaction;
• it did not remove the need for provider request IDs, topology checks, or reconciliation.

Workers still received no general RDS or Route 53 credentials. If a worker could bypass the gateway, the fence would be a number in a log rather than an enforced safety mechanism.

The system they took back to review​

The corrected design separated four ownership boundaries.

The human and incident interface contained the React console, incident-api, Relay's evidence, and the incident commander's exact approval.

The AI analysis and durable workflow boundary contained the Python relay-worker, Temporal, Kubernetes controller election, and versioned activity workers on EKS. Relay proposed. Temporal remembered orchestration. The Lease helped choose a current controller. None of them owned AWS truth or enforced the effect fence.

The operation control and evidence boundary contained the failure-independent PostgreSQL ledger, deterministic policy service, effect-gateway, reconciliation workers, OpenTelemetry, and CloudTrail correlation. This was where stable operation identity, current epoch, approval binding, and effect evidence met.

The AWS data and traffic boundary contained Aurora's authoritative topology and Route 53's asynchronous change resources. Northstar observed those systems through their own contracts rather than treating its last checkpoint as a copy of them.

The recovery rule became simple enough to print beside the incident console:

Resume the task from durable history. Reconcile an uncertain effect with its authority. Revalidate the world before beginning the next effect.

Simple did not mean cheap.

The tests that cared how it finished​

The original dashboard evaluated the end state: was Aurora healthy, was one writer present, did the workflow finish, and did checkout recover?

Those questions still mattered. They were not enough.

Imani added Trajectory vs end-state evaluation+. End-state evaluation checked where the system finished. Trajectory evaluation checked the observations, approvals, dispatches, policy decisions, and prohibited intermediate transitions used to get there.

The test environment repeatedly injected the failures that ordinary happy-path tests hid:

• drop the provider response after dispatch;
• terminate a worker before it persists an external receipt;
• stop heartbeats, start a replacement, then wake the old worker;
• duplicate or delay audit events;
• change topology between approval and dispatch;
• deploy a new worker build while an old execution remains open;
• leave a Route 53 change PENDING longer than expected;
• let an operator modify the same recovery resource.

Deterministic graders checked one stable promotion intent, no new stale-epoch dispatch, and no completion without authoritative evidence. Every UNKNOWN operation had to become reconciled or explicitly escalated. The final writer and traffic target had to agree. A run failed if traffic made a prohibited transition, even when the final dashboard was green.

Model evaluation ran separately. Relay was graded on evidence classification, loss-bound extraction, and plan proposal. Improving those scores could not compensate for an unsafe effect trajectory.

Across Northstar's 1,200 fictional fault-injection trials, every unknown operation either reconciled to authoritative evidence or stopped in MANUAL_REVIEW; zero stale-epoch dispatches crossed the gateway. None were converted into a fresh logical promotion merely because a response was missing.

The result that mattered most was also the least attractive on a status slide: safe write resumption became slower.

What the safety cost​

The previous path optimized for recovery time. If the first call truly had failed before reaching AWS, an immediate replay was fast.

The new path deliberately paused to establish external truth. During ambiguous cases, Northstar kept checkout read-only for another 45 to 90 seconds. More orders entered a queue instead of receiving an immediate answer.

The team now operated a failure-independent control database, an effect gateway, provider-specific reconcilers, epoch management, and richer evidence retention. A damaged control store could delay recovery. A conservative precondition could send an incident to a human even when an automatic action would have worked.

Operations accepted that cost because the alternative spent correctness without measuring it. Product accepted it because a visible “please retry” message was recoverable. Conflicting order histories were not.

The design did not promise exactly-once cloud effects. It promised something more testable:

• one stable intent;
• explicit uncertainty;
• no new action from a stale owner;
• no completion claim without evidence from the system that owned the result.

The question Imani used next​

The incident changed how Imani reviewed every durable agent.

For a payment gateway, she asked what happened when capture succeeded but its response disappeared.

For a secret-rotation worker, she asked which credential actually existed when a checkpoint and the target account disagreed.

For a deployment agent, she asked whether the approved plan still described the cluster after a human changed it during a pause.

The surface changed. The review question did not:

If this worker wakes with no answer, what proves whether the outside world already acted?

A durable workflow can remember where its computation stopped. It cannot remember a fact it never received.

That fact has to be recovered from the authority that owns it.

The production topology​

The incident sequence earlier showed when Northstar's histories diverged. The final deployment view shows where each responsibility lives, and lets the reader switch between the failed path and the corrected control boundary.

Northstar Ledger, its people, its incident, and its metrics are fictional. Technical grounding: AWS guidance on idempotency and retries in durable execution, Kubernetes Leases, the Amazon RDS global-cluster failover API, Route 53 change batches, Route 53 change status, and resource freshness validation. These sources establish technical behavior and boundaries; they do not describe the fictional incident.

Ashvale Benefits (a fictional employee-benefits administration company) helps mid-sized employers manage health-plan enrollment, eligibility rules, and employee policy questions. It had eleven days before its busiest open-enrollment season.

The company had built an AI support assistant inside its member portal. The assistant was supposed to answer routine questions from each employer’s approved policy handbook, show the supporting section, and hand uncertain cases to the support team.

During open enrollment, that team expected eighty thousand questions. Most would be some version of the same thing: Does my plan cover this? When does coverage begin? Which form do I need?

The business goal was simple. Answer the routine questions immediately. Send the hard ones to a human. Never invent a benefit that did not exist.

There was one more rule from legal: every answer had to point to the policy section that supported it.

The obvious shortcut​

Rhea (the AI engineer leading the assistant project) was responsible for taking that system from an internal demo to production. Her service sat behind the member portal, received an employee’s question and plan details, called a language model, and returned either an answer or an escalation to a human agent.

The base model wrote clear answers, but it did not know Ashvale’s plans. The company had 4,800 approved question-and-answer pairs from past enrollment seasons. They were clean, reviewed, and already written in the support team’s voice.

Training on those examples felt like the shortest path. If the model did not know the handbook, teach it the handbook.

Rhea removed personal data, balanced the common and rare question types, and held back 600 examples for evaluation. Two days later, the new model looked much better:

• answer accuracy rose from 71% to 93% on the held-back set;
• the required JSON shape passed 99.6% of the time;
• answers were shorter and matched the support team’s tone;
• the model stopped recommending forms from other plan families.

The team called that a launch candidate.

The phrase they kept using was: “Now the model knows our policies.”

That sentence survived every review.

The answer from last week​

On Friday afternoon, legal approved a policy amendment. New spouses would become eligible after 30 days, not 60. The document team published version 7.4 of the handbook and archived version 7.3.

On Monday morning, a support analyst ran the launch checklist.

Question: I got married last month. Can I add my spouse now?

Assistant: Spouses become eligible after a 60-day waiting period. See section 8.2 of the Ashvale Standard Plan handbook.

Section 8.2 did not say that anymore.

Worse, the answer looked excellent. It was direct. It used the approved tone. It included a citation-shaped sentence. Nothing in the wording signalled that the fact was stale.

Rhea tried the question twelve ways. Nine answers used 60 days. Two avoided a number. One used 30 days but cited the wrong section.

The launch dashboard still showed 93% accuracy because its questions came from version 7.3—the same policy era as the training data.

The model had passed the test it was given. The product had failed the test the business cared about.

What had actually changed​

Rhea’s manager asked a blunt question.

“We replaced the handbook on Friday. Why is the assistant still reading the old one?”

It was not reading either handbook.

The training run had changed the model’s weights. The old examples had influenced statistical patterns inside those weights. There was no row Rhea could update from 60 to 30, no source record she could inspect, and no reliable pointer from an answer back to the training example that shaped it.

That was the distinction Rhea had missed: parametric knowledge and non-parametric knowledge+ are stored differently.

The fine-tuned model held knowledge implicitly in its parameters. The handbook was explicit knowledge outside the model. Rhea had copied some of the handbook’s patterns into the parameters, then mistaken that process for connecting the model to the handbook.

Fine-tuning can teach facts. It is not physically incapable of doing so. But learning a fact from examples is not the same as maintaining a current, inspectable source of truth. Coverage can be uneven. Updates require more training. Provenance is weak. Old and new facts can compete.

Ashvale’s problem was not “make the model speak differently.” It was “answer from whichever policy is active for this employee today.”

That reframed RAG versus fine-tuning+.

Fine-tuning had been useful for behaviour: tone, response shape, and when to escalate. The changing policy facts needed a different path.

Two pipelines, not one training run​

The team stopped asking the model to remember the handbook.

They built an indexing pipeline and a query pipeline+.

Ashvale already ran its customer-facing services on Amazon EKS. The member portal was React. A NestJS service called assistant-api handled questions. Versioned policy PDFs lived in Amazon S3, PostgreSQL held plan and policy-version metadata, and a dedicated OpenSearch domain held searchable policy sections. A Python worker called policy-indexer prepared each new handbook.

The indexing pipeline ran when the document team published a policy. It extracted each approved section, attached the tenant, plan, version, and effective dates, then stored a searchable representation. Publishing version 7.4 created new records and retired the old records. It did not retrain the model.

The query pipeline ran for every question. It identified the employee’s plan and date, searched only the active policy records, and placed the best matching passages beside the question.

Expand diagram ↗

The model still generated the prose. But it now generated with current evidence in the request. That pattern was retrieval-augmented generation+.

Rhea’s first implementation was deliberately boring:

async function answerPolicyQuestion(input: PolicyQuestion) {
  const activePolicy = await policyVersions.findActive({
    tenantId: input.tenantId,
    planId: input.planId,
    asOf: input.asOfDate,
  });

  const evidence = await openSearch.search({
    index: 'policy-sections-v1',
    query: input.question,
    filters: {
      tenantId: input.tenantId,
      planId: input.planId,
      policyVersion: activePolicy.version,
    },
    limit: 5,
  });

  if (!hasEnoughEvidence(evidence)) {
    return escalate('No active policy passage supports an answer');
  }

  const answer = await model.generate({
    instructions: [
      'Answer only from the supplied policy passages.',
      'Cite the source ID after every policy claim.',
      'If the passages do not answer the question, say so.',
    ],
    question: input.question,
    evidence,
  });

  return citationsResolveToEvidence(answer, evidence)
    ? answer
    : escalate('The answer contains an unsupported citation');
}

The important line was not model.generate. It was the refusal before it and the check after it.

Ashvale did not accept “the model probably knows” as evidence. Each policy claim had to connect to a retrieved, active passage. That connection was grounding+.

Grounding did not make the model truthful by definition. The search could retrieve the wrong section. The model could misread the right section. A citation could point to a passage that did not actually support the sentence.

So the team tested the pieces separately. Could the system retrieve the correct active section? Given that section, did the answer stay within it? Did every citation resolve? Did no-evidence questions escalate?

The second launch review​

By Thursday, the updated-policy test set had 240 questions. Half depended on a recent policy change. The other half were designed to catch accidental regressions on stable rules.

The numbers were less pretty than the original 93%, but more useful:

• 91% of questions produced a correct answer supported by the active policy;
• 7% escalated because the retrieved evidence was weak or conflicting;
• 2% failed and stayed blocked from launch for investigation;
• every displayed citation resolved to a versioned policy section.

The spouse question now returned 30 days and linked to version 7.4, section 8.2. When the team marked version 7.4 inactive in a staging test, the assistant did not quietly fall back to 7.3. It escalated.

That behaviour cost them something.

Median response time rose from 720 milliseconds to 980. The 99th percentile rose by almost a second. Each answer consumed more input tokens. The team now operated a document parser, an index, freshness alarms, access filters, and two evaluation suites. A bad effective date could hide the right policy even when every other component worked.

The fallback also sent more conversations to humans. Legal considered that a feature. Finance saw a higher support cost.

Both were right.

What Rhea kept from the fine-tune​

The team did not throw the fine-tuned model away.

It still followed Ashvale’s response format better than the base model. It used the right tone. It made cleaner escalation decisions. Those were changes in behaviour, and the training examples were good evidence for that behaviour.

The policy text remained outside the model, where it could be versioned, filtered, inspected, and replaced.

That was the answer Rhea carried into the next design review:

If the knowledge changes, retrieve it. If the behaviour changes, fine-tune it. If both change, combine them—but keep the source of truth outside the weights.

The rule was not absolute. It was a better starting question than “Which AI technique should we use?”

The architecture they took to production​

The lifecycle view earlier in the story showed when the indexing and query pipelines ran. For the final design review, Rhea also needed a deployment view that answered a different question: where does each responsibility live?

The member and legal portals remained user-facing systems. The Python policy-indexer and NestJS assistant-api ran inside the Amazon EKS cluster. Versioned documents, publish events, active-version records, and searchable vectors lived in managed data services. Embeddings and generation crossed a separate AI API boundary.

Ashvale Benefits, its people, and its metrics are fictional. Technical grounding: the original RAG paper, research on fine-tuning with new factual knowledge, and an empirical study of groundedness in retrieval-augmented generation.

Kiteframe Pay (a fictional payment-risk infrastructure company) helps online marketplaces decide whether a card order should be approved, declined, or reviewed by a human. Merchants call Kiteframe during checkout, before they capture money or promise inventory to a shopper.

Most orders never need generative AI. Deterministic rules settle obvious cases in under 80 milliseconds. The difficult eight percent—new devices, unusual delivery patterns, sparse account histories—enter Aster, Kiteframe's AI-assisted risk analyst.

Aster was not a chatbot and could not approve a payment. It gathered approved evidence, used a language model to produce a typed risk recommendation with cited signals, and passed that recommendation to a deterministic merchant-policy engine. Without Aster, those ambiguous orders went to a manual-review queue. During a large sale, that queue could grow faster than Kiteframe's analysts could empty it.

At 02:13 on Tuesday, model latency rose sharply. Seven minutes later, Kiteframe's entire checkout success rate had fallen from 99.4% to 71%.

The model provider was recovering.

Kiteframe's retries would not let it.

Where AI sits in a checkout​

Mina Rao (the Principal Reliability Engineer responsible for Kiteframe's risk-decision platform) began the incident by drawing the useful path, not the failure. One merchant request entered risk-api. A bounded Python worker assembled evidence. The model returned a schema-constrained recommendation. A policy service—not the model—owned the payment decision.

The architecture below lets you switch between that normal journey, the amplification incident, and the protected design. The numbered explanation remains readable on a phone; full-screen mode exposes the production boundaries and zoom controls.

Three teams had each added a sensible retry​

Kiteframe's merchant-facing services ran on Amazon EKS. A NestJS checkout-api called risk-api; a Python risk-agent assembled device, account, and merchant evidence; and an internal AI gateway called the external model API. Envoy sidecars handled service-to-service networking. PostgreSQL held merchant policies. Amazon SQS held manual-review cases. OpenTelemetry joined an order ID to traces across the path.

Each component had been tested in isolation.

Three retry policies had accumulated over eighteen months:

1. checkout-api retried the whole risk evaluation once if it had no answer after 2.4 seconds.
2. risk-agent allowed three generation attempts because transient model failures were common during deploys.
3. Envoy retried selected connection resets and HTTP 503 responses once.

No team had intended twelve model calls. Yet the theoretical multiplication for one risk decision was:

2 whole evaluations × 3 agent attempts × 2 transport attempts = 12 provider requests

A retry+ is another attempt after a failure. The word “another” sounds harmless until several layers are each allowed to manufacture attempts for the same original work.

The policies also disagreed about time.

The merchant request had a four-second deadline. checkout-api spent 2.4 seconds before its retry. Each agent attempt allowed two seconds. Envoy knew nothing about either budget. A later layer could therefore begin work that had no chance of returning before the merchant had left.

At the model boundary, Kiteframe's 2-second timeout+ stopped its local wait. It did not prove the provider had stopped computing. Cancellation was not propagated through every hop, and some requests had already entered the provider's queue. Their tokens continued to consume capacity even though Kiteframe would discard the late answers.

That distinction changed the arithmetic. The dashboards counted timed-out calls as finished client work. The provider still counted them as admitted inference.

The autoscaler made the breaker forget​

At 02:13, the provider's 99th-percentile latency rose from 1.1 seconds to 5.8 seconds and some requests returned 503. Kiteframe was receiving roughly 390 AI-routed orders per second.

By 02:16, it was starting more than 3,400 provider requests per second. The exact amplification varied because some calls completed and not every response qualified for every retry. The direction did not vary:

• queues increased latency;
• latency crossed more local timeouts;
• timeouts created more attempts;
• those attempts deepened the queues.

The recovery mechanism had become a retry storm+.

The team believed it already had a circuit breaker+. After twelve failures, each risk-agent pod opened its local breaker and stopped calling the model for thirty seconds.

Then Kubernetes did exactly what Kiteframe had configured it to do. CPU and in-flight work rose, so the Horizontal Pod Autoscaler expanded the deployment from 24 pods to 78. Each new pod started with an empty memory and a closed breaker. It admitted model traffic while older pods were rejecting it.

The breaker had protected one process. The dependency was being attacked by a fleet.

At 02:18, the provider restored enough capacity for about 2,200 request starts per second. Kiteframe was still offering far more. A health chart turned green for forty seconds, then red again as delayed retries and new pods arrived together.

Mina stopped the autoscaler at 78 replicas. That prevented another wave of fresh breaker state, but it did not establish which layer owned retries or how much work the fleet was permitted to admit.

The trace looked like a tree, not a request​

The incident review began with one order, ord_81K2.

Its root trace had two risk.evaluate spans. Beneath them were six generation spans. Transport telemetry showed eleven provider request starts; one connection had failed before Envoy could send a body. Four model requests finished after their parent spans had timed out. Two produced identical valid recommendations that nobody read.

Nothing in Aster's reasoning caused the outage. The prompts were valid. The tool evidence was current. The typed responses passed schema validation.

AI was still load-bearing in the incident because model inference was the scarce, slow, externally scheduled work being amplified. Replacing the model with a database call would have changed the cost and latency profile. It would not have fixed retry ownership.

Mina's first rule for the repair was therefore architectural:

One customer intent gets one deadline and one retry budget. Crossing a boundary does not create more of either.

One place was allowed to try again​

Kiteframe moved model-attempt policy into the AI gateway. The other layers stopped retrying generation.

risk-api created an absolute deadline and an attempt budget when it accepted the order. risk-agent inherited them. Envoy retries were disabled for the model cluster. The AI gateway could make one additional attempt only for a narrow set of transient failures, only when budget remained, and only when enough deadline remained for the result to be useful.

The delay used capped exponential backoff+. Its maximum grew after a failure. The actual wait used full jitter+, choosing a random delay below that cap so every pod did not wake on the same boundary.

async function generateRiskRecommendation(ctx: DecisionContext) {
  // Allocated once at ingress; inherited by every downstream hop.
  const budget = ctx.retryBudget;
  const deadline = ctx.deadline;

  while (budget.tryConsumeAttempt()) {
    const remainingMs = deadline.remainingMs();
    if (remainingMs < MIN_USEFUL_ATTEMPT_MS) break;

    const permit = await aiAdmission.tryAcquire({
      merchantId: ctx.merchantId,
      deadline,
    });
    if (!permit) break;

    try {
      return await model.generate(ctx.prompt, {
        signal: deadline.abortSignal(),
        timeoutMs: Math.min(1_600, remainingMs),
      });
    } catch (error) {
      if (!isTransient(error) || !budget.canRetry()) throw error;
      const capMs = Math.min(200 * 2 ** budget.attemptsUsed, 1_200);
      await sleep(Math.random() * capMs, deadline.abortSignal());
    } finally {
      permit.release();
    }
  }

  return degradedDecision(ctx);
}

The abort signal made cancellation explicit through Kiteframe's own code. It still could not guarantee that a remote provider would erase already-admitted work. The gateway therefore treated cancellation as a capacity hint, not as proof of zero downstream cost.

A breaker for the destination, not the pod​

The repaired gateway maintained one logical model-destination policy across its replicas. A Redis-backed token bucket enforced a fleet-wide concurrency ceiling and fair per-merchant admission. If Redis was unavailable, the AI path failed closed into degraded mode instead of silently admitting unbounded inference.

The breaker's closed, open, and half-open states+ now described the gateway's relationship with the model destination:

• Closed: admit calls up to the concurrency limit and measure outcomes.
• Open: admit no normal calls; return degraded decisions immediately.
• Half-open: after a cooldown, allow at most twenty probes per second across the fleet. Successful probes closed the circuit gradually; failures reopened it.

This design introduced coordination cost. Redis became part of the admission path. Shared state could be delayed. A breaker threshold could open during a brief provider wobble and reject work that might have succeeded.

Kiteframe accepted those costs because the alternative allowed every new pod to rediscover the same outage by spending provider capacity.

The fallback needed its own capacity model​

Opening the breaker did not make risk disappear.

For established merchants and low-risk returning shoppers, the policy engine could use a stricter deterministic rule set. New or conflicting identities went to SQS for human review. Checkout displayed a pending-review state instead of pretending an AI recommendation existed.

That was a fallback, or degraded response+: a deliberately reduced service when the preferred path was unavailable.

The first version was operationally unsafe. It could enqueue 390 cases per second while the review team could resolve only 42. A “successful” fallback would merely move the outage to tomorrow's queue.

Product, fraud operations, and reliability set an explicit degraded-mode budget:

• deterministic policy could approve only a reviewed low-risk segment;
• the manual queue admitted cases until its projected age reached forty minutes;
• after that bound, remaining ambiguous checkouts received an honest retry-later response;
• large merchants received fair shares so one flash sale could not consume the whole review team.

During the next provider impairment, 404 ambiguous orders per second reached Kiteframe. The gateway capped provider starts at 520 per second. When the breaker opened, only twenty global probes per second tested recovery. Checkout remained available for deterministic decisions, while 31,406 orders entered review and 6,218 received retry-later responses.

Conversion for the affected segment fell 4.8%. Fraud operations worked an elevated queue for three hours.

Those were not footnotes to the technical solution. They were the price of keeping the system inside known capacity while its preferred intelligence was unavailable.

The production path after the incident​

Switch the architecture to Protected path to see the final ownership boundaries. The most important component is not the retry loop. It is the single admission point before expensive inference, backed by a deadline that still represents the merchant's request.

What Mina carried into the next review​

A timeout says, “this caller stopped waiting.” It does not say, “the work stopped.”

A retry can improve availability when the failure is transient, the operation remains useful, and one layer owns the policy. Repeated independently across a call graph, it can turn a partial provider impairment into a platform outage.

A circuit breaker protects the boundary where it observes and rejects work. If every autoscaled process owns a fresh breaker, the fleet may have no breaker at all.

And a fallback is not free availability. It is another production system with a quality limit, a queue, and a finite team behind it.

BrambleGrid is a fictional grid-asset inspection company. Regional electric utilities hire it to combine drone imagery, asset records, and certified field inspection so scarce crews visit pole-top equipment that most needs a closer look.

A drone could photograph thousands of connector assemblies in a morning. A physical visit was different. It needed access coordination, a qualified crew, and enough time to perform the same close-range inspection protocol on every asset. BrambleGrid had capacity for 240 flexible visits per week. Twenty always remained reserved for manual safety reports that did not come from a model.

That made field inspection both an operating resource and an evidence resource.

BrambleGrid's ML-assisted product was called Spanwatch. For one recent connector evidence snapshot, Spanwatch estimated the probability that a protocol-C3 inspection within seven days would find an actionable connector condition. It did not predict an outage, and it could not authorize a repair.

Dalia Moravec (the ML reliability engineer responsible for calibration, evaluation cohorts, and launch recommendations) owned Spanwatch's model evidence.

Jon Ibarra (the field-inspection planning lead responsible for the weekly 240-visit capacity ledger) owned which proposed visits entered the field workflow.

Mara Venn (the lead asset-integrity engineer responsible for protocol-C3 adjudication and label revision) owned the final condition record. A utility duty engineer—not Spanwatch, Dalia, Jon, or Mara—separately decided whether to restrict or repair an asset.

The boundaries looked fussy until the week BrambleGrid tried to replace its model.

How one connector becomes evidence​

The journey matters because its handoffs prevent a fluent model score from quietly becoming an operational fact. Admission, physical visit state, condition adjudication, and utility action remain separate authorities; the evaluation can make a bounded claim only by retaining those handoffs.

Three things in that path were easy to collapse in conversation.

The score estimated what a C3 inspection would find. The condition label recorded what a completed C3 inspection did find. Between them sat a decision policy+: a versioned rule that combined the score, thresholds, capacity, and current context to choose inspect, review, or defer.

The threshold was not part of the model. A score did not spend a visit. A visit did not authorize repair. Repair did not prove that a connector would otherwise have failed.

Those distinctions were already reflected in BrambleGrid's implementation. Large images lived in restricted object storage, while small events carried evidence references. Point-in-time features fed two PyTorch models behind a scoring service. A Kotlin policy service owned thresholds. A PostgreSQL-backed FieldOps service and capacity ledger owned admission and visit state. A separate Condition Registry owned C3 observations and append-only revisions. Iceberg tables, dbt jobs, and MLflow identities supported evaluation.

The tool names were replaceable. The authority boundaries were not.

The safe way to test S5​

Spanwatch's production model was S4.

Each week, policy P17.4 divided the 240 flexible visits like this:

The threshold branch was deterministic: every connector satisfying 0.58 <= S4 < 0.86 entered the review band. The review desk could examine 500 review-band cases each week, but it could escalate at most 100 into the field budget. A reviewed case that did not receive a visit remained unobserved for the C3 condition target. It did not become CLEAR.

Dalia's candidate model, S5, detected a condition pattern on newer composite cross-arms that S4 often scored below 0.58. On BrambleGrid's older test data, S5 looked promising.

The team did not let it control field work immediately. For four weeks, S4 and S5 scored the same evidence snapshots, but only S4 entered P17.4.

That was a shadow evaluation+: the candidate produced predictions beside the live model without controlling the live action.

It was a competent safety choice. S5 could not unexpectedly consume field capacity. It could not delay S4's urgent inspections. It could not change a utility decision while the team was still evaluating it.

The team made one assumption that felt equally safe:

Because S5 cannot change production, the condition labels created during the shadow are neutral evidence for comparing S4 and S5.

That assumption survived the launch checklist.

The report that rejected S5​

Across four stable weeks, the locked eligibility register—the sampling frame—contained 40,000 unique eligible connector assemblies. In the team's matrix, screen positive meant only that a model scored the case at or above 0.58 and would send it toward the evidence-acquisition path. It did not mean the connector was faulty.

S4's policy created 880 protocol-C3 observations through the model-selected route:

The launch report performed a technically correct join between final C3 labels and the two score receipts.

S4 had selected all 880 visited cases in A and B. Of those, 472 were actionable:

S4 observed yield = 472 / 880 = 53.6%

Among the 720 visited cases in A that S5 also screened positive, 360 were actionable:

S5-positive observed yield = 360 / 720 = 50.0%

Fifty-three point six beat fifty.

The report concluded that S5 found no extra field value. The launch council rejected it and proposed raising S4's admission threshold, which would spend still fewer visits near the uncertain boundary.

Nothing in the arithmetic was fabricated. Every one of the 880 condition labels could be correct.

The problem was where the labels existed.

The sequence exposes the asymmetry the report hid: correct arithmetic over the S4-created cohort said nothing about the candidate-only region. Cell C's 800 connectors remained unknown, and later routine-route evidence could reopen that question without filling the original cohort.

The incumbent policy controlled label observability​

The deployment had created selective labels+: outcomes were observed for a non-random subset chosen by the existing score and policy.

S4 did not change whether a physical connector condition existed. It changed which conditions BrambleGrid paid to observe under protocol C3.

That distinction bounded the report.

Among connectors S4 selected for inspection, the S5-positive subset had lower observed actionable-condition yield. The result could describe those visited cases.

It could not compare an S4-controlled policy with an S5-controlled policy across 40,000 eligible connectors. S5's claimed value was in C—the exact cell where shadow mode prevented it from causing observations.

The sampling frame+ was the locked eligibility register of 40,000 connectors. Their point-in-time S4/S5 score receipts assigned them to A, B, C, or D; those attributes did not turn the observed subset into a different frame. P17.4 was the selection and observation design applied to the frame: it determined which connectors had a non-zero path to a model-route inspection. The 880 completed visits in A and B with final binary C3 labels were the observed cohort.

That vocabulary bounded the inference precisely. The 53.6% and 50.0% yields described subsets of the S4-selected observed cohort. They did not compare an S4-controlled policy with an S5-controlled policy over the 40,000-member sampling frame, because P17.4 created no model-route observations in C or D.

This was deeper than replacing missing values with zero. BrambleGrid had not done that. Its dataset correctly marked unvisited assets as unknown. The team had still overextended a valid narrow result into a release decision about a different action policy.

The proposed threshold increase made the mistake self-reinforcing. S4 would send fewer boundary cases into FieldOps. Those cases would produce fewer future C3 labels. A later candidate would be judged in an evidence world shaped even more strongly by S4.

What the annual route did—and did not—show​

BrambleGrid also operated a routine annual inspection program. It had its own selection policy, AR-2026.3, based on inspection age, route geography, access windows, and planned utility work. Many not-yet-due assets had no chance of inclusion. The annual route was selected, versioned evidence—not a random control group.

About two months after the launch review, visits under a successor route plan found actionable conditions on composite-arm connectors in the score region S5 had elevated and S4 had left alone.

That discovery mattered because it falsified the council's confidence that the S4-selected report had closed the question.

It did not retroactively label cell C.

Those later visits observed connector condition at a later time, under a different route version and outside the original seven-day target window. They did not prove that S5 was globally more accurate. They did not prove that any repaired connector would have failed. They told Dalia only that the omitted region deserved a valid evidence path.

The council withdrew its threshold proposal and asked a better question:

Which decision are we trying to make, and what observation policy would let us make that claim?

Dalia answered by reconstructing two exact worked counterfactuals. Each design would have had to be assigned at the original four-week frame lock, before the target labels were visible. The tables below are worked alternative outcomes for those predeclared designs, not measurements BrambleGrid collected after the annual-route discovery. Neither alternative actually ran during the incident, they could not both have shared one capacity ledger, and the old score receipts and cohort gained no labels from this reconstruction.

Worked counterfactual A: a sentinel frame​

If BrambleGrid had wanted to compare the S4-positive and S5-positive score regions across the declared four-week frame, it would have needed non-zero observation probability in every cell from the original frame lock.

The first worked design would have reserved 60 of the 240 weekly visits for a predeclared sentinel sample:

The sampling service would have created a keyed random order independently within A, B, C, and D before condition evidence was visible. Within each cell, every eligible connector would have had one equal inclusion probability. Geography and asset attributes could balance route execution only after that keyed order was fixed; they were operational attributes, not statistical sub-strata with separate inclusion probabilities or weights. A cancellation would have remained missing unless the system used the next pre-ranked case from the same cell before the seven-day window closed.

After four weeks, the exact worked counterfactual would have contained 240 completed sentinel visits:

Because the cell-level inclusion probabilities would have been known and non-zero, the evaluation could have accounted for the unequal sampling. For this declared frame, the worked estimate was:

S4-positive region yield = 46.0%
S5-positive region yield = 56.7%
difference               = +10.7 percentage points
approximate 95% range    = +6.0 to +15.3 points

This result would have changed the release discussion. It would not have proved that S5 was globally safer or would prevent more service events. The both-low D estimate remained especially imprecise: one worked actionable observation carried a large weight. The range described uncertainty under the locked sampling assumptions, not certainty about the future.

The design would have cost 60 lower-priority S4 review-band visits each week for four weeks—25% of all flexible capacity. Urgent inspections and the 20 manual/safety slots would have remained protected, but some incumbent boundary cases would have waited in the normal cycle. BrambleGrid would also have paid for more travel to apparently routine assets and waited through the final 48-hour adjudication window.

The sentinel would have answered a broad score-region comparison by buying broader evidence at the original frame lock.

Worked counterfactual B: expose only the disagreement​

In the reconstruction, Jon posed a narrower question:

Before comparing both models over the whole frame, can we learn whether cell C is valuable enough to keep investigating?

For that question, the second worked alternative was a disagreement canary+: a bounded live policy that would have acquired evidence where incumbent and candidate actions differed, had it been assigned at the original frame lock.

S4 would have remained the policy everywhere except cell C. Inside C, the system would have randomly selected 40 of roughly 200 eligible connectors each week for field inspection. Every selection would have carried its P17-CANARY.1 policy version and assignment probability.

After two weeks and the final 48-hour adjudication window, the exact worked counterfactual had 56 of 80 inspected C connectors as actionable:

local C yield          = 56 / 80 = 70.0%
compatible 95% range  = 59.2% to 78.9%

That result could have supported continuing, expanding, or stopping a bounded C-region rule. It could have rejected the statement that S5's exclusive region had produced no measured gain.

It could not estimate S5 in A or D. It could not detect a blind spot shared by both models. It could not establish whole-population precision, recall, calibration, safety, or future utility.

The canary would have cost 40 lower-priority S4 review-band visits each week. For two weeks, BrambleGrid would have operated mixed policies. If the canary had paused, new C admissions would have stopped, but already completed visits and labels would have kept their original canary receipts. Rollback could have restored future admission to P17.4; it could not have rewritten the evidence already created.

The counterfactual canary would have answered a local disagreement question faster by buying evidence only in C.

The two designs were alternatives, not layers of a universal fix, and neither was retroactively executed. If the original question had been “compare score-positive regions across the declared frame,” the sentinel would have fit. If it had been “is C worth bounded exposure before a broader comparison,” the canary would have fit. If field operations could not have accepted either capacity cost, “not enough evidence yet” would have remained an honest release decision.

The join had to remember who selected the label​

The old evaluation table joined two scores to a final condition. That was not enough. It lost the route that made the condition observable.

Dalia reduced the production receipt to a teaching shape:

type DecisionEvidence = {
  evidenceSnapshotId: string;
  s4: ScoreReceipt;
  s5: ScoreReceipt;

  policyId: string;
  capacitySnapshotId: string;
  selectionSource: 'S4' | 'manual' | 'annual' | 'sentinel' | 'canary';
  samplingFrameId?: string;
  assignmentProbability?: number;

  fieldVisit:
    | 'completed'
    | 'expired-unobserved'
    | 'cancelled'
    | 'not-selected';
  inspectionProtocolId?: string;
  conditionLabelVersion?: string;
};

The real receipt also retained connector lineage, evidence and feature versions, both calibrations, threshold branch, FieldOps case state, raw observation digest, adjudication, repair reference, delayed outcome contract, cohort version, and release decision.

The compact type carried the central rule: the evaluation needed the policy, frame, and assignment process that made a label observable.

An inner join from score rows to final labels could be technically correct and still erase every connector that never had a chance to produce a label. The corrected cohort began with all 40,000 frame members, then made completed, indeterminate, expired, cancelled, and not-selected visible before choosing any binary denominator.

Where each responsibility lives​

The incident sequence showed when the inference escaped the observed cohort and was generalized to its sampling frame. The production topology shows where the corrected responsibilities would live and lets the reader compare two counterfactual evidence designs anchored to the original frame lock.

Switching the visual changes the hypothetical observation policy, capacity receipt, and claim—not the systems that own visit state, condition evidence, or utility action. The Sentinel view spends 60 weekly slots across A–D for four weeks; the Canary view spends 40 weekly slots only in C for two weeks. They are alternative what-if deployments at the original frame lock, never simultaneous layers and never a way to write later discoveries into old labels.

The question Dalia used next​

The next model review was not about grid connectors. A warranty team wanted to evaluate a candidate that flagged battery packs the incumbent rarely sent to diagnostic teardown.

Dalia did not begin with the candidate's headline precision. She drew two score columns and asked who controlled access to the authoritative diagnostic label.

The domain changed. The review question did not:

Your candidate raises cases the incumbent always leaves untouched. In shadow mode, which outcomes can the candidate never create, and what evidence would you need before changing the live threshold?

A useful answer has five parts:

1. Name the incumbent policy that selects observations.
2. Mark the candidate-only disagreement region.
3. State which target remains unknown there.
4. Choose a bounded evidence-acquisition design and pay its capacity cost.
5. Limit the conclusion to the population and decision that design can support.

A shadow model can leave production unchanged while being graded on outcomes selected by the incumbent.

The safest release decision is not always “ship” or “reject.” Sometimes it is:

We have a result for the old policy's evidence. We do not yet have evidence for the policy we are being asked to approve.

BrambleGrid, Spanwatch, its people, incident, protocol names, data, and metrics are fictional. Technical grounding: the 2026 study “Discovery of an Artificial Intelligence Label Feedback Loop” shows that labels influenced by a deployed AI workflow can reverse the apparent comparison of a later model; the associated confidence-gated production workflow documents selective automatic action and human review; “The Selective Labels Problem” establishes why a prior decision policy can determine which outcomes become observable; and “Performative Prediction” provides the broader foundation for deployed predictions changing later evidence. These sources establish mechanisms and limits. They do not describe BrambleGrid or prove a grid-asset incident, queue collapse, outage, injury, or the superiority of S5.