Delivery is assertion egress — a value written into a system of record must carry its…

deliver is the point where a value leaves the epistemic lattice into a machine system of record — a CRM whose rows downstream humans treat as verified fact. It is the exact dual of scrape (v2.52.0): where a scraped value ENTERS the program born adversarial and Untrusted, a delivered value goes OUT into a system that confers an authority the value may never have earned.

The law. A value written into a system of record must carry its epistemic origin (provenance: attached, the default), OR the author must have vouched — under epistemic { believe|know }, after a shield + anchor cleared it — that it is a verified fact (provenance: cleared). Stripping the origin from an Untrusted / Inferred value at the delivery boundary is impossible: it is a compile-time refusal (axon-T920), not a runtime surprise. A vendor's guess arrives in the CRM labeled a guess, or it does not arrive bare.

Why this is a law, not a lint

A v2.58.0-enriched email is a vendor model's probabilistic guess — born speculate (a pattern heuristic) or believe (deliverability-verified), never know, and epistemically Untrusted. The CRM does not know that. A row in a system of record reads as true — the format confers authority the value never earned. Booking a speculate email as a bare email field is precisely the assertion-laundering v2.53.0 forbids for a document (T916); deliver is that barrier in egress form (T920).

The surface

deliver PushLead {
    target:     crm            # the system-of-record class (axon-T921)
    provenance: attached       # each field lands with its level/confidence/source
    secret: crm_api_key # v2.48.0 custody — the credential never enters cognition
    effects:    <web>          # a CRM write crosses the network trust boundary (axon-T924)
    upsert_contact {
        key:   lead_email      # idempotency key — a retry never double-creates (axon-T926)
        email: lead_email
        name:  lead_name
    }
}

provenance: cleared is legal ONLY when the flow vouches:

# axon-T920: launders a vendor guess into the CRM as a bare fact.
deliver bad { target: crm  secret: k  effects: <web>  provenance: cleared
    upsert_contact { key: guessed_email  email: guessed_email }
}

# OK: the author vouches the values are ≥ believe (after shield + anchor).
believe {
    deliver good { target: crm  secret: k  effects: <web>  provenance: cleared
        upsert_contact { key: verified_email  email: verified_email }
    }
}

The three enforcement layers (all fail-closed)

Compile — axon-T920 (the provenance-stripping barrier) + T921–T926 (target catalog, provenance catalog, secret: required, web effect, operation catalog + non-empty, idempotency key:).
Verify / deploy — the PCC DeliveryProvenanceSoundness class re-derives T920 (+ T921/T924) from the compiled IR, so a hand-edited IR that flips provenance to cleared without the vouch is REFUTED before it deploys.
Runtime (enterprise) — a crm:deliver SoD gate (role-expanding) + a per-tenant legal flag (default OFF) + a fail-closed crm:delivered audit that witnesses the delivery's op kinds + field-count — never the PII values (a delivered email is itself a PII record).

What the law does NOT promise

Not that the CRM keeps the label. Once the bytes reach the vendor, whether the axon_provenance companion survives is the adopter's CRM's responsibility — the same honest perimeter as document (v2.53.0): axon guarantees the artifact leaves labeled, not that every downstream tool respects the label.
Not a lawful basis. Delivering v2.58.0-enriched PII is further processing; the governance demonstrates diligence, it does not create a GDPR lawful basis (the tenant is the controller).

Why this is a law, not a lint​

The surface​

The three enforcement layers (all fail-closed)​

What the law does NOT promise​

See also​

Why this is a law, not a lint

The surface

The three enforcement layers (all fail-closed)

What the law does NOT promise

See also