FORAY in Plain English

The companion — your first document. It explains; the specification specifies; the trust model outranks everything, including this page.

FORAY in Plain English — The Companion

Document Version: 0.7
Date: 2026-07-24
Lineage: continues the plain-English companion lineage. Supersedes v0.6 (FORAY_Batch_Anchoring_Plain_English-v0_6.md, preserved unchanged in this directory), whose scope was the batch-anchoring amendment alone; this version is the one full rewrite against production reality — the whole protocol, wire format 4.2, as it stands today.
Technical counterpart: the specification publication edition. The companion explains; the edition specifies. Where they could be read to differ, the edition — and behind it the F-Wire Migration Amendment — governs.
Audience: a competent stranger. You can run commands, and you have never heard of FORAY. This is your first document.

1. What FORAY is — and what it is not

Businesses and software systems generate records: an invoice was paid, a policy check ran, a loan was issued, an AI agent deployed a release. Months later, someone asks: is this record the same one that existed then, or has it been quietly changed?

FORAY answers that one question, extremely well, and does not pretend to answer others.

A FORAY record is a small JSON document describing an event. FORAY hashes it — a hash is a fingerprint: change one character in the record and the fingerprint changes completely — and writes a commitment derived from that fingerprint onto a public blockchain, where nobody, including us, can edit it. From then on, anyone holding the record can prove two things: these exact bytes existed no later than that moment, and nobody has altered them since. That property is called being tamper-evident. FORAY records are tamper-evident. They are not "immutable" — you can edit your copy any time; you just can't hide that you did.

Now the boundary, stated exactly, because everything honest about this protocol depends on it:

FORAY makes the originating system's declarations tamper-evident; it does not make them true.

If your accounting system declares an invoice of 12,500 and that number is wrong, FORAY faithfully preserves the wrong number, forever, with proof nobody edited it afterward. When FORAY's validator says PASS, it attests that the record conforms to the ruled shape — every required fact present, every number legally spelled, every internal reference resolving. PASS never attests that the content is true. The same rule covers formulas: a record can carry a fingerprint of the formula that computed a number, and that fingerprint proves which formula was declared and that it hasn't changed since — never that the formula ran, or ran correctly. The full statement of what is and isn't proven is the trust model, and it outranks every other claim anywhere, including in this document.

2. The four components: commitment, judgment, expectation, event

Every FORAY record decomposes an event into up to four kinds of parts. The names are formal; the ideas are everyday:

  • Arrangement — a commitment was made. A contract signed, an order placed, an authority granted. Who committed to what, from when.
  • Accrual — a judgment was computed. An amount was calculated, a policy was evaluated. What method, what inputs, what came out.
  • Anticipation — an event is expected. A payment due next month, a deploy expected inside a release window. What, when, how likely.
  • Action — an event occurred. Money moved, the deploy ran. What settled, when, with what outcome.

Not every record needs all four. A cash sale is just an Action — no contract, no expectation, money across the counter. A depreciation entry is just an Accrual — a judgment with nothing settled. The parts reference each other, so a payment can point at the expectation it fulfills, which points at the calculation behind it, which points at the contract that started everything.

Notice that nothing in those four ideas is about money specifically. A grant of authority is a commitment. A policy check is a computed judgment. "The agent should deploy within this window" is an expectation. "The agent deployed, and the check passed" is an event. Governance and agent-activity records run through the same four parts as invoices do — that is a design fact, not a stretch, and you'll see both kinds below.

A finance record, complete

An advisory firm bills a monthly retainer: the agreement (Arrangement), the month's revenue recognition (Accrual), the expected client payment (Anticipation), and the payment received (Action), each referencing backward. This record was emitted by the FORAY generator — no example in this document, or anywhere in the FORAY repo, is hand-written — template arrangement-led-full-chain, and its canonical bytes hash to:

4d933c29bb4e86ff379df4f0c5d00487e588ad042d5887e9a6878b64c333c227

{
  "F1": "CONSULT_2026_Q3_RETAINER_014",
  "F2": "CONSULT_2026_Q3_RETAINER_014",
  "F3": "Bright Harbor Advisory LLC",
  "F7": 12500,
  "F8": "USD",
  "F26": "consulting_retainer_settlement",
  "schema_version": "4.2",
  "timestamp": "2026-07-24T09:00:00Z",
  "arrangements": [
    {
      "F4": "master_service_agreement",
      "F5": [
        {
          "jurisdiction": "US-MA",
          "name": "Bright Harbor Advisory LLC",
          "role": "Provider"
        },
        {
          "jurisdiction": "US-NJ",
          "name": "Stonebridge Logistics Inc",
          "role": "Client"
        }
      ],
      "F7": 12500,
      "F11": "2026-07-01T00:00:00Z",
      "F14": "2027-06-30T23:59:59Z",
      "F25": {
        "engagement_summary": "Monthly advisory retainer, July 2026 service period"
      },
      "F29": [],
      "id": "ARR_MSA_BH_2026"
    }
  ],
  "accruals": [
    {
      "F4": "service_revenue",
      "F7": 12500,
      "F13": "2026-07-01T00:00:00Z",
      "F14": "2026-07-31T23:59:59Z",
      "F17": "FixedAmount",
      "F18": "hash_4f1a9c2e7b3d8065a1c4e7f0b2d5a8c1",
      "F19": {
        "monthly_retainer": 12500
      },
      "F20": 12500,
      "F22": [
        "ARR_MSA_BH_2026"
      ],
      "id": "ACC_RETAINER_2026_07"
    }
  ],
  "anticipations": [
    {
      "F4": "expected_client_payment",
      "F10": 12500,
      "F22": [
        "ARR_MSA_BH_2026"
      ],
      "F23": [
        "ACC_RETAINER_2026_07"
      ],
      "F27": "2026-08-15T00:00:00Z",
      "F28": 0.97,
      "id": "ANT_JULY_INVOICE"
    }
  ],
  "actions": [
    {
      "F4": "client_payment",
      "F6": "Stonebridge Logistics Inc",
      "F9": 12500,
      "F12": "2026-08-12T15:45:00Z",
      "F15": "completed",
      "F16": "ach",
      "F21": [
        {
          "amount": 12500,
          "currency": "USD",
          "ref": "ANT_JULY_INVOICE",
          "ref_type": "anticipation"
        }
      ],
      "F22": [
        "ARR_MSA_BH_2026"
      ],
      "F23": [
        "ACC_RETAINER_2026_07"
      ],
      "F24": [
        "ANT_JULY_INVOICE"
      ],
      "id": "ACT_JULY_PAYMENT"
    }
  ],
  "component_hashes": {
    "accruals": "sha256:PLACEHOLDER",
    "actions": "sha256:PLACEHOLDER",
    "anticipations": "sha256:PLACEHOLDER",
    "arrangements": "sha256:PLACEHOLDER"
  },
  "merkle_root": "sha256:PLACEHOLDER",
  "blockchain_anchor": {
    "anchored_at": null,
    "block_height": null,
    "confirmation_time_ms": null,
    "kaspa_tx_id": null
  }
}

The keys look like F7 and F22 — hold that thought for one section.

A governance record, same grammar

A company grants a deployment agent authority for one release window (Arrangement), evaluates its release policy (Accrual — the checks are the formula's inputs, the passing result its output), expects the deploy inside the window (Anticipation), and records the performed deploy with a passing verdict (Action). Template governance-agent-activity; canonical bytes hash:

ba094b2b36589d5cf84eef0b7285fdbfde58e5c5decf1079d271a01062c0385b

{
  "F1": "GOV_2026_Q3_AGENT_DEPLOY_A17",
  "F2": "GOV_2026_Q3_AGENT_DEPLOY_A17",
  "F3": "Done In Seven LLC",
  "F7": 0,
  "F8": "USD",
  "F26": "agent_activity_record",
  "schema_version": "4.2",
  "timestamp": "2026-07-24T11:20:00Z",
  "arrangements": [
    {
      "F4": "authority_grant",
      "F5": [
        {
          "jurisdiction": "US-FL",
          "name": "Done In Seven LLC",
          "role": "Principal"
        },
        {
          "jurisdiction": "US-FL",
          "name": "deploy-agent-a17",
          "role": "Agent"
        }
      ],
      "F11": "2026-07-24T09:00:00Z",
      "F14": "2026-07-24T23:59:59Z",
      "F25": {
        "grant_scope": "production deploy of service worker, single release window"
      },
      "F29": [
        "sha256:c4a1f2e8d7b9035612384756a9c0e1f2d3b4a5c6e7f8091a2b3c4d5e6f708192"
      ],
      "id": "ARR_AUTH_GRANT_A17"
    }
  ],
  "accruals": [
    {
      "F4": "policy_evaluation",
      "F13": "2026-07-24T11:00:00Z",
      "F14": "2026-07-24T11:05:00Z",
      "F17": "Calculated",
      "F18": "hash_2b7e1a9c4f6d80351927c5e8a0b3d6f1",
      "F19": {
        "boot_check": 1,
        "release_window_open": 1,
        "tests_green": 1
      },
      "F20": 1,
      "F22": [
        "ARR_AUTH_GRANT_A17"
      ],
      "id": "ACC_POLICY_EVAL_A17"
    }
  ],
  "anticipations": [
    {
      "F4": "expected_agent_behavior",
      "F22": [
        "ARR_AUTH_GRANT_A17"
      ],
      "F23": [
        "ACC_POLICY_EVAL_A17"
      ],
      "F27": "2026-07-24T11:30:00Z",
      "F28": 0.99,
      "id": "ANT_EXPECTED_DEPLOY"
    }
  ],
  "actions": [
    {
      "F4": "agent_deploy_action",
      "F6": "production environment",
      "F9": 0,
      "F12": "2026-07-24T11:18:42Z",
      "F15": "verdict_pass",
      "F22": [
        "ARR_AUTH_GRANT_A17"
      ],
      "F23": [
        "ACC_POLICY_EVAL_A17"
      ],
      "F24": [
        "ANT_EXPECTED_DEPLOY"
      ],
      "F25": {
        "release_version": "d15673ea",
        "trace_id": "wf-2026-07-24-a17-0042"
      },
      "id": "ACT_DEPLOY_EXECUTED"
    }
  ],
  "component_hashes": {
    "accruals": "sha256:PLACEHOLDER",
    "actions": "sha256:PLACEHOLDER",
    "anticipations": "sha256:PLACEHOLDER",
    "arrangements": "sha256:PLACEHOLDER"
  },
  "merkle_root": "sha256:PLACEHOLDER",
  "blockchain_anchor": {
    "anchored_at": null,
    "block_height": null,
    "confirmation_time_ms": null,
    "kaspa_tx_id": null
  }
}

One thing worth noticing: the record's amount is 0. This event has no monetary measure, and 0 is an assertion that nothing was measured — not an omission. Where a governance commitment is bounded (a spending ceiling on the grant, say), the amount can carry that bound.

3. Why the wire speaks in codes

You saw keys like F7 where you might expect amount. That is deliberate, and there are three names for every fact, each at its own layer:

  1. Your system's names — whatever your ERP or platform calls things (invoice_total). FORAY never dictates these.
  2. Readable names — what humans use everywhere FORAY is discussed: catalog names like amount, currency, settled amount, and the implementer register (foray_amount, foray_currency) used in field-mapping work. This document's prose uses these.
  3. The wire codes — what actually gets hashed, anchored, and kept: F7, F8, F9. Every fact in the ratified catalog (F1 through F29) has one permanent code.

Why codes on the wire? Because the hashed bytes should reveal nothing through their field names, work identically in every language — and, most practically: a code like F7 cannot be plausibly guessed. There is no English word to autocomplete toward. Every field any implementation emits — human-written or AI-written — is a field somebody looked up in the catalog. Vocabulary drift, the classic failure of system integrations, has nothing to attach to. The catalog table with every code, name, and meaning is in the specification edition.

4. Verify something yourself, right now

Everything above is claims. Here is the exercise that turns claims into checking. FORAY's /proofs page publishes complete custody material for two demonstration records anchored to the Kaspa public blockchain — including things ordinarily kept private, published there precisely so strangers can check without trusting us.

  1. Download a record body: record-a-body-v2.json. Use the file, not a copy-paste from a rendered page — bytes are bytes.
  2. Hash it yourself: shasum -a 256 record-a-body-v2.json
  3. Compare. The page says the body hash is 5b106984710c31538beadea650d4f3091b2629e59a34189751bdcda15b316630. You should get exactly that. If one character of the record had changed since anchoring, you would get something unrecognizably different.
  4. Go deeper if you like: /proofs also publishes the salt and lane for each demonstration record, and the recipe — body hash, plus salt, plus lane, recomputed into the commitment — matches the payload sitting in a named Kaspa transaction that anyone can look up. No FORAY software required at any step; a hash tool and a block explorer suffice.

The same discipline runs through the site itself: every example page shows its record's canonical bytes and their hash, reproducible from what is served. The two records in section 2 carry their hashes for the same reason.

5. What a holder keeps — evidence custody

The chain keeps only commitments — never records. That means proving a record later requires holding three things: the record body (the bytes), the salt (fresh random material bound into the commitment so the chain reveals nothing, and so nobody can confirm guesses about your record against it), and the anchor reference (which transaction, which lane). Lose the body or the salt, and the anchor becomes a commitment nobody can prove anything against — the anchor is permanent; your ability to use it is exactly as durable as your custody.

This program learned that honestly: FORAY's own custody records — the ops log and per-record custody sheets on /proofs — exist because early operations taught that anchoring is the easy half, and the discipline of keeping bodies, salts, and anchor references paired and retrievable is the half that decides whether evidence works years later. Custody terms (how long, stored where, replicated how) are engagement decisions, not protocol; the protocol just makes the consequence of losing material plain.

6. Old records verify forever — the wire break, and why evidence is innocent

FORAY's wire format changed once: earlier records spelled fact names in English (wire 4.1); current records use the coded wire (4.2). Two things are true at once, and both are permanent:

  • Every old record still verifies and always will. The validator accepts wire 4.1 (and 4.0) records indefinitely: it checks them against their own era's rules, converts them mechanically to the current form, and labels the result legacy. The two demonstration records on /proofs are pre-break records — frozen, correct exactly as anchored, and verifiable forever against their era's bytes.
  • Producing new records in the old format is no longer conformant. Since the 4.2 publication of the FORAY site, newly emitted old-format records are accepted, converted, labeled — and the validator's response carries a notice saying the production is out of conformance. The record is still served fully.

The posture has a name worth keeping: the evidence is innocent of the producer's lateness. A record is never punished for when its producer upgraded. Conformance pressure lands on production practices, through engagement terms — never on the evidence, and never as refusal of service.

7. The map — where everything lives

You wantGo to
The precise rules of the current wireSpecification publication edition — and the F-Wire Migration Amendment behind it (spec/amendments/, this repo)
The machine-readable shapethe canonical 4.2 JSON Schema (foray-api repo, schema/foray-transaction-v4_2.schema.json)
To check a record, livePOST https://foray.dunin7.com/api/validate-foray — paste a record, get errors by name; the endpoint is the conformance arbiter
To generate records with an AI assistantthe FORAY skill (skill/FORAY_SKILL_WIRE-4_2-v1_0.md, this repo)
Worked examples, all generator-emitted with hashesforay.dunin7.com/examples — eleven records, finance and governance
To verify with your own handsforay.dunin7.com/proofs
What is proven and what is not, normativelyTrust model
The old wire's full recordforay.dunin7.com/specification-4-1

If you read only one thing after this: the trust model. It is short, it is blunt, and every claim anyone makes about FORAY answers to it.

Appendix — How FORAY handles huge volumes: the notary and the box

Carried forward from v0.6 of this companion, whose whole subject this was. The mechanics it explains in pictures are the batch-anchoring amendment's; where this appendix simplifies, that amendment governs. Nothing here changes anything in sections 1–7 — this is the anchoring layer below the records those sections describe.

The problem in one paragraph

FORAY's promise is simple: write a fingerprint of every business transaction onto the Kaspa blockchain, so that later, anyone can prove the record wasn't tampered with. That works beautifully when transactions arrive at human speed — a loan here, an invoice there. But some systems don't work at human speed. AI agents mint thousands of records a second. Trading systems fire constantly. A big company's ERP never sleeps. Kaspa is fast, but it is one shared road, and if every single transaction demands its own trip down that road, the road jams.

The solution in one sentence

Don't send every transaction to the blockchain individually — bundle them, fingerprint the bundle, and send one fingerprint that covers the whole bundle.

An everyday analogy: the notary and the box

Imagine a notary who stamps documents to prove they existed on a certain date and haven't been altered since.

The old way (one at a time): every document gets its own trip to the notary. Fine for a few documents a day. Impossible for ten thousand an hour — the queue outside the notary's office becomes the bottleneck.

The new way (the box): you collect documents into a box. When the box is full — or when a timer runs out, whichever comes first — you seal it and the notary stamps the seal. One stamp now covers everything in the box. Crucially, the seal is made in a clever way (a "Merkle tree" — think of it as a fingerprint of fingerprints) so that later you can prove any single document was in that box, without opening the box and showing everyone else's documents.

And when even that isn't enough (the warehouse): if hundreds of companies each have boxes, the notary's queue fills up with boxes instead of documents — same jam, one level up. So the boxes' seals get collected into a crate, the crate gets one master seal, and the notary stamps that. One stamp, covering hundreds of boxes, covering millions of documents. Proving your one document later just takes two steps instead of one: "my document was in box 47" and "box 47 was in Tuesday's crate."

One more thing about the notary: FORAY isn't the only customer. The notary's office serves the whole town — payments, tokens, other record-keepers, everyone. FORAY doesn't get to plan as if the queue belongs to it. So the design principle is to be the town's most considerate customer: arrive rarely (a fixed, tiny number of visits per second, no matter how much business is booming inside the boxes), and when the office is visibly busy, wait a little longer before the next visit rather than pushing into the queue. Because one stamp covers a whole crate, FORAY's visits scale with the clock, not with transaction volume — a million transactions an hour costs the notary exactly the same number of visits as a thousand.

That's the whole amendment. Everything else is the fine print that makes it trustworthy.

The fine print, translated

"Whichever comes first" — the timer matters. A box seals when it's full (512 documents) or when 60 seconds pass, whichever happens first. Why the timer? So a quiet afternoon doesn't leave your documents sitting unsealed in a half-empty box for hours. A busy trading system fills boxes in a fraction of a second; a sleepy back office seals a nearly empty box once a minute. Both are normal.

Half-empty boxes need a rule. The fingerprint math works most naturally on boxes with a "round number" of documents (powers of two: 256, 512...). Real boxes usually seal at awkward counts like 137. The rule: pretend the last document is repeated until the count is round, and write down the true count on the box. Everyone pads the same way, so everyone's math agrees. Boring, but without one canonical rule, two auditors checking the same box could get different answers.

Very busy warehouses use pallets. A flat-out system seals a box roughly eight times a second — and logging every single box in the warehouse ledger, one at a time, would swamp the ledger the same way individual documents once threatened to swamp the notary. So the busiest operations stack sealed boxes onto a pallet, seal the pallet the same way boxes are sealed, and make one ledger entry per pallet instead of one per box. Same trick, one level down; nothing new to learn. One iron rule comes with it: a box's seal never leaves the warehouse — never goes toward the crate or the notary — until the box itself is safely shelved. A quick scribble in the warehouse's intake log the moment a box is sealed counts as "safely shelved"; the tidy ledger entry can follow at pallet pace. Break that rule and you get the worst outcome this system can produce: a stamp at the notary vouching for a box that no longer exists — permanent, official, and unprovable. Later, proving one document just has one extra hop: "my document was in box 47, box 47 was on pallet 6, pallet 6 was in Tuesday's crate."

It's worth noticing what's happened here: it's the same move every time — collect things, seal the collection, note the true count, pass one seal upward. Documents into boxes, boxes onto pallets, pallets into crates, crates to the notary. Learn it once and you understand the entire system at any scale.

The whole journey in one picture:

<svg viewBox="0 0 860 260" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Documents to boxes to pallets to crates to notary">
<style>
.plbl{font:600 13px 'Avenir Next','Segoe UI',sans-serif;fill:#1a2332}
.psm{font:11px 'Avenir Next','Segoe UI',sans-serif;fill:#5a6b7f}
.pbox{fill:#ffffff;stroke:#1a2332;stroke-width:1.4}
.psoft{fill:#e3efee;stroke:#0e6e6e;stroke-width:1.4}
.parrow{stroke:#1a2332;stroke-width:1.6;fill:none;marker-end:url(#pah)}
</style>
<defs><marker id="pah" markerWidth="9" markerHeight="9" refX="7" refY="3" orient="auto">
<path d="M0,0 L7,3 L0,6 z" fill="#1a2332"/></marker></defs>

<g><!-- documents -->
<rect class="pbox" x="30" y="90" width="26" height="34" rx="2"/>
<rect class="pbox" x="44" y="80" width="26" height="34" rx="2"/>
<rect class="pbox" x="58" y="70" width="26" height="34" rx="2"/>
<text class="plbl" x="57" y="150" text-anchor="middle">Documents</text>
<text class="psm" x="57" y="167" text-anchor="middle">your transactions</text>
</g>
<path class="parrow" d="M100,100 H150"/>
<text class="psm" x="125" y="90" text-anchor="middle">512 or 60 s</text>

<g><!-- box -->
<rect class="pbox" x="160" y="70" width="70" height="52" rx="4"/>
<path d="M160,86 H230" stroke="#1a2332" stroke-width="1.2"/>
<text class="plbl" x="195" y="150" text-anchor="middle">Box</text>
<text class="psm" x="195" y="167" text-anchor="middle">sealed · true count on lid</text>
</g>
<path class="parrow" d="M245,96 H295"/>
<text class="psm" x="270" y="86" text-anchor="middle">busy sites only</text>

<g><!-- pallet -->
<rect class="pbox" x="310" y="58" width="40" height="30" rx="3"/>
<rect class="pbox" x="354" y="58" width="40" height="30" rx="3"/>
<rect class="pbox" x="332" y="90" width="40" height="30" rx="3"/>
<rect x="305" y="122" width="94" height="10" fill="#8a5a00" rx="2"/>
<text class="plbl" x="352" y="150" text-anchor="middle">Pallet</text>
<text class="psm" x="352" y="167" text-anchor="middle">one ledger entry, not one per box</text>
</g>
<path class="parrow" d="M415,96 H465"/>
<text class="psm" x="440" y="86" text-anchor="middle">seals only</text>

<g><!-- crate -->
<rect class="psoft" x="480" y="52" width="110" height="80" rx="6"/>
<path d="M480,78 H590 M517,52 V132 M554,52 V132" stroke="#0e6e6e" stroke-width="1.1"/>
<text class="plbl" x="535" y="150" text-anchor="middle">Crate (shared)</text>
<text class="psm" x="535" y="167" text-anchor="middle">many companies' seals · list published</text>
</g>
<path class="parrow" d="M605,92 H660"/>
<text class="psm" x="632" y="82" text-anchor="middle">one visit</text>
<text class="psm" x="632" y="108" text-anchor="middle">per interval</text>

<g><!-- notary -->
<circle cx="730" cy="92" r="40" fill="#1a2332"/>
<text x="730" y="87" text-anchor="middle" font-family="'Avenir Next','Segoe UI',sans-serif" font-size="13" font-weight="700" fill="#f4f6f8">KASPA</text>
<text x="730" y="103" text-anchor="middle" font-family="'Avenir Next','Segoe UI',sans-serif" font-size="10" fill="#c9d2dc">the notary</text>
<text class="plbl" x="730" y="160" text-anchor="middle">One stamp</text>
<text class="psm" x="730" y="177" text-anchor="middle">covers everything inside</text>
</g>

<text class="psm" x="430" y="225" text-anchor="middle">Proving one document later: “it was in box 47 → box 47 was on pallet 6 → pallet 6 was in Tuesday's crate → the crate is stamped.”</text>
<text class="psm" x="430" y="245" text-anchor="middle">Documents never leave home — only seals travel. And nothing moves right until what it covers is safely shelved.</text>
</svg>

Only seals travel; documents stay home. Your actual transaction data never leaves your own database. The only thing you send to the shared crate-packing service is your box's seal — a fingerprint, meaningless on its own. Nobody at the crate level can read your transactions, see your parties, or learn your formulas. Privacy isn't weakened by sharing the crate; in one way it improves — your document becomes one anonymous leaf among millions from unrelated companies, which makes it harder to single out.

The crate-packer must prove its honesty. You shouldn't have to trust whoever assembles the crate. So for every crate, they must publish the list of box seals that went into it. Anyone can redo the math from that list and check it matches the stamp on the blockchain. If the crate-packer ever cheats or errs, the math won't check out — publicly.

Nobody gets to toss a fake box in the crate. Every box seal must be signed by a registered sender, so the crate only ever contains boxes from known consumers. This is about protecting the shared infrastructure — it says nothing about whether the transactions inside a box are legitimate (see below).

Keep your box, or lose your proof. The blockchain stamp lives forever — but the stamp alone can't prove your document was in the box. For that you also need the box's internal fingerprint tree, and that lives in ordinary databases, not on the blockchain. If a company deletes its old boxes and later needs to prove a seven-year-old transaction, the eternal stamp on the blockchain is useless to it. So: whoever created the transactions is responsible for keeping the proof material as long as their regulations require (SOX means about seven years), and there should always be a second copy held somewhere outside that company — so one firm going bust or wiping a server doesn't silently destroy provability. One more rule at the shelving stage itself: the warehouse writes every box's paperwork into two separate filing systems at the same moment, not one system copied to another later — because a fire in the minutes between "filed" and "copied" is exactly how proof material vanishes while its seal is already traveling. (This rule isn't new, as it happens — it was in FORAY's very first persistence design from January 2026, which named specific products for each filing system. That design was set aside on purpose during the Kaspa hackathon — proving the model only needed one-at-a-time persistence, and the deadline didn't allow following the bigger paths. It was recovered from history in July; the principle now lives in the specification, product names left in the past where they belong.)

Example 1 — An AI agent system (like Stele Agentic ID)

An agent platform mints identity records at around 4,000 per second per processor core. At that pace a box fills in about an eighth of a second — roughly 8 sealed boxes per second from one busy core. Even one such core, sending every box straight to the notary, would already exceed the handful of visits per second FORAY allows itself as a considerate tenant. So high-speed systems like this don't queue at the notary at all — their boxes stack onto pallets inside their own warehouse (one tidy ledger entry per pallet, not per box), the pallet seals go into the crate, and the crate makes one visit per interval regardless of whether ten cores or ten thousand fed it. Systems like this typically already keep the required intake log the moment each box seals — it's how they're built — so the iron rule costs them nothing. The amendment includes this arithmetic explicitly, so the routing rule is a calculation, not an argument.

One more rule for agents specifically: every agent appearing in a transaction must state how its identity was verified. At this stage, only agents with proper cryptographic credentials (like Stele's signed identities) are accepted. A slot exists in the format for weaker "the platform vouches for it" identities, but it's switched off — it can be switched on later by a deliberate decision, not by accident.

Example 2 — A trading system

An AI agent executes a trade: shorts 2 BTC at $67,400 with 3x leverage, stop-loss at $69,500. FORAY records the whole story — what the agent was authorized to do, what it analyzed, what it planned, and what actually executed, plus the exchange's confirmation. Trading records can't wait a minute to be anchored (regulators expect promptness), so trading streams get the fast lane: a crate that seals every couple of seconds instead of every minute. Slower business systems use the standard lane. Same machinery, different timer.

Example 3 — An ordinary company

A mid-sized business posts a few hundred transactions a day through its ERP. It doesn't need boxes at all — the original one-stamp-per-transaction mode still works, unchanged, and always will. Batching is an option for those who need it, never an obligation. Nothing about existing FORAY behavior, the live demo sites, or current integrations changes.

The one thing FORAY never claims — worth repeating

FORAY proves that what was submitted has not changed since it was submitted, and when it was submitted. That's all — and that's a lot. It does not prove the trade was authorized, the invoice was genuine, or the agent behaved well. If someone submits a lie, FORAY faithfully proves it's the same lie, unaltered, timestamped. Catching the lie is the job of the company's own controls, auditors, and attestors. Boxes and crates change nothing about this: every layer of the pipeline is pure mechanics — hash, bundle, stamp — and none of it ever vouches for content.

DUNIN7 — Done In Seven LLC
FORAY — Plain-English Companion — v0_7 — 2026-07-24