CLONESHOP: gameplay treatment

Identity forgery capability module, KN-86 Deckline expansion concept

Design state: Josh made the premise and every design decision below in the 2026-08-22 design session; this treatment records them, including the same session’s endgame rulings (the two-path capstone, the Deck Hub brokerage, reputation-event blowback, flags on the legend). Tier 2 is unwritten; Tier 3 holds only the implementation seam. This document carries no knob values, no key tables, and no cell types. v1.1 | 2026-08-22

Tier 1 — Treatment

The hook

CLONESHOP is the identity forger’s workshop. Operators have no legal identity (the Identityless Premise, aethernet.md), the synthetic identity is the economy’s capstone purchase (development-document.md), and CLONESHOP is where identities are made. The cart is the endgame of the deck: the operator forges identities for clients all game, and the final work is forging their own and taking it through the government’s automated screening.

The capstone has two paths (Josh, 2026-08-22). The synthetic identity can be bought outright through the shop, at heavy credit cost, and the buyer does not know the legend’s weak points. Or it can be forged here, claim by claim, screened as it is built, so the maker knows every claim. Both paths end at the same screening gate.

What the operator does

A legend is a list of claims

A legend, the forged life, is a list of claims. A claim is structured data: type, entity, date range, role. Example: EMPLOYMENT, Hayashi Grid, dock clerk, 2039 to 2041. Entities are the generated world’s companies, districts, and institutions (world-engine.md). No prose appears anywhere in the mechanics. The identity renders on screen as a walkable text structure, rooms as chapters of the life, because the deck renders everything as text structure; the rooms are display only, never mechanics.

Backing has three levels

Every claim needs backing, and backing has three levels.

1. Paper only. A forged document, with no system behind it. Survives a glance.
2. One planted record. The operator broke into the system that holds such records (a company HR host, a housing registry) and inserted a row. The registry answers when queried. Survives a normal check.
3. Corroborated. Several systems agree (employer record, tax mirror, transit pattern), each one a separate break-in. Survives deep screening.

More intrusion work per claim buys a stronger claim. A record inserted today carries a fresh stamp; backdating and trail-scrubbing are follow-up jobs.

Planting a record reuses the whole game

Finding the host, riding it, and cutting its defenses are the existing recon and intrusion loop (bzbx, CONDUIT, ICE Breaker). The payload changes: the game inverts at the end, from breaching systems to take things to breaching systems to leave things. The operator breaks into the system that holds such records and leaves a row behind; from then on the registry answers when queried. How the row lands in the world is Tier 3’s sentence.

Pre-checks cost suspicion

The operator can test one claim at a time against the public verification surface, pass or fail. The scanner logs queries: repeated probes against an identity that has never been used read as fraud probing, so every pre-check adds a flag to the legend itself. Flags are properties of the legend object, never of the operator (Josh, 2026-08-22): the operator’s own visibility state (invisible, emitting a signature, hunted; aethernet.md) and the region trace do not move on a pre-check. How many checks to burn before the final screening is a wager: each one buys certainty and adds a flag.

Internal and external coherence

Internal coherence checks claims against each other: date gaps, overlapping residences, employment at a company after its closing date. The workshop editor runs this mechanical rule-checking for free, like a compiler showing errors before submission. External coherence checks claims against records the operator cannot see: does the tax mirror agree, is someone already registered at that address. That is knowable only where the operator has broken in or observed. Final-screening uncertainty is proportional to recon coverage, never artificial.

The screening, beat by beat

The scanner audits claims one at a time to its scrutiny depth. A checkpoint selling a bus pass audits little; the full citizen screening audits deep. Green results scroll. On a failed check the game stops with three choices, drawn from the operator’s inventory:

• Present a backup document. Consumes it.
• Grease. Spend credits. Works at low scrutiny and leaves a corruption trail.
• Withdraw. Abort, forfeit the fee, walk away free.

Withdrawing in time is the skill.

Client work is the rehearsal ladder

All game the operator sells identities to NPC clients at the lower backing levels. Client orders are placed and their outcome mail returns through Deck Hub, the deck’s acquisition surface (deck-hub.md); SynthFence’s spec is untouched (Josh, 2026-08-22). Outcomes arrive as mail: the courier made it through the northern checkpoint or did not, and credits and reputation move on the news. A failed cheap identity can be traced back to its maker: the trace-back arrives as mail carrying a reputation hit with a named cause, so sloppy work under deadline pressure is a risk the maker took. By the time the operator’s own name is on the table, they have watched dozens of screenings from the other side, all in text.

Harvested material

Recovered memory files of dead operators, acquired during runs or bought on black markets, contain lived records that can be lifted into a legend: perfect backing, wrong history. If the screening system holds the donor’s records, the match fails the legend as a known ghost, the worst outcome in the cart.

Seen records become casting material

While inside a system planting a row, the operator sees adjacent records. This is the batch-file moment: the forged row is 4,502, and rows 4,501 and 4,503 are real people. Seen entries are captured as DOSSIER references (dossier.md) and become casting material: future missions can target names the operator scrolled past. Generation draws on those references, so detail accumulates along the paths the operator has traveled.

Feel

The workshop is quiet: assembling claims, running the internal checker, reading the file at leisure. The pressure lives in the field work that backs each claim and in the screening room, where a green scroll pays off weeks of preparation and one failed check turns the session into a three-button decision with freedom on the table. The long arc runs from selling paper-only identities to couriers up to the one screening where the client is the operator.

Feasibility verdict

• Reuses: the recon and intrusion loop (bzbx, CONDUIT, ICE Breaker) for the break-ins that back a claim; the World Engine’s generated entities as the claim vocabulary; the sanctioned mission-outcome pattern for planted records (Tier 3 names the contract); DOSSIER references for seen records; Deck Hub’s acquisition surface for the client brokerage and its outcome mail; the World Engine’s scheduled arrival timeline for those outcomes.
• New surface required: the persistent record store (persistent-record-store.md). Planted records and seen-record references must survive across missions and cartridge swaps; that store is the one new engineering requirement this treatment adds.

Boundaries

• RESURRECTION, GHOSTLINE, and RECITATION in the concept library (future-concepts.md §12) overlap the memory-file half of this treatment. Treat them as neighbors: a future pass merges the overlap into one design and does not duplicate it.
• The influence and propaganda concept (§11 of the same file) is a separate concept and stays separate.
• DOSSIER stays the store of facts. CLONESHOP artifacts (legends, claims, backing) are never a second database: seen records land as DOSSIER references, and planted records land in the persistent record store.

Settled since v1.0 (Josh, 2026-08-22)

• The capstone has two paths. Bought outright (heavy credits, and the buyer does not know the legend’s weak points) or forged claim by claim in CLONESHOP, where the maker knows every claim. Both paths end at the same screening gate.
• The fence question. The brokerage is Deck Hub’s: client orders for forged identities and their outcome mail run through the acquisition surface (deck-hub.md), and SynthFence’s spec is untouched.
• The heat question. Maker blowback from a traced-back client identity is a reputation event: mail carrying a reputation hit with a named cause. No new meter, and the visibility vocabulary is unchanged.

Open questions

Recorded, unanswered:

• Whether the final screening needs a live layer beyond the three-button audit.
• How record aging is priced.
• The cart-versus-program shape of the workshop.

Tier 3 — Implementation seam

Implementation seam (GWP-806): C files, FFI names, and ADRs may appear here.

• The planted-record write path. A planted record is an engine-applied outcome of a resolved mission through the sanctioned mission-outcome path: the cart reports a goal and the engine mutates its own world (the ADR-0043 objective model and the ADR-0055 mission-end contract). No cart writes world truth. The durable table is the persistent record store (persistent-record-store.md).
• Client-job settlement. Client jobs resolve as contracts, so mission resolution stays the sanctioned wallet writer for the fee (the GWP-718 evented setters; economy-model.md). Outcome mail carries narrative plus the reputation event; the mail itself writes nothing.
• Legend flags. Pre-check suspicion flags and screening scrutiny live on the legend object, outside the engine’s operator visibility state (aethernet.md, the rule 7 note).