The gap implementation closes
Your system knows more than your auditor can prove
Systems of record are good at storing transactions and bad at proving them to outsiders. Change logs are optional and configurable — the histories they keep can be incomplete, and what was logged can be altered or purged by the same administrators the audit is meant to check. Summarised ledger entries discard the origination detail — who agreed to what, calculated how — that assurance actually rests on. And every platform does all of this differently, so evidence from two systems arrives in two shapes with two gaps.
The question a verifier ultimately asks is not "what does your system say?" but "can you prove that's what it said at the time?" Conventional systems cannot answer the second question to someone who doesn't trust their operators. A system that emits FORAY-structured events at origination — anchored as they happen — can.
What implementing means
Emit the grammar at origination
An implementing system produces, for each covered transaction, a FORAY record: the four-component decomposition with _refs[] chains, per the specification. The record stays in the enterprise's custody — the Evidence Custody Model states exactly what a holder keeps per anchor and how completeness is demonstrated — and its commitment is anchored per the anchoring layer. Three properties matter:
- At origination, not at reporting. The record is produced where the transaction is born — order entry, contract execution, payment run — capturing the detail a ledger summarises away.
- In the published form. The same grammar every other implementer uses, so consumers verify all of it with the same published rules.
- Anchored as it happens. Commitments reach the chain in continuous short windows per the anchoring specification, not in periodic exports.
DUNIN7's role: the specification, the validation rules, and reference implementations. The implementer's role: producing conforming events from their own system, with their own engineering, under their own product decisions.
Your data already fits
Illustrative mappings — how familiar records decompose
These are conceptual mappings from common platform objects to the grammar — illustrations of the decomposition, not connectors, and not statements about any vendor's plans.
An invoice lifecycle
Small-business accounting platform, e.g. QuickBooks-style objects
Customer + terms → Arrangement
Invoice issued (amount owed arises) → Accrual, referencing the arrangement
Due date and expected payment → Anticipation, referencing both
Payment received and applied → Action, referencing the anticipation; a single payment clearing several invoices carries allocations[] summing to the settled amount
An opportunity-to-cash flow
CRM platform, e.g. Salesforce-style objects
Closed-won opportunity + contract → Arrangement
Revenue recognition schedule entries → Accruals
Billing schedule → Anticipations
Applied payments → Actions
A procurement flow
ERP, e.g. NetSuite/SAP-style documents
Purchase order → Arrangement
Goods receipt / invoice verification → Accruals
Payment proposal → Anticipations
Payment run, with open-item clearing → Actions with allocations[]
The pattern generalises: agreements → Arrangements; obligations arising → Accruals; schedules → Anticipations; settlements → Actions. If your platform can export or stream these objects, it holds everything a FORAY record needs.
Reaching the data
Read-only access is the honest baseline
Producing FORAY events requires read access to transaction data — there is no version of this that requires none. What it does not require is workflow change or new data entry. Three delivery paths cover most platforms:
- Native emission. The platform itself produces FORAY events at transaction time. The deepest implementation; the direction demand-side adoption pulls toward.
- Warehouse-side production. Records already landing in a data warehouse are decomposed and emitted from there.
- Export-based production. Periodic exports feed a producer. The simplest start; the weakest origination claim, since records are captured after the fact rather than at the moment of origination — name that honestly when it's the path taken.
Conformance
One grammar, testable
The specification defines conformance: the component structure, the reference rules, the allocation sum, the versioned fields, and the anchoring envelope at the anchoring layer. DUNIN7 publishes the validation rules for the standard and runs a live validator, so "emits FORAY-structured events" is a claim a procurement checklist can test — submit a record to the validator and check the result — rather than a marketing phrase. Read the specification for the normative rules; the worked examples show complete conforming records across domains.
Contact
Talk it through
Implementing, or specifying FORAY in a procurement requirement, and want to talk it through: foray@dunin7.com.