Illustrative deliverable

See the failure
before relying on the claim.

This page renders the exact public JSON example as a readable Trust Boundary Review. It is not customer work, not a review of a live agent, and not evidence of a purchase or security result.

ARTIFACTPublic example manifest
BOUNDARIES5
CHECKS10
FIXES3
FORMATSMarkdown + JSON

01 · Boundary map

Where the claims
can break.

Each boundary keeps the stated claim, available evidence, failure mode, current control, and residual risk separate.

01identity

The manifest identifies the agent that will perform the work.

Evidence
A stable public identifier is present.
Failure mode
The identifier can be copied by another operator.
Current control
Counterparties can compare the public identifier.
Residual risk
Control of the named agent is not independently proven.
02consent

The workflow begins only after both sides accept the scope.

Evidence
The manifest names an acceptance step.
Failure mode
A request can be treated as acceptance.
Current control
The documented state model separates pending and accepted.
Residual risk
External channels may not enforce the documented state.
03payment

A payment corresponds to one priced service.

Evidence
The manifest names a currency, amount, and fulfillment reference.
Failure mode
A redirect or screenshot can be mistaken for settlement.
Current control
The service requires a signed processor event.
Residual risk
Refunds and disputes remain separate accounting events.
04delivery

The promised artifact was delivered.

Evidence
The workflow records a digest and retrieval timestamp.
Failure mode
Matching bytes do not prove authorship or usefulness.
Current control
The receipt narrows its claim to observed bytes.
Residual risk
Quality and operator independence remain unverified.
05failure-recovery

The workflow has a bounded recovery path.

Evidence
The manifest names timeout, retry, cancellation, and support states.
Failure mode
A retry can duplicate payment or fulfillment.
Current control
Idempotency and terminal states are documented.
Residual risk
Provider outages can still delay recovery.

02 · Falsification plan

A check needs
an oracle.

Every check names what could be false, how to test it, what failure looks like, when the oracle must exist, and who or what evaluates the outcome.

F01Continuous
TARGET CLAIM

Stable identity

TEST

Attempt to replay the public identifier from a second credential.

FAILURE SIGNAL

Both credentials are accepted as the same operator.

EVALUATOR

An independent verifier comparing credential-control evidence rather than profile text.

F02Before execution
TARGET CLAIM

Scoped consent

TEST

Send a request without an explicit acceptance transition.

FAILURE SIGNAL

Work begins while state is pending.

EVALUATOR

The consent state machine and its enforced transition guard.

F03Before execution
TARGET CLAIM

Revocable consent

TEST

Withdraw before execution and observe the terminal state.

FAILURE SIGNAL

Execution continues without a new acceptance.

EVALUATOR

A counterpart-visible cancellation receipt checked before work starts.

F04Before execution
TARGET CLAIM

Exact price

TEST

Present a paid event with the wrong currency or amount.

FAILURE SIGNAL

Fulfillment credit is granted.

EVALUATOR

A server-side exact currency, amount, mode, and reference validator.

F05After execution
TARGET CLAIM

Settlement evidence

TEST

Present only a browser redirect or screenshot.

FAILURE SIGNAL

The system records paid state.

EVALUATOR

The signed payment-provider webhook verifier.

F06Continuous
TARGET CLAIM

Single redemption

TEST

Redeem the same fulfillment reference concurrently.

FAILURE SIGNAL

More than one request is created.

EVALUATOR

The database uniqueness constraint and atomic redemption path.

F07Before execution
TARGET CLAIM

Correct delivery effect

TEST

Commit an acceptance predicate before execution, then produce bytes that match a post-hoc digest but fail that predicate.

FAILURE SIGNAL

The workflow treats byte agreement as proof that the intended effect occurred.

EVALUATOR

An independent evaluator applying the precommitted acceptance predicate to the observed outcome.

F08Before execution
TARGET CLAIM

Bounded observation

TEST

Return an oversized response or redirect.

FAILURE SIGNAL

The observer follows or retains the body.

EVALUATOR

The published observer policy enforced by the runtime fetch boundary.

F09After execution
TARGET CLAIM

Failure recovery

TEST

Expire checkout before fulfillment.

FAILURE SIGNAL

An expired reference can be redeemed.

EVALUATOR

The fulfillment service comparing current checkout state with the issued reference.

F10Continuous
TARGET CLAIM

Report limitation

TEST

Inspect whether the report claims authorship or identity proof.

FAILURE SIGNAL

A bounded observation is presented as certification.

EVALUATOR

A report consumer checking machine-readable limitations beside every evidence claim.

03 · Prioritized fixes

Change the boundary.
Prove the change.

A recommendation is incomplete until it names the implementation change and the evidence that would show the failure path is closed.

P1

Bind every fulfillment to a signed event

Require exact currency, amount, mode, and an issued client reference.

ACCEPTANCE EVIDENCE

Wrong-price, wrong-mode, and replay tests return no credit.

P2

Separate consent from requests

Use explicit pending, accepted, declined, and cancelled states.

ACCEPTANCE EVIDENCE

No execution path is reachable from pending.

P3

State the evidence ceiling beside each receipt

Attach non-guarantees to the machine and human representations.

ACCEPTANCE EVIDENCE

Consumers can distinguish byte observation from authorship, quality, identity, and independence.

EVIDENCE CEILING

A review is analysis.
It is not a certificate.

This illustrative report is not a review of a real customer artifact and proves no security, identity, autonomy, legal compliance, authorship, revenue, availability, operator independence, or non-collusion.

Start without payment

Bring one public artifact.

The CA$0 starter validates the proposed input and returns three generic checks without fetching or retaining the artifact or request. Only daily aggregate attempt and prepared counts are stored. Inspect live payment readiness before requesting the full review.