02 · Follow one product

One fictional page, followed through.

The Lumen listing below is a fixture, not a merchant we fetched. The path is the proposed design. The names stay the same in later chapters so you can recognize them.

Fictional fixture Proposed path

The offer

A collector aimed at fictional src_lumen_web sees a Strata P5 1 TB listing, lst_lum_p5_1t_hs, from manufacturer mfr_corvane and brand brd_strata, in family fam_strata_p5. The page is capture cap_lum_0310. The HTML artifact is art_0310_html. An older mapping points the listing at itm_ssd_p5_1t, the variant without a heatsink. The page and a spec grid say the heatsink is present. That conflict is the point of the walkthrough.

Figure

What happens to one fictional Lumen capture before a reader can see it?

What happens to one fictional Lumen capture before a reader can see it? cap_lum_0310 stays evidence until acceptance. evt_0142 is the private listing-mapping correction. Readers see the listing only after a separate release is applied. A collector records the Lumen listing and the time the page was observed. The deterministic parser misses the heatsink field. The HTML artifact is kept. An optional model proposes a claim. A second model may advise. Neither accepts. A reviewer creates itm_ssd_p5_1t_hs. evt_0142 is listing_mapping.corrected, not a release. The product service may apply that private mapping. Readers see it only after a separately authorized release is applied. job fallback case advice accept private events still private later, separate release event allowlist STATE Capture cap_lum_0310 Fictional Lumen listing page SERVICE Deterministic parse pa_lumen_product@0.9.1 misses heatsink MODEL ACTOR LLM extraction Proposes a claim. Optional. MODEL ACTOR Advisory review Suggests. Cannot decide. PERSON Human decision dec_0141 Creates the heatsink variant DATABASE Accepted privately Facts and outbox commit together SERVICE Apply mapping privately evt_0142 is listing_mapping.corrected STATE Readers still see the old release A correction is not public GATE Authorized release Separate command and event SERVICE Apply the release Only this makes the change readable PERSON Reader sees the listing Only the released URL and fields

Takeaway. cap_lum_0310 stays evidence until acceptance. evt_0142 is the private listing-mapping correction. Readers see the listing only after a separate release is applied.

Text equivalent

  1. A collector records the Lumen listing and the time the page was observed.
  2. The deterministic parser misses the heatsink field. The HTML artifact is kept.
  3. An optional model proposes a claim. A second model may advise. Neither accepts.
  4. A reviewer creates itm_ssd_p5_1t_hs. evt_0142 is listing_mapping.corrected, not a release.
  5. The product service may apply that private mapping. Readers see it only after a separately authorized release is applied.

Status. Prototype walkthrough of a fictional fixture. The path is the proposed design, not a production trace.

Make the bytes durable before anyone interprets them

The collector does not ask the resolver to fetch the URL. It already holds the body. It asks for an upload, puts the bytes, and only then submits the capture. The receipt is the acknowledgement. Until that receipt exists, the collector must assume the system does not have the page.

The object write happens before the database transaction. The queue message happens after the commit. If the process dies between those steps, a sweeper retries the enqueue. A repeated submission with the same idempotency key and the same body goes through intake again and returns rcpt_0310. It is not delivered straight to the job queue. A different body under that key is a conflict, not a second receipt. The key is worker, native record, and captured_at. Receipts belong to the stable instance, not to a rotating client id.

Figure

What must be durable before the collector receives a receipt?

What must be durable before the collector receives a receipt? Store the artifact before the database commit. Enqueue only after that commit. A repeated submission returns through intake to the existing receipt and does not go straight to the queue. The collector declares the artifact checksum and receives an upload target. Object storage stores the bytes if that checksum is absent. That put is before the SQL commit. PostgreSQL then commits the capture, receipt and job row. The object store is outside that transaction. The API returns the receipt, then enqueues the job. A sweeper covers a crash between commit and enqueue. The same key and body re-enter intake and receive the existing receipt. They are not sent directly to the queue. declare put first then commit enqueue after via intake same receipt SERVICE Collector Holds bytes until receipt SERVICE Intake API Validates and returns the receipt OBJECT STORE Evidence store Put-if-absent before the commit DATABASE Resolver database Capture, receipt, and job row QUEUE · ASYNC Job queue Reference only, after commit STATE Same submission Same key and body STATE Existing receipt No second enqueue

Takeaway. Store the artifact before the database commit. Enqueue only after that commit. A repeated submission returns through intake to the existing receipt and does not go straight to the queue.

Text equivalent

  1. The collector declares the artifact checksum and receives an upload target.
  2. Object storage stores the bytes if that checksum is absent. That put is before the SQL commit.
  3. PostgreSQL then commits the capture, receipt and job row. The object store is outside that transaction.
  4. The API returns the receipt, then enqueues the job. A sweeper covers a crash between commit and enqueue.
  5. The same key and body re-enter intake and receive the existing receipt. They are not sent directly to the queue.

Status. Proposed intake flow (AW-02). The Pantry & Pour fixture cap_pp_feed_1011 is the deterministic stand-in. Not implemented.

Upload request, fictional

Explanatory excerpt, not a complete payload.

{
  "sha256": "a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192",
  "bytes": 233904,
  "media_type": "text/html",
  "capture_hint": "cap_lum_0310",
  "mode": "presigned",
  "source_id": "src_lumen_web"
}

The recorded response is upload upl_0310_html and a private object ref under ten_primary. The presigned target host in the fixture is a placeholder, not a live bucket. Full fields are on Artifact upload.

Receipt after the commit

Explanatory excerpt, not a complete payload.

{
  "receipt_id": "rcpt_0310",
  "capture_id": "cap_lum_0310",
  "status": "stored",
  "received_at": "2026-10-10T03:32:01Z"
}

Status 202 means stored, not resolved. received_at is processing time. The observation time on the later event is 2026-10-10T03:31:55Z.

Parsers propose. A rule or a person accepts.

The job names the capture. It does not carry the HTML. pa_lumen_product@0.9.1 is a parser adapter. It runs because it supports the page, and it misses the heatsink. The extractor model may propose a claim, with a locator, under prompt extract-listing@5. The reviewer model may advise on case rc_0007. Models only propose or advise. They cannot accept, publish, or hold a credential. The resolver accepts through an authorized deterministic rule or through a human decision. dec_0141 creates itm_ssd_p5_1t_hs and changes the listing so it references that item. The correction does not merge the two variants.

Figure

Who may propose, advise, or decide?

Who may propose, advise, or decide? The deterministic parser writes claims when it supports the artifact. The extractor model only proposes. The reviewer model only advises. A person decides an uncertain identity. A stored capture becomes a parse job. If an adapter supports the source, it emits claims and normalization continues. If no adapter supports it, or the adapter fails, the extractor model may propose located claims. A confident uncontested match can be accepted by rule. A conflict or a new identity opens a review case. The advisory model attaches a recommendation. An authorized rule or a human decision accepts. Models only propose or advise. job yes no or failed claims conflict rule match proposal advice recommendation decision STATE Stored capture Evidence plus receipt CHOICE Adapter available? supports() on pa_* SERVICE Deterministic parser Versioned adapter MODEL ACTOR LLM extractor Proposes claims only SERVICE Normalize and match Profiles, then identity rules DATABASE Review case Durable until a decision DATABASE Accepted by rule Facts and one outbox row MODEL ACTOR Advisory reviewer Cannot accept or publish PERSON Human reviewer Approve, correct, or reject DATABASE Accepted by decision Same transaction shape

Takeaway. The deterministic parser writes claims when it supports the artifact. The extractor model only proposes. The reviewer model only advises. A person decides an uncertain identity.

Text equivalent

  1. A stored capture becomes a parse job.
  2. If an adapter supports the source, it emits claims and normalization continues.
  3. If no adapter supports it, or the adapter fails, the extractor model may propose located claims.
  4. A confident uncontested match can be accepted by rule. A conflict or a new identity opens a review case.
  5. The advisory model attaches a recommendation. An authorized rule or a human decision accepts. Models only propose or advise.

Status. Proposed actor permissions (ADR-006). Any added model cost must fit the proposed USD 40 operating envelope and leave the USD 10 reserve untouched.

The decision that accepts the correction

Explanatory excerpt, not a complete payload. The resolver can accept through an authorized deterministic rule or through a human decision. Models only propose or advise.

{
  "case_id": "rc_0007",
  "expected_revision": 2,
  "action": "correct",
  "corrections": { "core:mpn": "CVN-SP5-1T0-HS", "storage:heatsink": true },
  "create_item": { "id": "itm_ssd_p5_1t_hs", "family": "fam_strata_p5" },
  "map_to": "itm_ssd_p5_1t_hs"
}

The recorded result is 201, decision dec_0141, case revision 3, and outbox events evt_0141 and evt_0142. If expected_revision were stale, the response would be 409 and the mapping would stay. That rule is established in the design. The transaction around it is still proposed, and SPK-01 has not been run.

Accepted, applied, and public are three states

evt_0142 is listing_mapping.corrected. It says the listing now references itm_ssd_p5_1t_hs instead of itm_ssd_p5_1t. That changes the listing’s item. It does not merge the products, and it is not the release event. It depends on the new item at revision 1. The product service parks the mapping event until that item is applied, then applies both in private. Readers see the change only after a separately authorized release is applied. The event’s published_at, 2026-10-11T09:12:22Z, is when the relay handed the event off. It is not permission to show the page.

Figure

When is a change accepted, applied, and public?

When is a change accepted, applied, and public? Private application of an item or mapping event is not publication. evt_0142 corrects a listing mapping. Readers see that change only after a separate release is applied. Accepted item and mapping events commit in the resolver. evt_0142 is listing_mapping.corrected. The product service may apply those events and still show the previous release. Acknowledging the mapping event does not authorize a public page. A separate release command is applied before a reader can see the correction. private events not this event release event no public read not a release DATABASE Accepted privately Item and mapping events commit SERVICE Apply mapping privately evt_0142 is not a release GATE Authorized release Separate command and event SERVICE Apply the release Readers can see this STATE Still private Accepted is not a release STATE Not readable yet Mapping apply is not public

Takeaway. Private application of an item or mapping event is not publication. evt_0142 corrects a listing mapping. Readers see that change only after a separate release is applied.

Text equivalent

  1. Accepted item and mapping events commit in the resolver. evt_0142 is listing_mapping.corrected.
  2. The product service may apply those events and still show the previous release.
  3. Acknowledging the mapping event does not authorize a public page.
  4. A separate release command is applied before a reader can see the correction.

Status. Proposed (AW-01, AW-03, AW-04, ADR-003, ADR-009). Transaction behavior is still to be proven by SPK-01 and SPK-02.

The same story’s pack lesson uses a different fixture, so the heatsink item is not asked to do two jobs. itm_ridgeline_500g and itm_ridgeline_2x250g stay distinct. That comparison is in Data and vocabulary.

Services and boundaries