Made With — consent that travels both ways

• 

• 

• 

• 

Team name

Made With

Track and lane

Creative · Build lane

Short summary

Freelance illustrators, designers and writers are now required to disclose how their work was made — by client contracts, marketplace policy, and competition rules. The only two ways to comply today are to hand over your whole process, or to assert it and hope you're believed. One over-discloses your competitive advantage; the other isn't proof.

Made With adds two small objects to AI Passport. A Use Grant travels into an AI tool alongside your taste and portfolio context — purpose-scoped, time-boxed, revocable. A Work Receipt travels back out, proving which passport slices the tool read under which grant, without ever containing the work. The creator chooses, per piece, how much of that anyone else sees. The default is nothing. The maximum is still not your drafts.

The problem you are solving

AI Passport's premise is that your context should travel: Goals, Knowledge, Purchases, Preferences, Taste, Apps. For a creative professional that list isn't preference data — taste, references and past work are the entire asset. It's the thing they sell. That makes creative work the place where the passport is most valuable and most dangerous, and it breaks in two directions at once.

Inbound: connecting your taste to an AI tool is all-or-nothing and permanent in effect. There's no way to say the true thing a creator wants to say — use this to serve me, never to train on, never to serve someone else a prompt in my style, and stop in November. Consent today has no purpose field, no expiry, no revoke.

Outbound: what comes back carries no record of how it was made. But client contracts now routinely contain AI clauses, stock and craft marketplaces require declarations at upload, and juried competitions ask for a process statement. Satisfying any of those today means handing over drafts, prompts and layer files — a privacy loss and a competitive giveaway, since your process is your method — or writing "no AI was used" in a text box, which is the end of the verification story.

There is a third thing that should exist: proof of process that does not contain the process.

The user or group affected

Working freelance creatives who use AI tools and sell to clients or through marketplaces — illustrators, designers, copywriters, session musicians, video editors. They're the group where all three pressures land at once: they must disclose, they can't afford to over-disclose to competitors, and they have the least leverage to negotiate terms.

Specifically not "creators" in the abstract. A salaried designer at an agency has a contracts team between them and the requirement. A hobbyist faces no requirement at all. The freelancer absorbs it personally, at the moment of upload, with no counsel.

Secondary: the counterparties currently forced to just trust them — commissioning clients, marketplace review teams, competition juries. Not adversaries here. They're being asked to make decisions on unverifiable text-box declarations, which is bad for them too.

How AI Passport is used

Built on primitives ego.ist already has — connected apps, reviewable slices, per-app permission, an audit of what was used, and a public page at ego.ist/i/[handle].

The tool checks the Use Grant before reading any slice. An expired or revoked grant fails closed — the read is refused, not degraded. Purpose isn't free text; it's three independent booleans, because these are the three questions creators genuinely answer differently:

• serve_me — use my context to do my work → yes
• may_train — retain my context to improve the model → no
• may_serve_others_in_my_style — let other users prompt in my style → no

At session end the tool emits a Work Receipt: which slices were read, under which grant, when, and a content hash of the output. The creator attests the categories of assistance. That attested receipt is what a client or marketplace checks.

What context, permission, proof, or access is involved

Context: existing slices — Taste, Knowledge (references/portfolio), Preferences — plus one added slice, Style. Permission: the Use Grant — named slices, named purpose, named expiry. Grants without an expiry cannot be issued; twelve months is the ceiling. Proof: the Work Receipt — slices read, grant id, timestamp, sha256 of the output. It contains a hash, which lets anyone confirm this receipt belongs to this file while revealing nothing about the file to someone who doesn't already have it. Access: three disclosure levels, chosen per piece of work.

• L0 — nothing. No badge exists. Default.
• L1 — "AI assistance used · ideation, reference". For a marketplace upload.
• L2 — L1 plus which tool, and when. For a client whose contract requires it.
• L3 does not exist. The passport never receives the work, so drafts and prompts are not disclosable — by construction, not by policy. A design that merely promises not to show your drafts is one product decision away from showing your drafts.

Who controls access

The creator, unilaterally, at every step.

Grants are issued to one app at a time, slice-level not account-level — granting Taste doesn't grant Knowledge. Receipts are creator-held and private by default; an app emits a receipt to the creator, it doesn't publish one. Publication is per-receipt and reversible. Counterparties get read-only revocable links — a client shown an L2 badge holds a link, not a copy, and not an account.

No counterparty can grant themselves access, escalate a level, or retain access after revocation. There is no admin, no marketplace-side dashboard, and no "verified creator" tier.

What can be revoked or changed

Changeable: slices in a grant (narrow it), expiry (shorten it), purpose flags, the disclosure level of any published badge, and the attested categories — with the edit recorded, since silently rewriting your own attestation history would make the whole thing worthless.

Revocable: a grant (future reads refused); a published badge (reverts to L0 instantly); a whole app connection (every grant to it at once).

What revocation does to the past: past receipts are not deleted — deleting them would let a creator quietly erase a disclosure a client relied on. They're stamped consent_withdrawn, with the date. A counterparty checking an old badge sees that it was valid and has since been withdrawn. That's the difference between revocation and amnesia.

Risks or misuse concerns

1. Coercion — the biggest risk by far. If marketplaces begin requiring a badge, a voluntary consent tool becomes compulsory surveillance of creative process, and the creators with least leverage can't refuse. Mitigation: L0 must remain a legitimate, unpenalised state — so never ship a verified tier, a trust score, a badge count, or a directory filterable by disclosure. Those features are the mechanism by which optional becomes mandatory. Refusing to build them is stronger than any privacy policy.

2. The badge becomes a purity test. A "100% human" marker creates a hierarchy and pressures people to under-report real assistance, corrupting the data the system exists to produce. Mitigation: no percentage, no score, no ranking. An unordered set of categories, with no way to render "more human than" in the UI.

3. Receipts are a behavioural log. Every AI tool you used and when is subpoenable, breachable, saleable, and reveals working hours and creative dry spells. Mitigation: the passport stores grants and hashes, never work; receipts are creator-held and local-first; no aggregate analytics surface over receipt history for anyone; sessions at hour granularity.

4. False attestation — and the limit of what this proves. A creator can attest "ideation only" having generated the whole thing. The receipt does not prevent this and we don't claim it does. What's cryptographically checkable is narrower: which slices which app read, under which grant, at what time, against this output hash. The human/AI split is a signed declaration, not a measurement — closer to a tax filing than a proof. Its value is that it's on the record, attributable, timestamped and revocable, so a false one is a durable liability rather than a deniable sentence in an email. Any entry claiming to verify human authorship is overclaiming, and a creator relying on that claim will eventually be badly let down.

5. Style-lock. A passport carrying "your taste" pins you to work you've already done. Mitigation: Style and Taste slices expire by default, are opt-in per app, and a creator can hold multiple disjoint style slices so exploratory work isn't forced through the same identity as commissioned work.

6. Deanonymisation. A badge links work to a persistent handle — a real hazard for creators working pseudonymously for safety reasons. Mitigation: badges resolve to a per-work pseudonymous identifier by default; linking to the public handle is separate and reversible.

7. Uneven enforceability. Revoking future reads is enforceable. Deleting context a tool already copied is a contractual promise, not a technical guarantee. Mitigation: say so in the consent UI at the moment of granting, not in terms of service. The design makes non-compliance visible — reads against a dead grant surface in the ledger — which is the honest ceiling for what any consent layer can do.

Inspiration

Freelance creatives are now required to disclose how their work was made — by client contracts, marketplace upload policies, and competition rules. The only two ways to comply today are to hand over your entire process, or to assert it in a text box and hope you're believed. One over-discloses your competitive advantage; the other isn't proof. We'd hit the same wall before: our earlier project ProofPrint built chain-of-custody for AI-generated files, and the lesson it taught us was that the moment a provenance tool implies it verifies authorship rather than custody, it's lying. AI Passport — a personal context layer that already carries Taste, Knowledge, and Preferences across AI apps — is the first product we've seen where consent for the person could work the same way.

What it does

Made With adds two small objects to the passport a creator already has:

• A Use Grant travels into an AI tool alongside your taste and portfolio slices. Purpose is three separate booleans — serve_me, may_train, may_serve_others_in_my_style — because those are the three questions creators genuinely answer differently. Every grant expires; grants without expiry can't be issued.
• A Work Receipt travels back out: which slices were read, under which grant, when, and a sha256 of the output. The creator attests the categories of assistance and picks a disclosure level per piece — L0 (nothing, the default), L1 (categories only), or L2 (plus tool and session). There is no L3. The passport never receives the work, so drafts and prompts aren't disclosable — by construction, not by policy.

Revocation kills future reads instantly, but past receipts are stamped consent_withdrawn, never deleted — deleting them would let a creator quietly erase a disclosure a client relied on. Revocation, not amnesia.

How we built it

A single self-contained HTML page — no framework, no backend, no build step — that walks the full loop live: scope a grant, watch the JSON object update as you toggle slices and purpose flags, receive a receipt, flip disclosure levels and watch what the client sees change, then revoke and watch a read against the dead grant get refused and surfaced in the audit ledger. The object schemas (use_grant, work_receipt) are real JSON designs, not illustrations — every field earns its place, and what's absent from each object is called out on the page.

Challenges we ran into

The hard part wasn't the mechanism — it was refusing features. Every obvious "improvement" (a verified-creator tier, a human-percentage score, a searchable badge directory) is the exact mechanism by which a voluntary consent tool becomes compulsory surveillance of creative process. The design work was mostly subtraction.

Accomplishments that we're proud of

The honesty of the edges. The receipt does not prevent false attestation and the page says so plainly: what's checkable is which slices which app read under which grant; the human/AI split is a signed declaration — closer to a tax filing than a proof. And revocation's limits are stated at the moment of granting, not buried in terms: future reads fail closed, deletion of already-copied context is contractual — but non-compliance is visible, because reads against a dead grant surface in the ledger.

What we learned

Minimum sufficient disclosure is a stronger design principle than maximum verification. The counterparty checking a badge needs exactly one fact — was AI used, and how — and every additional fact the system could carry is a liability for the creator, not a feature.

What's next for Made With

One real connector. The v1 that should exist is a single AI tool checking a grant before reading passport slices and emitting a receipt at session end — proving the fail-closed loop end-to-end with the passport's existing permission and audit primitives.

Built With

• css3
• ed25519
• github
• html5
• javascript
• json
• sha256