Written for the Director of Customer Programs / Account Operations at a co-manufacturer — the seat where the traceability mandate arrived through the commercial relationship, priced not against an internal ROI but against what the account is worth to keep.

Every supplier in your position currently picks between two bad options, and both are bad in ways your seat pays for.

Option one: join the customer's platform. Their portal, their network, their data model — and their switching costs, which are now your switching costs. Multiply by the number of accounts that matter and your plant is keying the same production reality into N systems, each of which makes leaving that customer more expensive. The mandate's author sits inside their own programme office (the brand-owner's side of this decision); the join-their-network posture makes their programme's gravity your operating model.

Option two: email them exports. Spreadsheets at month-end, CSVs on request, a quality manager assembling evidence per audit. Cheaper, until the account review where your customer's auditor asks why the export from March differs from the one from May, and the honest answer is that exports are photographs and the plant kept moving.

The grant is the third option, and it is architecturally different rather than incrementally better.

The grant, anatomized

A SharingGrant is a scoped, revocable view over your own record, handed to a named counterparty. Three properties do the work:

Scope. The grant names exactly what the mandate covers — this customer's SKUs, this date range, these event types — and nothing else. What is outside the scope is absent from their view: not greyed out, not redacted, absent, so there is no shape left behind to argue about. Your other customers' volumes, your line efficiencies, your slack capacity — structurally invisible, because the view never contained them.

Compilation, not forking. The grant compiles down to native access scopes over the one record your plant already emits. There is no second copy, no export pipeline, no per-customer database drifting out of sync. The customer reads a view; the record stays yours, append-only, in one place.

Revocation without rewriting. When the contract ends, the grant ends. Revoking it rewrites nothing — nothing in this system rewrites — so everything either side already holds stays exactly as it was, and the history neither gains nor loses a fact. The relationship changes; the record does not.

The worked grant

One plant, one customer mandate, one grant — the shape your next account review could table:

grant: plant-opelika → customer QSR-A scope: products: the 14 GTINs under QSR-A's supply agreement window: 2026-01-01 → contract term events: commissioning, packing, shipping + the ASN-cited transaction references on each their auditor sees: every covered case's event chain, with the attested observer on each act and the warrantor account behind each capture — verifiable per event via the CBV 2.0 §8.9 content hash their auditor cannot see: any other customer's GTINs, volumes, schedules — absent, not redacted revocation: ends the view; touches no event either side holds

The line about the hash matters more than it looks. Each event's identity is computed from its content under the standard's own algorithm, so your customer's auditor can verify any event in their view independently — recompute, compare, done — without joining anything of yours and without trusting your word or ours. The evidence-grade argument is the custody answer; the point for your seat is that the verification is theirs to run, which is what makes the grant an answer to an audit rather than a substitute for one.

One record, N customers

Your book is concentrated — a handful of accounts is most of it — and each account's mandate differs in scope, never in kind. Your quality seat sees the same boundary as compliance without ownership (the flow-down brief); your Sunrise exposure runs through the same commercial channel, one hop removed. The grant model prices that reality correctly: your plant emits its record once, and each customer holds a grant shaped to their mandate. Compare the alternative you are living: N portals over N copies, where every new mandate is a new integration and every audit is an assembly project.

The account-review arithmetic follows. Capability funded once serves every current account and every prospective one; the marginal cost of the next mandate is a grant, not a project. For a seat whose spend must justify itself against retaining named accounts, that is the difference between a recurring cost-to-serve line and a one-time capability that compounds. The multi-client version of the same architecture — one operation, many counterparties, each seeing only their own — is worked through in the 3PL's version of this brief.

The line this hands you

The next time a customer tables a data requirement at an account review, the answer this architecture supports is one sentence: "You already have the view — here is the grant." Scope drawn to the mandate, verifiable by their auditor from their side, revocable by you without disturbing a single fact of history. No portal joined, no export queue, no copy of your plant's life living on someone else's servers.

That sentence retires the two bad options. What remains is the relationship, priced honestly.

If a mandate with a date is already on your desk, start the interview — it asks about the account and the ask, and it ends with exactly one promise about contact.