# Ad+Card Protocol — Draft 0.1 Status: **Community Draft, 2026-07-18** Identifier: `adcard/0.1` Specification license: CC-BY-4.0 Schemas and examples: Apache-2.0 This is an implementable draft for public review, not a final standard, certification program, or production settlement network. ## 0. Abstract Ad+Card is an open, user-owned format for **declarative advertising**: a person declares a goal, outfitters offer to equip the person toward that goal instead of advertising at them, and completion is represented by a **truthful receipt** describing exactly what evidence established—never more. The format is open so anyone can implement it. Instruments that verify moments compete on usefulness and honesty. The protocol is deterministic, not predictive: it tracks declared intent; it does not model people from behavioral exhaust. ## 1. Conventions The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, **SHOULD NOT**, and **MAY** are to be interpreted as normative requirements. - Objects MUST be UTF-8 JSON. - Every object MUST include `spec: "adcard/0.1"` and a recognized `kind`. - Timestamps MUST be RFC 3339 strings in UTC. - Identifiers MUST be UUIDs unless a field explicitly says otherwise. - Implementations MUST reject unknown fields in v0.1 protocol objects. - Human interfaces MUST render the draft version and assurance class without relying on color alone. ### 1.1 Draft cryptography limitation The v0.1 object shape reserves `signature` and `attestation` fields, but this draft does not yet freeze a canonicalization algorithm, signature suite, key-recovery method, or platform-attestation profile. Implementations MAY experiment with signatures but MUST NOT claim cross-implementation cryptographic conformance or production settlement safety until those profiles are published. ## 2. Normative principles 1. **The person owns the card.** A Declaration is created, held, exported, and deleted by the person. No implementation may require surrender of the card to a platform to participate. 2. **Declared intent, not surveillance.** A conforming system never derives Declarations from behavioral tracking. A card exists only because a person wrote it. 3. **Receipts never upgrade uncertainty into certainty.** Every receipt carries an assurance class. Self-attestation is valid and honest; it is never presented as device-verified. 4. **Raw reality stays with the person.** Coordinates, health samples, motion streams, images, and answer choices never appear in a protocol object. Only narrow claims do. 5. **Health data never enters commerce.** No health-derived value may appear in an Offer, Receipt, eligibility rule, or settlement decision. 6. **Equip, do not interrupt.** An Offer funds or supplies progress toward declared intent. Formats whose value is attention capture are non-conforming. 7. **Commercial offers are funded first.** An Offer with money or material reward is valid only when its declared settlement pool is funded. Unfunded commercial offers MUST NOT be shown to people. ## 3. Protocol objects There are three objects: Declaration, Offer, and Receipt. The normative machine-readable shape is in [`schema/adcard-0.1.schema.json`](../schema/adcard-0.1.schema.json). ### 3.1 Declaration — the Ad+Card ```json { "spec": "adcard/0.1", "kind": "declaration", "id": "b94fe35f-08de-48bc-8b4b-e94981770c9f", "subject": "local:per-card-public-key", "goal": "Run a 5K without stopping by October", "category": "move", "createdAt": "2026-07-18T06:00:00Z", "expiresAt": "2026-11-01T00:00:00Z", "baseline": { "vibeForecast": 620, "note": "I want to finish feeling steady, not depleted." }, "visibility": "private", "signature": "draft-signature-placeholder" } ``` Requirements: - `subject` MUST be pseudonymous. Real identity is not a protocol field. - A fresh per-card key MUST be the default so exported cards are not linkable by default. - A person MAY visibly opt into a reusable key for continuity. Implementations MUST NOT require it. - `goal` MUST be person-authored. Autocomplete MAY help editing but MUST NOT silently create or infer a Declaration. - `visibility: "private"` is fully conforming. - `baseline` is optional and person-authored. Its absence MUST NOT reduce access or conformance. ### 3.2 Offer — the outfitter’s response ```json { "spec": "adcard/0.1", "kind": "offer", "id": "f227e7be-df76-4b86-8427-f64b443afde3", "declarationRef": "b94fe35f-08de-48bc-8b4b-e94981770c9f", "outfitter": { "name": "Neighborhood Run Club", "id": "outfitter:run-club-example" }, "equips": "Entry to a coached four-week 5K practice group", "module": { "id": "practice-run", "revision": 3, "disclosure": { "goal": "Complete one disclosed practice session", "uses": ["fresh location capability during the session"], "stored": ["the resulting narrow receipt"], "shared": ["nothing unless the person approves the receipt"], "validates": ["arrival", "session completion"], "reward": "25.00 USD after an accepted verified receipt", "expiresAt": "2026-09-01T00:00:00Z" } }, "settlement": { "perReceipt": { "class": "verified", "amount": "25.00 USD" }, "escrow": { "pool": "example-funded-pool", "attestation": "draft-escrow-attestation-placeholder" } }, "expiresAt": "2026-09-01T00:00:00Z", "signature": "draft-outfitter-signature-placeholder" } ``` Requirements: - `equips` MUST describe a good, funding, access, or disclosed module that supports progress. - An Offer MUST NOT require unrelated attention, tracking, or data surrender. - The module disclosure MUST be visible before acceptance and included in what the outfitter signs. - Monetary or material rewards REQUIRE `settlement.escrow`. - The accepted settlement assurance class MUST be named before the person begins. - An Offer MUST NOT use a forbidden field or a health-derived value for eligibility or settlement. ### 3.3 Receipt — the settlement truth ```json { "spec": "adcard/0.1", "kind": "receipt", "id": "e77f31b9-8b5f-45c2-8e7b-752a9db8c5e5", "declarationRef": "b94fe35f-08de-48bc-8b4b-e94981770c9f", "offerRef": "f227e7be-df76-4b86-8427-f64b443afde3", "moduleId": "practice-run", "moduleRevision": 3, "outcome": "completed", "phases": [ { "phaseId": "arrive", "claim": "Arrived at the declared practice venue during the accepted window", "assurance": "verified", "validator": { "id": "fresh-location-window", "version": "1.0.0" } } ], "window": { "acceptedAt": "2026-07-18T06:00:00Z", "settledAt": "2026-07-18T07:10:00Z" }, "instrument": { "name": "Example Instrument", "attestation": null }, "signature": "draft-instrument-signature-placeholder", "subjectSignature": "draft-subject-countersignature-placeholder" } ``` Requirements: - `outcome: "stopped"` is a first-class result. Stopping is truthful data, not a failure to hide. - Every `claim` MUST be one narrow human sentence. If it cannot be stated honestly in one sentence, the module is malformed. - Each phase MUST carry exactly one assurance class from Section 4. - A person MUST approve a Receipt before it leaves their instrument. - A Receipt MUST NOT contain or encode raw evidence. - A receipt that settles money will require an attestation profile in a later draft. v0.1 does not yet define one. ## 4. Assurance classes | Class | Meaning | May settle a commercial offer? | |---|---|---| | `verified` | Fresh, capability-specific evidence established the claim on the instrument. | Yes, once an attestation profile exists. | | `corroborated` | Evidence supports but cannot fully establish the claim. | Only if the Offer explicitly accepted this class. | | `selfAttested` | The person said so. Honest, visible, and first-class. | No; participation credit only. | | `inconclusive` | Evidence was gathered but the claim was not established. | No; never advances settlement. | Implementations MUST render assurance with a visible word and a non-color cue such as shape or icon. An implementation MUST NOT relabel an existing phase at a stronger assurance class after issuance. ## 5. Forbidden receipt material Protocol objects MUST reject fields or payloads containing: - coordinates, latitude, longitude, altitude, or distance to a target; - health samples, totals, derived health metrics, or workout records; - image, audio, or video content, including hashes of private media; - answer choices, transcripts, or raw interaction sequences; - motion, heading, acceleration, or other sensor streams; - opaque metadata intended to smuggle any forbidden material. Implementations MAY keep raw evidence locally for the minimum time required to evaluate a claim. Local retention and deletion MUST be disclosed before acceptance. Raw evidence is never part of Ad+Card interoperability. ## 6. Human consent and disclosure Before a person accepts an Offer or module, an implementation MUST show: - **GOAL** — what this moment is for; - **USES** — which capabilities are needed now; - **STORED** — what remains after the moment; - **SHARED** — what can leave the device and with whom; - **VALIDATES** — the exact claims that may be issued; - **REWARD** — what can settle and at which assurance class; - **EXPIRES** — when the offer and its authority end. The displayed disclosure and the signed Offer MUST describe the same terms. ## 7. Conformance roles ### 7.1 Card wallet A minimal Card wallet can create, hold, export, and delete Declarations. It MUST default to private visibility and per-card keys. ### 7.2 Instrument An Instrument executes disclosed modules and issues Receipts. It MUST enforce the forbidden-material boundary and preserve assurance. ### 7.3 Market A Market matches Declarations to Offers and settles accepted Receipts. It MUST reject unfunded commercial offers, forbidden fields, hidden eligibility, and unaccepted assurance classes. One entity MAY implement all three roles. The protocol exists so it does not have to be the same entity. Until the public conformance suite is released, implementations SHOULD say “implements the Ad+Card 0.1 draft,” not “Ad+Card certified.” ## 8. Threats the draft must resist - linking a person’s cards without visible opt-in; - inferring a Declaration from tracking and presenting it as person-authored; - replaying an old Receipt into a new settlement window; - hiding an unfunded or changed Offer behind the same identifier; - upgrading `selfAttested`, `corroborated`, or `inconclusive` evidence; - smuggling raw evidence into free-form or opaque fields; - coercing a reusable identity key as the price of participation; - using health-derived information in eligibility or commerce. ## 9. Open questions for 0.2 - JSON canonicalization and signature suite. - Passkey-backed key management, recovery, and rotation. - Receipt revocation and disputes without silent history rewriting. - Replay protection and settlement nonce profile. - Category taxonomy and extension governance. - Instrument and escrow attestation profiles. - Public test vectors and reference-validator release process. - Accessibility and localization rules for human disclosures. ## 10. Changelog ### Draft 0.1 — 2026-07-18 - Published the three-object model for public review. - Defined the four assurance classes. - Made stopped attempts first-class Receipts. - Defined the forbidden raw-evidence boundary. - Added implementer roles and explicit draft limitations.