PRIVATE COMPLETION
The strict pilot completes without publishing anything
An authenticated account may accept the current legal documents, verify control of an eligible external subject, run the complete bounded activation chain, and retain that completion privately. Private completion creates no public proof, catalog entry, badge, or publicly retrievable subject record. It does not require publication before a later product evaluation, commercial decision, or paid handoff.
Publication is a separate optional step. A public record may be created only when the authenticated account sends a fresh finalization request with publication_consent=true. Missing, false, stale, or replayed consent must not publish a record. The initial signed binding challenge carries no publication direction.
NORMATIVE CLAIM
Two positive observations and an explicit stopping point
A conforming proof states that the MandateShield production service observed one persisted strict ALLOW reservation and that the exact one-use execution permit was freshly redeemed by the separately scoped processor credential. Both observations must belong to the same account, entitlement, mandate, trusted authority key, verification key, processor key, authorization, and permit.
The fixed activation profile is GENERIC_HTTP_V1 in the test environment for exactly $0.01 USD. The official external runner stops immediately after permit redemption and contains no client that calls the bound resource or a payment provider. The signed record cannot observe unrelated out-of-band activity.
SUBJECT AND ACCOUNT BINDING
The record cannot come from an anonymous hosted demo
Before activation, an authenticated account accepts the current legal documents and proves control of either an HTTPS domain by DNS TXT or a public GitHub repository by placing a fixed binding document at the exact current HEAD of its default branch. This account-bound challenge proves the requested subject binding; it does not authorize publication. MandateShield verifies that HEAD through GitHub before reading the file, records the binding digest, and applies its published operator/internal/test exclusion policy. A commit that exists only in a fork, pull-request ref, or non-default branch is rejected.
The eligibility result ELIGIBLE_EXTERNAL_CANDIDATE means only that the submitted subject did not match those exclusions at the recorded evaluated_at time. Subject control is separately scoped to the binding verified_at time. Final proof issuance reuses those recorded results and does not rerun either check. Neither result is independent identity verification or can establish that the publisher is unrelated to MandateShield.
ONE-TIME ENTITLEMENT
Credentials are narrow, short-lived, and chain-bound
- The account receives one expiring deployment-proof entitlement.
- Bootstrap creates separate one-time live
VERIFYandPROCESSORcredentials, one trusted P-256 authority key, and one immutable one-cent mandate. - The authority assertion binds the exact final amount, currency, merchant, resource, nonce, and challenge.
- Strict verification persists one reservation and consumes the complete one-cent lifetime budget.
- Provider-bound consume issues one short permit; exact online redemption claims it once.
- Private completion reloads and matches the complete server-side chain without creating a public record.
- Optional publication requires a separate fresh finalization with
publication_consent=truebefore MandateShield signs the public record.
Replays, different credentials, different resources, missing persistence, stale permits, subject mismatches, and incomplete chains fail closed.
MACHINE-READABLE BOUNDARY
Scoped observations and false assurances are signed
{
"attestation_type": "ACCOUNT_BOUND_SERVER_OBSERVED_ACTIVATION",
"binding": {
"verified_at": "2026-07-28T12:00:00.000Z",
"subject_control_verified_at_binding": true
},
"eligibility": {
"evaluated_at": "2026-07-28T11:55:00.000Z",
"operator_exclusion_no_match_at_evaluation": true
},
"activation": {
"strict_live_reservation_server_observed": true,
"provider_permit_redeemed": true,
"mandateshield_provider_submission_observed": false,
"mandateshield_provider_enforcement_observed": false,
"provider_evidence_recorded": false,
"independent_terminal_evidence_verified": false
},
"assurance": {
"counts_as_verified_activation": true,
"counts_as_customer": false,
"counts_as_revenue": false,
"deployment_runtime_inspected": false,
"non_bypassability_verified": false,
"independent_organization_verified": false,
"audit": false,
"certification": false,
"security_guarantee": false,
"non_authorizing": true,
"observation_scope": "MandateShield observed no provider submission or provider evidence in this proof flow. Out-of-band activity is outside this proof."
}
}A published entry is therefore valid activation evidence, but it does not establish whether the holder acted outside MandateShield. It is not evidence of a paid account, a customer, revenue, continuous deployment, non-bypassability, payment submission, provider enforcement, settlement, independent testing, an audit, certification, or security.
Public lists contain only records that received that separate publication consent. They exclude private completions, so absence from the catalog does not imply that no private pilot completed.
PUBLIC VERIFICATION
Every active proof has human and machine representations
- Public deployment activation proof catalog
- Machine-readable active-proof list
GET /api/v1/deployment-proofs/{proof_id}returns the complete bounded claim and compact signature.GET /api/v1/deployment-proofs/{proof_id}/badge.svgreturns a badge labeled only “activation observed.”- Current immutable runner URL and SHA-256
- Published ES256 verification keys
- Guided account-bound deployment workflow