How it works / Illustrative mission
From delegation to evidence to a decision
One bounded mission, followed from the first agreement to the buyer’s decision. Then the question that matters for a network: what can a second, independent buyer reuse?
The example
Illustrative example. The parties, the service and every figure on this page are invented to explain the proposed design. No such mission has been run, and the service class for the first validation has not been selected.
The example uses catalogue enrichment because it has the properties the first service terminal needs: the deliverable is digital and bounded, most of the result can be checked by machine, and many independent buyers purchase the same kind of work from the same kind of supplier.
One mission, seven steps
Read the mission from agreement to record. Switch the ending to see how an accepted result and a disputed result differ.
- 01
Agree
Buyer A · Supplier SBuyer A, an online retailer, needs 1,200 product records completed to its catalogue schema. Supplier S, an independent data-services firm, offers that service through its own agents.
Before any work starts, the two principals agree on scope, permissions, a deadline and how the result will be judged.
AcceptanceRuleIllustrative- Criterion 1
- All 1,200 records valid against the buyer’s schema
- Criterion 2
- At least 58 of 60 records match a control sample held by the buyer
- Decision
- Made by Buyer A, not by the supplier or the port
- 02
Delegate
Buyer ABuyer A issues a mandate for this mission only. It names the supplier’s agent, the actions it may take and the limits it must respect.
MandateIllustrative- May
- Read the catalogue export · write to a staging area
- May not
- Touch customer data · publish to the live catalogue · spend
- Limit
- 1,200 records · expires after 72 hours · revocable at any time
- Human approval
- Required for anything outside this scope
- 03
Execute
Supplier S’s agentThe agent performs the work inside controls that are compatible with the mandate. The mission record tracks each authorized change of state: accepted, in progress, submitted.
The port records the mandate. It can only constrain an agent that runs inside compatible execution controls or a binding integration.
- 04
Evidence
Supplier SThe supplier submits the evidence the parties agreed to share—and nothing else. Each item carries its origin and an integrity check.
EvidenceEventIllustrative- Item 1
- Schema validation report for 1,200 records
- Item 2
- Output for the 60 control-sample records
- Not shared
- The buyer’s catalogue data · the supplier’s internal prompts and tooling
- 05
Verify
Verification against the ruleThe evidence is checked against both criteria.
VerificationIllustrative- Criterion 1
- 1,200 of 1,200 valid — met
- Criterion 2
- 59 of 60 match — met
The evidence is checked against both criteria.
VerificationIllustrative- Criterion 1
- 1,200 of 1,200 valid — met
- Criterion 2
- 55 of 60 match — not met
- 06
Decide
Buyer ABuyer A accepts the work. Verification informed the decision; it did not make it. The buyer could still have raised a dispute on grounds the criteria did not capture.
Payment follows through an existing payment rail chosen by the parties. The port, as proposed, does not hold client funds.
Buyer A disputes the work. The dispute record points to the criterion that was not met and to the evidence that shows it. The supplier can see exactly what is contested.
From here the parties might agree to rework within the same mandate, a partial acceptance or a rejection. The procedure for resolving disputes is one of the operating rules still to be developed.
- 07
Record
Mission recordMissionRecordIllustrative- State
- Closed — accepted by Buyer A
- Mandate
- Expired on completion
- Kept
- Criteria, evidence events, verification result and the decision
MissionRecordIllustrative- State
- Open — disputed by Buyer A
- Mandate
- Still bounded by its 72-hour expiry
- Kept
- Criteria, evidence events, verification result and the dispute record
Either way, both parties hold the same account of what was agreed, what was done, what was shown and who decided.
Then a second buyer arrives
Buyer B is an independent retailer with the same need. It has never worked with Supplier S. The network claim rests on what happens next: how much of the first relationship Buyer B can reuse, and how much it must rightly decide for itself.
| Reusable, with permission | Decided again by Buyer B | Never carried over |
|---|---|---|
| Supplier S’s versioned service profile | Its own mandate: scope, limits and expiry | Buyer A’s permissions |
| The working integration and format mapping | Its own acceptance rule and thresholds | Buyer A’s data |
| Evidence that Supplier S and Buyer A allow to be shared | Its own security, risk and commercial terms | Buyer A’s acceptance as a guarantee |
The founding plan sets a target: Buyer B should need at least 50% less active onboarding time than Buyer A did. If Buyer A’s onboarding took 40 working hours, the target would be met at 20 hours or fewer for a comparable service. These numbers illustrate the arithmetic; they are not measurements.
What the example leaves out
- It is not a prototype. No software described here is available.
- Prices and fees are unknown. Whether buyers and suppliers will pay for shared acceptance is one of the questions under test.
- Dispute resolution is unwritten. Liability, evidence retention and dispute procedures are operating rules still to be developed.
- Enforcement has a boundary. A mandate is only as strong as the execution controls that honor it.
- One service class proves little. A result here would support a narrow hypothesis, not general adoption.