The Sovereign Spine: A Two-Phase Blueprint for Private Identity and Public Enforcement

Red Anvil Creative | Wednesday, April 29, 2026

The Sovereign Spine

A Two-Phase Blueprint for Private Identity and Public Enforcement

Document	Clockwork Butterfly + Pitchfork Foundry — Product Requirements Document
Version	v1.2 (Working Draft)
Author	Redwin Tursor
Consultation	Rhombus Ticks
IT Design	Thomas Craig Ricks
Date	April 2026
Status	For internal review and partner solicitation
Audience	Founding engineers, prospective backers, member-contributors, pilot legal partners, civil liberties allies
Changes from v1.1	Identity Vault extracted and renamed Clockwork Butterfly. Now Phase 1: standalone open-source primitive. Pitchfork Foundry becomes Phase 2. Service count reduced. Watermarking non-negotiable.

1. Executive Summary

This document specifies two related products built in sequence by the same founding team and shipped to overlapping but distinct constituencies...

PART I: CLOCKWORK BUTTERFLY

5. System Components

Component	Function
The Vault	Local-first encrypted credential store on the user’s device. No cloud backup by default.
Credential Receivers	Receives W3C Verifiable Credentials from any issuer the user trusts.
Selective Disclosure Engine	Constructs Verifiable Presentations without revealing underlying identity.

1. Executive Summary

This document specifies two related products built in sequence by the same founding team and shipped to overlapping but distinct constituencies.

Phase 1 is Clockwork Butterfly: an open-source, user-controlled digital identity primitive that lets a person prove a property about themselves — over 18, harmed party in a specific matter, citizen of a jurisdiction, holder of a credential — without revealing the underlying identity to the verifier or to any central authority. It is funded through Kickstarter and ships as a standalone product before Phase 2 begins.

Phase 2 is Pitchfork Foundry: crowdfunded, source-available infrastructure for economic justice enforcement that uses Clockwork Butterfly as its identity layer. It ingests harm narratives, transforms them into certified Letters of Marque through hybrid AI-and-human review, and matches them to plaintiff-side firms through a blind RFP marketplace. It is funded through Open Collective and validates Clockwork Butterfly by being its first major civic application.

The two products share a founding team, a threat model, a governance posture, and a refusal to take government grants, foundation grants, or institutional capital. They are independently shippable and independently useful. Together, they are a more ambitious project: identity sovereignty as the foundation for enforcement infrastructure that the public owns, funds, and defends.

1.1 Why Two Products

An earlier draft of this PRD treated the identity layer as an internal compartment of the enforcement platform. That was wrong. The identity layer has its own constituency, its own threat model, its own funding logic, and its own urgency. Building it inside the enforcement platform would have hidden it from the people who need it most and tied its survival to a project most of them do not care about.

Separating the two phases produces three benefits. First, the identity layer reaches a much broader constituency — parents who do not want their kids in government databases, queer kids in hostile states, abuse survivors, sex workers, journalists, immigrants, dissidents, libertarians, and ordinary people who are tired of uploading their driver’s license to every website. Second, the enforcement platform’s most legally precarious component (the identity vault) becomes a battle-tested, externally validated product before any harmed claimant relies on it. Third, the funding asks are clean: Kickstarter for the install-and-use product, Open Collective for the operational-infrastructure organization.

1.2 Threat Model

Both products are designed against the same threat profile: well-resourced corporate defendants with sophisticated counsel, coordinated industry coalitions with political-influence capacity, and the realistic possibility of state-actor pressure exercised through tax authorities, financial-intermediary pressure, platform deplatforming, regulatory weaponization, and mandated identity-verification regimes that function as surveillance infrastructure. Any architecture that depends on a single funder, a single hosting provider, a single jurisdiction, a single payment processor, a single distribution channel, or a single government issuer is presumed compromised.

2. Founding Context and Existing Audience Assets

This project does not begin from zero. The principal consultant is the operator of a 334+ episode podcast (Tossing Grenades at Windmills, now Codex Americana), the author of 57+ published titles including ten novels, and the proprietor of an established analytical-writing footprint covering institutional capture, antitrust, governance failure, and adversarial-system design. The IT designer brings nine years of senior technical product management across regulated industries (insurance, healthcare, hospitality, financial services, telecom).

This matters operationally and strategically. Operationally: the audience-building target for Phase 2 is not from-cold; the popularization spine connects to existing readers and listeners, and the technical architecture is not first-time work. Strategically: the project’s credibility with skeptical funders and pilot partners benefits from a documented track record of pattern recognition, institutional analysis, and shippable technical product.

It also creates a constraint. The principal’s existing public footprint includes politically charged analysis. The project’s defense against capture and pressure is the soundness of its architecture and the breadth of its constituency, not the political posture of any one contributor. Public-facing communications from the project itself will be calibrated accordingly.

PART I

Clockwork Butterfly

3. Clockwork Butterfly: What It Is

3.1 One-Paragraph Description

Clockwork Butterfly is a free, open-source, user-controlled digital identity vault that lives on a person’s own device. It lets the user receive credentials from sources they choose, hold them privately, and prove specific properties to verifiers — “yes, this person is over 18” — without revealing the underlying identity to the verifier, to any central authority, or to any government issuer. It is engineered for the use case the existing market does not serve: people who need to prove something about themselves without becoming legible to surveillance infrastructure that may be turned against them.

3.2 The Specific Problem It Solves

In 2026, a wave of mandated identity-verification regimes is being implemented or proposed across multiple jurisdictions: the UK Online Safety Act, US state laws in Louisiana, Texas, Utah, and others requiring age verification for online services, the Federal Trade Commission’s new policy statement encouraging COPPA-aligned age-verification technologies, and federal proposals such as the Kids Online Safety Act. These mandates are presented as protections for vulnerable populations — particularly minors. In implementation, they require ordinary users to upload government-issued identification, biometric data, or full identity profiles to private verification services that store, analyze, and are subpoenable for that data.

The harms are foreseeable and documented. Identity-verification databases are breached at scale. Mandated verification chills lawful speech, particularly for queer adolescents in hostile jurisdictions, abuse survivors using anonymous resources, sex workers, journalists protecting sources, and immigrants. The verification systems become surveillance systems by another name, and the populations the mandates ostensibly protect are often the populations they expose to the greatest harm.

Clockwork Butterfly does not oppose age verification. It opposes age verification implemented in ways that destroy anonymity and concentrate identity data in databases vulnerable to breach, subpoena, and political weaponization. The architectural answer is selective disclosure: prove the property the verifier legitimately needs to know, reveal nothing else, leave no central record of the proof’s contents.

3.3 Why This Has Not Already Been Built

The cryptographic primitives Clockwork Butterfly relies on have existed since the 1980s. The relevant W3C standards (Verifiable Credentials, Decentralized Identifiers) have reached production maturity. Multiple wallets, both government and corporate, are shipping selective-disclosure functionality in 2026. The reasonable question is: if the technology exists and the need exists, why has no one shipped the product Clockwork Butterfly proposes?

Six structural reasons:

1. Government-issuer dependency. The major rollouts — the European Digital Identity Wallet under eIDAS 2.0, equivalent programs in Singapore, the UAE, Canada, and the United Kingdom — all anchor credentials to government issuers. They support selective disclosure but require trust in a state authority that issues, can revoke, can be subpoenaed for issuance records, and now operates a new mechanism for verifying citizen activity at scale. For users whose threat model includes their own government, this is the wrong design.

1. Corporate or chain control. Web3 implementations tie identity to blockchain wallets, which makes every interaction permanently linkable to a public on-chain identifier. Corporate implementations tie identity to a vendor whose business model is the data the user is trying to protect. Neither serves the constituency Clockwork Butterfly is built for.
2. Funding gap. The community open-source layer of self-sovereign identity is structurally underfunded. Government-issued wallets are funded by governments. Enterprise wallets are funded by enterprises. The user-aligned, government-independent, corporation-independent layer has no natural funder in the existing market. Crowdfunding from the public the layer is built for is the funding mechanism that has not been tried at sufficient scale.
3. UX gap. Existing implementations require the user to understand decentralized identifiers, credential flows, key management, and cryptographic abstractions. The constituency that needs Clockwork Butterfly most — people who are not technical, who have never heard of a DID, who do not own crypto — is the constituency every existing implementation has failed to serve.
4. Interoperability gap. Despite standards, implementations remain fragmented. Each existing wallet is optimized for its issuer’s ecosystem. None is optimized for the use case “user wants to prove a property to any verifier that needs only the truth value, not a chain of state issuance.”
5. Political window. Mandate-creep is happening now. The implementations being mandated or encouraged are surveillance-compatible. The architectural alternative needs to exist as deployed, working software before the mandates are settled, not after. The window for shipping a credible alternative is open and is not open indefinitely.

Clockwork Butterfly’s pitch is not that it invents anything. It is that it ships the implementation that the existing market is structurally incapable of shipping: opinionated, user-controlled, no-government-issuer, no-blockchain-required, UX-first, open-source, and funded by the public it serves.

3.4 What It Does Not Claim

• It does not claim to compete with the European Digital Identity Wallet on scale. EUDI will reach hundreds of millions of users; Clockwork Butterfly will reach a smaller audience aligned with its design principles. The two are complementary in the populations they serve.
• It does not claim to invent new cryptography. It composes existing primitives — Verifiable Credentials, BBS+ signatures, zero-knowledge proofs of attribute possession — into an opinionated implementation.
• It does not claim to defeat any specific piece of legislation. Legislation evolves; architecture endures. The pitch is for an architecture that makes mandate-creep harder to enforce against people who choose to use it.
• It does not claim that adopting Clockwork Butterfly will be lawful in every jurisdiction. In some jurisdictions, possession of unmandated identity infrastructure may carry legal risk. The product does not advise users to break laws; users are responsible for assessing the legality of its use in their own jurisdictions.

4. Clockwork Butterfly: Users

4.1 Primary Constituencies

The five constituencies below are illustrative composites drawn from documented threat profiles in published reporting on identity-verification mandates, abuse-survivor advocacy, source-protection literature, and FCA claimant intake patterns. They are not interview-derived. Pre-launch validation engages at least one consultative contact per constituency, sourced through aligned advocacy organizations, with findings documented before the Kickstarter campaign opens.

4.1.1 The Parent (Carmen)

Carmen has a thirteen-year-old who uses social media. She supports keeping age-restricted content away from minors. She does not support uploading her child’s face or identification to a private verification vendor that will store, analyze, and potentially leak the data. She wants a tool that lets services confirm her child is under thirteen without becoming a permanent record of her child’s online life.

4.1.2 The Adolescent in a Hostile Jurisdiction (Riley)

Riley is sixteen and lives in a state where libraries have removed books about queer adolescence and where the political environment is dangerous to be visible in. They need access to information and community. Existing age-verification regimes would force them to either lie about their age (creating account-termination risk) or hand over identification that ties them to topics they cannot afford to be linked to. Selective disclosure — “yes, this person is at least sixteen” — solves Riley’s problem in a way no existing wallet does.

4.1.3 The Survivor (Diane)

Diane left an abusive partner two years ago. Her ex has resources and connections. She uses online support resources for survivors and occasional anonymous adult-content services as part of her recovery. Every identity-verification database is a potential vector for her ex to locate her. She needs to prove she is over 18 to access services she has every legal right to access, without producing any record that links her presence on those services to her real identity.

4.1.4 The Journalist’s Source (Marcus)

Marcus has documents that prove fraud at his employer. He wants to provide them to a journalist. The journalist needs to know Marcus is who he says he is — a current employee with the access claimed — but neither of them wants the journalist’s organization to be able to identify Marcus under subpoena. Verifiable-credential proofs of employment, presented through Clockwork Butterfly, let Marcus authenticate without exposing his identity to the journalist’s organization at all.

4.1.5 The Pitchfork Foundry Claimant (Maria)

Maria is the Phase 2 user from the original PRD. She has been overcharged by a hospital. She wants to submit a claim to Pitchfork Foundry without exposing her identity to the platform’s contractors, the platform’s hosting provider, or any future adversarial discovery. Clockwork Butterfly is what makes that possible: she proves she is the person who experienced the harm without ever transmitting her identity to a database that can be breached or compelled.

4.2 Why These Constituencies Matter Together

These five users have nothing in common politically. The libertarian father, the queer adolescent, the abuse survivor, the journalist’s source, and the harmed Medicare beneficiary do not vote the same way and do not see themselves as part of the same coalition. They are unified only by the architectural answer to their problem. That is a feature: Clockwork Butterfly’s constituency is broader and more politically resilient than any single political coalition, because the harm of mandated identity verification cuts across coalitions in ways the political class has not yet absorbed.

5. Clockwork Butterfly: System Components

5.1 What Ships in v1.0

Component	Function
The Vault	Local-first encrypted credential store on the user’s device. Mobile (iOS, Android) and desktop (Linux, macOS, Windows). Encrypted at rest with a key derived from a user passphrase plus device hardware secure enclave where available. No cloud backup by default; opt-in encrypted-blob backup with user-controlled keys.
Credential Receivers	Standardized issuer interface. Receives W3C Verifiable Credentials from any issuer the user trusts: government documents (where the user chooses to import them), employer credentials, educational credentials, peer-attested credentials (e.g., affinity-group attestations), and self-attestations.
Selective Disclosure Engine	Constructs Verifiable Presentations: cryptographic proofs that the holder possesses a credential satisfying the verifier’s requirement, without revealing more. Supports threshold proofs (“over 18”), set-membership proofs (“citizen of one of these jurisdictions”), and scope-bound proofs (“this proof is valid only for this verifier and this session”).
Verifier Interface	Open-source SDK and reference verifier service that platforms can deploy to accept Clockwork Butterfly proofs as a valid form of identity verification. Designed for trivial integration: a platform that accepts EUDI Wallet proofs can accept Clockwork Butterfly proofs with minimal additional work.
Pseudonym Manager	Generates and manages durable per-context pseudonyms. The user has one identity to themselves but presents distinct, unlinkable pseudonyms to different services. Compromise of one pseudonym does not compromise others.
Audit Log (Local-Only)	User-only record of every credential received and every proof issued. Never transmitted off device. Lets the user understand and control their own disclosure history. Can be wiped at user discretion.

5.2 What Does Not Ship in v1.0

• No reputation system. Reputation is a vector for re-identification and surveillance; it is deferred to a later version where the privacy properties can be carefully designed.
• No payment functionality. Clockwork Butterfly is identity infrastructure, not a payment system. Payment integration is out of scope.
• No messaging. The vault holds credentials and issues proofs; it does not handle communication.
• No blockchain. Some implementations use blockchains for credential anchoring or revocation. Clockwork Butterfly does not require any. Revocation is handled through issuer-published revocation registries that can be served from any web infrastructure.
• No central honeypot. There is no Clockwork Butterfly central server holding user data. The verifier-interface reference deployment is operated by the project but does not retain user information; it can be replicated by any verifier.
• No user accounts on a Clockwork Butterfly server. There is no account to be subpoenaed.

5.3 Architectural Non-Negotiables

• Local-first. The user’s credentials and the cryptographic keys protecting them live on the user’s device. The project does not operate a hosted vault.
• No central honeypot. The reference architecture has no server that holds user data. Compromise of project infrastructure does not compromise users.
• Open-source from day one. The code is auditable, forkable, and reproducible. Source-available licensing for commercial deployment; non-commercial users get the AGPL terms immediately.
• No required government issuer. Users can import government credentials if they want to. They are never required to. Self-attested and peer-attested credentials are first-class.
• Standards-compliant. Verifiable Credentials and Decentralized Identifier compliance, so credentials and proofs interoperate with other standards-compliant implementations including, where the user chooses, government-issued wallets.
• Reviewable cryptography. Established primitives, well-reviewed libraries, no novel cryptography. The trust comes from the auditability of standard parts, not from claims about new ones.

6. Clockwork Butterfly: Funding and Distribution

6.1 Why Kickstarter for Phase 1

Phase 1 is a defined product with a clear deliverable: an installable application across three desktop and two mobile platforms, with documented protocols and a reference verifier service. That is exactly the kind of thing Kickstarter exists to fund. The discovery surface of Kickstarter brings the product to people who are not already in privacy-advocacy circles. The pledge structure produces a finite, time-bounded fundraising event with a publicly-tracked progress meter, which is the right shape for a product launch.

Open Collective is reserved for Phase 2, where the funding model is ongoing operational support for an organization rather than a one-time product launch. Kickstarter would be the wrong fit for Phase 2 (an organization is not a Kickstarter project) and Open Collective would be the wrong fit for Phase 1 (it lacks the discovery surface that makes Kickstarter useful for first-time-product introduction).

6.2 Funding Targets

Tier	Amount	Unlocks
Minimum Viable	$200K	Desktop apps (Linux, macOS, Windows). Vault, credential receivers, selective disclosure, pseudonym manager. Reference verifier service. Open-source release. Integration documentation.
Stretch 1: Mobile	$350K	iOS and Android apps. Hardware secure enclave integration. App store distribution.
Stretch 2: Verifier Network	$500K	Outreach to ten major platforms in adult content, social media, gaming, and library e-resource sectors. Integration support. Public verifier directory.
Stretch 3: Audit	$650K	Independent third-party security audit by a recognized cryptographic-engineering firm. Public audit report. Bug bounty program.
Stretch 4: Operations Endowment	$850K	Two-year operational runway for maintenance, security updates, standards-track participation, and the maintainers’ continued work on the codebase.

6.3 Backer Recognition

Kickstarter backers receive what every Kickstarter backer receives: project updates, early access to releases, and recognition. They additionally receive a Founder Letter of Marque — a non-transferable Verifiable Credential issued through Clockwork Butterfly itself, certifying participation in the founding round. This is the first credential the system issues, and it doubles as proof that the system works end-to-end.

6.4 If the Round Underperforms

Tiered targets mean the project ships meaningful product at $200K and ships more at higher tiers. If the round closes below $200K, the project does not ship Clockwork Butterfly. The codebase, design, and documentation are released anyway, under the original license, for any future team that wants to build on the work. There is no scenario in which contributed funds are used and the product is not shipped.

7. Clockwork Butterfly: Roadmap

Phase	Milestones
Pre-Launch (Months -3 to -1)	Founding team committed. Existing audience prepared. Initial content series launched explaining the problem and the architecture. Pre-launch sign-up page on Kickstarter. Self-hosted contribution backstop built and tested in case Kickstarter delays or rejects the campaign.
Month 0: Launch	Kickstarter campaign opens. Six-week run. Daily updates across distribution spine.
Months 1–3: Core Build	Vault, credential receivers, selective disclosure engine, pseudonym manager. Desktop builds. Internal alpha.
Months 4–5: Verifier Interface	Reference verifier service. SDK. Initial integration partnerships. Public beta.
Month 6: v1.0 Release	Public launch. Open-source release. First production verifier integrations. Founder Letters of Marque issued.
Months 7–9: Mobile (if Stretch 1 met)	iOS and Android apps. App store submissions. Hardware secure enclave integration.
Month 9+: Phase 2 Begins	With Clockwork Butterfly stable and shipped, Pitchfork Foundry’s Open Collective round opens. Pitchfork Foundry uses Clockwork Butterfly as its identity layer. Phase 1’s working code is the proof Phase 2’s promise can be kept.

7.1 Risks Specific to Phase 1

• App store gatekeeping. Apple and Google may reject the mobile apps if they conflict with platform-mandated identity-verification requirements. Mitigation: ship desktop and side-loaded Android first; pursue app-store distribution as a secondary path; F-Droid as a guaranteed Android distribution channel.
• Standards drift. The W3C Verifiable Credentials and DID specifications continue to evolve. Mitigation: build against current stable releases; participate in standards-track work; design the codebase for protocol-version migration.
• Hostile legislation. Specific jurisdictions may pass laws that explicitly prohibit non-government identity infrastructure or treat it as evidence of intent to evade verification. Mitigation: legal review pre-launch; multi-jurisdiction maintainer team; the codebase is open-source and forkable, so the project can persist even where the original team cannot operate.
• Cryptographic vulnerability. An issue in an underlying primitive could compromise the entire system. Mitigation: rely only on well-reviewed primitives and well-audited libraries; mandatory third-party audit (Stretch 3); bug bounty; coordinated-disclosure policy.
• Misuse for illegal purposes. Any tool that protects identity can be used to evade legitimate accountability. Mitigation: the architecture intentionally does not prevent misuse, because architectures that distinguish good users from bad users are surveillance architectures. The project’s defense is that the same protection that benefits an abuser benefits an abuse survivor, and the choice the law has historically made is to extend the protection.
• Mid-campaign platform disruption. Distinct from rejection at submission. Kickstarter or its payment processor may suspend an active campaign under pressure after pledges have been collected, leaving the project with partial commitments and no settlement path. Mitigation: self-hosted contribution backstop validated and live-tested before campaign launch; pledge data exported daily; backer communications channel independent of the campaign platform; published continuity policy describing how partial-commitment funds are handled in a suspension scenario.
• Legislative response to a successful launch. A visible, working alternative to mandated verification regimes may itself become the subject of targeted legislation, distinct from the general mandate-creep already named under Hostile Legislation. The risk profile after Month 6 differs from the risk profile at Month 0. Mitigation: legal review cadence repeats post-launch on a six-month cycle; multi-jurisdiction maintainer team in place before mobile release; protocol-level interoperability with W3C-compliant wallets so that a regulatory action targeting Clockwork Butterfly specifically cannot disable user-side credentials in transit.

PART II

Pitchfork Foundry

8. Pitchfork Foundry: What It Is

8.1 One-Paragraph Description

Pitchfork Foundry is crowdfunded, source-available infrastructure for economic justice enforcement. It ingests harm narratives from consumers, workers, and small businesses harmed by monopolistic conduct, runs them through a hybrid AI-and-human review pipeline that classifies the harm, maps it to existing law, estimates damages, and packages viable matters into certified Letters of Marque, then matches those claims to plaintiff-side firms through a blind, watermarked RFP marketplace. It uses Clockwork Butterfly as its identity layer: claimants prove they are the harmed party without exposing their identity to the platform’s infrastructure. It is operated by a member-governed cooperative funded through Open Collective, with intake services delivered through an affiliated law firm structure to provide privilege friction against adversarial probing.

8.2 Why Phase 2 Comes After Phase 1

Pitchfork Foundry’s most legally precarious component is the identity vault that holds claimant identity data. In v1.1 of this PRD, that vault was an internal compartment of the platform — built by the founding team, validated only by its first uses, and load-bearing on day one. That created an unacceptable concentration of trust and an unacceptable single-point-of-failure: if the vault’s design had a flaw, every claimant’s identity was exposed before anyone outside the project had a chance to find the flaw.

Building Clockwork Butterfly first inverts that risk. By the time Pitchfork Foundry opens its doors, Clockwork Butterfly has been shipped, audited, used by a much broader population, and stress-tested by adversarial review. Pitchfork Foundry inherits a battle-tested identity layer rather than building one in private. The first Pitchfork claimant is not the first user of the identity vault; they are user N+1, in a system that has already been in production for months.

9. Pitchfork Foundry: Problem and Opportunity

Every year, millions of workers, consumers, and small businesses are harmed by monopolistic and fraudulent corporate conduct. Most receive no remedy. State and federal AGs are underfunded, politically constrained, and increasingly hostile under hostile administrations. Plaintiff-side firms reject roughly 95% of valid claims at intake because individual matters are too small or evidentiary lift is too high. Pro se filing is impossible for complex matters. Nonprofit policy organizations produce research and advocacy but cannot file cases and are vulnerable to funder pressure and 501(c)(3) status revocation.

The infrastructure required to convert diffuse, pattern-based, small-dollar harm into a sponsorable, fileable claim does not exist outside the heads of a handful of plaintiff-side specialists. The institutions that might have built it are themselves vulnerable to the same political and corporate pressure they would need to enforce against. Pitchfork Foundry builds that infrastructure under conditions of structural independence: no government grants, no foundation grants, no 501(c)(3) status, no venture funding, no institutional capture surface.

9.1 Why Now

• Algorithmic harm is now ubiquitous, but enforcement is still organized around one-defendant, one-plaintiff matters.
• Hospital and provider consolidation has pushed billing fraud out of regulator capacity and into private enforcement.
• Open-source AI models can do first-pass legal-theory mapping that previously required senior associates.
• Federal enforcement capacity is being deliberately degraded; traditional pathways for redress are closing.
• Distributed crowdfunding infrastructure is mature enough to fund operational infrastructure, not just one-off campaigns.
• Clockwork Butterfly will exist by Phase 2’s launch, providing the identity layer Pitchfork Foundry needs.

10. Pitchfork Foundry: Users

10.1 Primary Users

• Claimant. A person harmed by corporate conduct who submits a narrative and evidence. Identity authenticated through Clockwork Butterfly; never transmitted to platform databases.
• Whistleblower / Insider. A current or former employee with documentary evidence of fraud. Same identity model as claimant, with additional evidentiary chain-of-custody requirements.
• Sponsoring Firm. A vetted plaintiff-side firm that bids to sponsor verified claims through the RFP marketplace.
• Member-Backer. A person who contributes financially or operationally to the platform through Open Collective. Members govern the cooperative.
• Reviewer. A trained reviewer (paralegal-equivalent or supervised attorney, employed through Pitchfork Legal Partners) who handles human-in-the-loop verification.

11. Pitchfork Foundry: System Components

11.1 Component Overview

Component	Description
Secure Intake (built on CB)	Encrypted form with file upload. Identity authenticated through Clockwork Butterfly proofs; the platform never receives the claimant’s identity. Operated under Pitchfork Legal Partners.
Claimant Verification	Reviewer queue with manual checklist, integrity-score attestation, document hashing, chain-of-custody log. Reviewer access controlled by separation-of-duties: no single reviewer can de-anonymize and disclose without a second authorization.
Legal Theory Mapping	MVP: one vertical (hospital billing fraud / FCA). AI-drafted, reviewer-certified mappings to statute, elements, and evidence. Mandatory human certification on every Letter of Marque.
Letter of Marque	Structured certification record issued through Clockwork Butterfly: claim ID, theory mapping ID, evidence index hash, damages estimate, integrity score, issuing reviewer, signature. Immutable once issued.
Blind RFP Marketplace	Invite-only RFP rooms. Watermarked, derived-not-redacted anonymized packets. Per-recipient, per-download, per-time traceability. Watermarking is non-negotiable; not a candidate for cuts.
Sponsor Matching	Manual in MVP. Documented selection rationale. Identity disclosure to selected firm only after claimant consent and signed sponsorship agreement.
Recovery Tracking	Obligation ledger. Manual invoicing on closed matters. Capped per-origination fees, never percentage-of-recovery.
Member Funding & Governance	Open Collective integration with public transparent ledger. Self-hosted contribution backstop. Member registry and Letters of Marque (founder, vertical-backer) issued through Clockwork Butterfly.

11.2 Compartmentalization Architecture

• Identity Layer (Clockwork Butterfly). Lives on the user’s own device, not on platform infrastructure. The platform sees proofs, not identities. Compromise of platform infrastructure cannot expose claimant identities, because the platform never possessed them.
• Derived Claim Layer. Holds redacted summaries, legal-theory mappings, evidence indices, damages estimates, and Letters of Marque. References shadow IDs only. Operated by Pitchfork Cooperative.
• External RFP Layer. Holds anonymized, watermarked packets visible to sponsoring firms. Derived-not-redacted construction: packets are rebuilt from structured fields, never scrubbed from raw narrative. Eliminates the most common anonymization failure mode.

11.3 Insider Threat Controls

Reviewers are the highest-risk human element. A bribed, coerced, or compromised reviewer with access to verification workflows can defeat compartmentalization. v1 controls:

• Separation of duties. No single reviewer can perform the full chain from identity validation to disclosure. Sensitive operations require two-reviewer authorization, with the two reviewers drawn from different pools.
• Access pattern monitoring. Reviewer queries are logged at the database layer. Anomalous patterns (cross-claim queries, queries outside assigned matters, unusual time-of-day access) generate alerts independent of the reviewer’s own session.
• Cross-checks against the audit log. Every Letter of Marque issuance is cross-referenced against the reviewer’s access pattern; mismatches trigger review.
• Red-team mandate. The pre-launch red-team exercise includes explicit reviewer-compromise scenarios: a reviewer bribed by a defendant, a reviewer subject to legal threat, a reviewer who has been replaced by a hostile actor.

12. Pitchfork Foundry: Hard Problems

12.1 Privilege Friction at Intake

Pitchfork Legal Partners operates intake. Communications are framed as preliminary inquiry to the firm, with documented common-interest and confidentiality framing. The goal is friction against adversarial probing, not certainty of privilege in court. Outside counsel review pre-launch determines the minimum staffing model required to make the posture credible across the MVP’s three target jurisdictions (CA, NY, MA).

12.2 Re-Identification Risk in RFP Packets

Hospital billing fraud is among the most re-identification-prone verticals. Specific facility identifiers, date ranges, and billing codes that make a packet bid-able are the same fields that enable defendant identification, and from defendant identification, sometimes claimant identification. A re-identification testing protocol is mandatory before any external firm sees a packet:

6. Three to five real (consented) hospital billing scenarios run through the full intake pipeline.
7. The resulting RFP packet evaluated against three threats: (a) defendant identification by industry observer with public data, (b) claimant identification by defendant after defendant identification, (c) cross-packet correlation by an adversary with multiple packets.
8. Go/no-go gate: if any of the three threats produces successful identification, the packet template is reworked before the RFP Room opens.

12.3 UPL and Fee-Splitting

Two-entity structure (see §13). Capped fees, never percentage of recovery. Mandatory human certification on every Letter of Marque. Public legal posture document at launch. Outside counsel review pre-launch.

12.4 Adversarial-State Pressure

No 501(c)(3). No grants. No tax-deductible donations. Multi-jurisdiction infrastructure. Distributed contribution rails (Open Collective primary, self-hosted backstop). Source-available code. Forkable platform. Multi-platform popularization spine. Acknowledged residual risk: determined state-actor pressure can disrupt any project; the mitigation is friction and resilience, not invulnerability.

12.5 Funding Round Failure

Audience-first sequencing: the popularization spine is built before the launch round opens, leveraging existing audience footprint (see §2). Tiered minimum-viable targets so partial raises unlock partial scope. Pre-launch member registrations on Open Collective signal soft commitment before the formal round. Firm-side viability is validated in parallel: pre-launch consultative conversations with three to five plausible plaintiff-side firms in the FCA vertical confirm that the blind RFP construction, the Letter of Marque schema, and the proposed fee structure are economically credible from the sponsor’s perspective. Documented firm-side commitment to participate in the first RFP cycle is a prerequisite for opening the launch round.

13. Legal Structure and Funding Model

13.1 Two-Entity Structure

Entity	Role	Funding
Pitchfork Cooperative (member-owned, foreign-domiciled where feasible)	Holds platform IP. Operates infrastructure. Employs engineers. Governed by members under cooperative bylaws.	Open Collective member contributions. Firm subscriptions. RFP access fees. Capped per-origination fees.
Pitchfork Legal Partners (real law firm, admitted attorneys)	Operates intake services. Employs reviewers under attorney supervision. Provides privilege-friction posture. Structures sponsorship agreements where lawful.	Service-level fees from the Cooperative. Sponsorship-structuring fees from sponsoring firms.

There is no Foundation. There is no 501(c)(3). There is no government-grant-receiving body. The structure is designed against adversarial-state pressure, and 501(c)(3) status is one of the most reliably weaponized levers under hostile administrations.

13.2 Funding Streams

• Member contributions through Open Collective. Primary. Public transparent ledger. Self-hosted backstop ready to deploy if Open Collective access is disrupted.
• Launch round. Open Collective campaign. Tiered minimum-viable targets ($250K minimum, $500K full scope). Six-week run.
• Firm subscriptions. $500–$5,000/month tiered. Free tier for legal aid and public-interest organizations.
• Per-RFP access fees. $1,500–$5,000 per bid, refundable on losing bids.
• Capped per-origination fees. $25,000–$50,000 per successful filing or matter resolution. Never percentage of recovery. Cap set jurisdiction-by-jurisdiction by outside counsel review.

13.3 What We Do Not Take

The exclusions below are structural defenses against specific capture vectors documented in the threat model (§1.2), not a values statement. Each refusal is paired with the named pressure mechanism it removes from the project’s attack surface: tax-exempt status removes IRS-pathway revocation; government grants remove appropriations-pathway defunding; foundation grants remove funder-pathway program-officer conditioning; venture capital removes board-seat governance capture; corporate sponsorships remove conflict-of-interest exposure on enforcement targets. The project will reconsider any of these only on a documented showing that the corresponding capture vector has been independently neutralized.

• No 501(c)(3) tax-exempt status.
• No federal, state, or local government grants.
• No foundation grants from institutional philanthropy.
• No venture capital.
• No tax-deductible donations through any wrapper entity.
• No corporate sponsorships, no naming-rights deals, no in-kind partnerships with entities that have material conflicts with the enforcement work.

14. Technical Architecture

14.1 v1 Stack (Reduced from v1.1)

v1.1 specified eight services to be deployed across multiple zones with a three-engineer team. That count was too high. v1.2 reduces the v1 service count and defers non-essential services to v1.1+.

Layer	v1	Deferred to v1.1+
Application	Django + HTMX. Server-rendered.	React only for RFP room.
Database	PostgreSQL (single cluster, separate logical databases for derived layer and operational data).	Separate physical clusters when scale demands.
Object storage	MinIO. Server-side encryption.	—
Identity	Clockwork Butterfly for claimants. Django built-in auth for staff (reviewers, firms).	Keycloak deferred unless staff-side auth complexity demands it.
Search	PostgreSQL full-text. Sufficient for MVP scale.	OpenSearch when claim volume crosses threshold.
Pipeline orchestration	Django + Celery for queued tasks. Sufficient for MVP.	Dagster when AI workflows require auditable runs at scale.
AI / LLM	Self-hosted via Ollama. Open-weights models. No claim data leaves platform infrastructure.	vLLM for performance scaling.
Deployment	Hardened VPS, Docker Compose. Privacy-respecting hosting with second-jurisdiction failover.	Kubernetes is not adopted. The right answer to operational burden is fewer services, not more orchestration.
Secrets	SOPS with age. Identity-vault keys held separately from application secrets.	HashiCorp Vault when team size or rotation cadence demands it.

15. Pitchfork Foundry: Roadmap

The roadmap below begins after Clockwork Butterfly v1.0 has shipped and stabilized (CB Month 9+, see §7).

Phase	Milestones
Phase 0: Pre-Launch (Months -3 to -1)	Cooperative formed (foreign-domiciled where feasible). Legal Partners formed. Outside counsel engaged. Multi-platform popularization spine extended from CB content. Pre-launch member registrations on Open Collective. Self-hosted contribution backstop validated.
Month 0: Launch Round	Open Collective campaign opens. Tiered targets. Live transparency dashboard. Round closes at six weeks.
Months 1–2: Prove the Engine	Manual end-to-end test: one real (consented) claim hand-walked from intake through theory mapping to a single pilot firm. Re-identification testing protocol (§12.2) executed and packet template validated. No production code written until the engine is proven.
Months 3–4: Build Intake	Secure Intake live (built on CB). Reviewer Queue live. AI-drafted theory mapping for FCA vertical. Letter of Marque schema implemented and issued through CB.
Months 5–6: Open RFP Room	RFP Room live with 3–5 invited firms. First Letters of Marque issued. First RFP cycle. First matter routed to a sponsoring firm. Red-team exercise (including reviewer-compromise scenarios). Public MVP launch.
Months 7–12	Scale to 500+ claims. Onboard 10+ firms. Begin v2 design for second vertical. First sponsorship-revenue arrives. Open-source repository made public.

16. Success Metrics

16.1 Clockwork Butterfly

• Kickstarter round closed at minimum-viable target ($200K) or above.
• v1.0 shipped on time and on the funded scope.
• Independent third-party security audit passed (if Stretch 3 funded).
• At least three production verifier integrations live within six months of v1.0 release.
• At least 25,000 users who have issued a verifiable presentation against a production verifier within twelve months. Install counts, account creations, and downloads are tracked but are not the success metric; the metric is end-to-end use of the selective-disclosure engine in a real verification flow.
• Zero central-honeypot incidents. (There is no central honeypot. The metric is binary and the success state is structural.)

16.2 Pitchfork Foundry

• Launch round closed at minimum-viable target ($250K) or above.
• Engine proven (Months 1–2) before production code written.
• Re-identification testing passed before RFP Room opens.
• 100+ verified harm narratives processed by Month 6.
• 3–5 vetted firms in RFP marketplace.
• At least 1 matter routed to sponsoring firm.
• Zero identity-disclosure incidents. (Binary; one is failure.)
• 2,500+ recurring members on Open Collective by Month 6; 5,000+ by Month 12.

17. Open Questions for v1 Review

All items below resolve before Pre-Launch Month -1; any item still open at that gate is a launch-blocker. Three are explicitly load-bearing on the funding architecture and cannot slip: cooperative domicile, fiscal host selection for both the Kickstarter and Open Collective rounds, and the per-origination fee cap. The remainder are operationally consequential but not capital-structure-blocking.

9. Final domicile for Pitchfork Cooperative: Iceland, Estonia, Switzerland, Costa Rica candidates. Decision rests on cooperative-law support, banking access, and adversarial-state-resistance properties.
10. Staffing model for Pitchfork Legal Partners: minimum admitted-attorney count, supervisory ratios, multi-jurisdiction bar admissions for CA, NY, MA. Outside counsel review.
11. Open Collective fiscal-host selection. Open Collective Foundation, Open Source Collective, or non-US fiscal host.
12. Self-hosted contribution rail technical specification: BTCPay configuration, foreign merchant-of-record arrangements, ACH and check-by-mail capabilities.
13. Cap on per-origination fees, justified jurisdiction-by-jurisdiction.
14. Cooperative bylaws: membership concentration limits, recall procedures, vertical-prioritization voting, security non-negotiables that members cannot vote to remove.
15. Anti-SLAPP-aware state of formation for Pitchfork Legal Partners.
16. Clockwork Butterfly fiscal hosting for Kickstarter campaign. Kickstarter requires a fiscal entity; the Cooperative may not be the right one for Phase 1 specifically.
17. Clockwork Butterfly app store strategy: Apple, Google, F-Droid sequencing; side-loading documentation; expectations for mandate-based rejection.
18. Whether Clockwork Butterfly should formally participate in W3C standards-track work or remain a downstream implementation.

Appendix A: Glossary

• Clockwork Butterfly. The Phase 1 product: an open-source, user-controlled digital identity vault with selective disclosure.
• Pitchfork Foundry. The Phase 2 product: crowdfunded infrastructure for economic justice enforcement, built on Clockwork Butterfly.
• Letter of Marque. A non-transferable Verifiable Credential issued through Clockwork Butterfly, certifying participation: as a verified claimant, as a founder backer, or as a vertical backer.
• Selective Disclosure. The cryptographic technique by which a credential holder proves a property — over 18, citizen of X, harmed party in Y — without revealing the underlying credential or identity.
• Verifiable Credential. A W3C-standardized cryptographic document that a credential issuer signs and a credential holder presents.
• Decentralized Identifier (DID). A W3C-standardized identifier that does not require a central registry, allowing identity to be portable and user-controlled.
• Pitchfork Cooperative. Member-owned entity that holds Pitchfork Foundry IP and operates infrastructure.
• Pitchfork Legal Partners. Affiliated law firm that operates Pitchfork Foundry intake and provides the privilege-friction posture.
• Privilege Friction. The posture of structuring intake to make adversarial subpoenas expensive and slow, even where final privilege determinations are uncertain.
• Mandate-Creep. The ratchet by which identity-verification requirements expand from narrow contexts (banking, age-restricted services) to general internet use, producing surveillance infrastructure as a side effect of stated child-protection or fraud-prevention goals.