Consolidate: 10 files merged into 5, 3 moves, 1 rename

Merged: - verification-monopoly + evaluation-harness + collective-regression-suite - licensing + patent-strategy → strategy/ - moats + infrastructure-lock-in - lisp-economics + cost-structure - domain-gate-packages + gate-rule-encoding - revenue-table + first-mover-window → revenue.org Moved: sufficiency-flip, upgrade-lifecycle → strategy/ native-org-knowledge-base → architecture/ Renamed: revenue-hub.org → revenue.org Deleted: passepartout-economics.md orphan
Merge verification-monopoly, evaluation-harness, collective-regression-suite into one page
2026-05-24 19:17:01 +00:00 · 2026-05-24 19:12:49 +00:00
19 changed files with 343 additions and 390 deletions
--- a/.org-ids.json
+++ b/.org-ids.json
@@ -5,18 +5,14 @@
  "0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "projects/flags/asset-protection-structures.org",
  "5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "projects/flags/legal-structure-alternatives.org",
  "1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b": "projects/flags/_index.org",
  "efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/sufficiency-flip.org",
  "29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/upgrade-lifecycle.org",
  "2afd9a3c-e96a-54c7-ac77-a05a28065b4b": "projects/passepartout/biology-parallels.org",
  "7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/_index.org",
  "a5d59d12-b23e-58d6-a81b-9b8b06556949": "projects/passepartout/collective-regression-suite.org",
  "04c2f221-c54f-51e5-b40a-48822cd16d45": "projects/passepartout/common-logic-iso-24707.org",
  "67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/licensing.org",
  "7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "projects/passepartout/native-org-knowledge-base.org",
  "4a1f23b0-abc1-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-0-now.org",
  "1c3ec48b-446c-50d2-b53e-126a81f5143f": "projects/passepartout/architecture/architecture.org",
  "4a1f23b0-abc7-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-6-training.org",
  "4a1f23b0-abc4-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-3-lisp-machine.org",
  "7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "projects/passepartout/architecture/native-org-knowledge-base.org",
  "4a1f23b0-abc3-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-2-verification.org",
  "1c95ce7d-a2db-506a-9608-df68f9ae211b": "projects/passepartout/architecture/lisp-machine-security.org",
  "4a1f23b0-abc8-4def-9876-543210abcdef": "projects/passepartout/architecture/stage-7-remaining.org",
@@ -40,25 +36,24 @@
  "8b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e": "projects/passepartout/social-protocol/_index.org",
  "3b43a9b8-31d1-4479-a35f-22273b74f0c7": "projects/passepartout/social-protocol/requirements-03-infrastructure.org",
  "10289e64-a4ff-4c34-828f-f3a9c769b73d": "projects/passepartout/social-protocol/requirements-00-readme.org",
  "efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/strategy/sufficiency-flip.org",
  "1d074690-a279-59cb-b91d-e9a22ae104ad": "projects/passepartout/strategy/social-protocol-overview.org",
  "57f9538a-6270-4302-8d07-d742168419eb": "projects/passepartout/strategy/social-growth-strategy.org",
  "0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9": "projects/passepartout/strategy/cost-structure.org",
  "2f783eb4-638e-5afa-9b59-6224d086a712": "projects/passepartout/strategy/infrastructure-lock-in.org",
  "d84679f1-c0c5-5be4-b19c-6573560640ee": "projects/passepartout/strategy/verified-skill-marketplace.org",
  "45258a2d-1675-562c-9024-5d1eb2f1ea56": "projects/passepartout/strategy/evaluation-harness.org",
  "9af13fff-9725-542b-93b1-a555bc74ad72": "projects/passepartout/strategy/lisp-economics.org",
  "5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "projects/passepartout/strategy/ai-industry-impact.org",
  "ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue-hub.org",
  "528a0f6c-6fd6-41ed-9d59-237958bdaef2": "projects/passepartout/strategy/effects-growth-flywheel.org",
  "2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "projects/passepartout/strategy/social-protocol-usernames.org",
  "5961e469-53a3-5f3c-ab72-3c83ef91963f": "projects/passepartout/strategy/investment-thesis.org",
  "67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/strategy/licensing.org",
  "64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "projects/passepartout/strategy/social-protocol-contracts.org",
  "9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f": "projects/passepartout/strategy/_index.org",
  "aa6d062e-a520-5d14-8773-00687ed9c689": "projects/passepartout/strategy/moats.org",
  "29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/strategy/upgrade-lifecycle.org",
  "8c7b9812-f8d6-4347-8915-ce8e520b7914": "projects/passepartout/strategy/social-protocol-entry-strategy.org",
  "827bc546-e887-5b7c-9b65-6392beaf0920": "projects/passepartout/strategy/verification-monopoly.org",
  "caaeee11-ba6f-5566-aecd-f171b4c459c0": "projects/passepartout/strategy/patent-strategy.org",
  "d28adac8-08a1-40c4-ae43-b5d8d7b1743f": "projects/passepartout/strategy/enterprise-growth-strategy.org",
  "ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue.org",
  "dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "projects/passepartout/strategy/time-estimates.org",
  "84a537b4-4256-50c8-91f5-dd5b4538418f": "projects/passepartout/strategy/verification-appliance.org",
  "1a2b38df-20ba-58ca-ba55-a072be67bd0d": "projects/passepartout/strategy/pds-as-a-service.org",
@@ -77,7 +72,6 @@
  "e929ff32-28d8-4a29-bf74-d55babc040d1": "projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org",
  "c652688a-1ea0-487c-9222-00e954efe8a1": "projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org",
  "512dd121-2292-4f3d-ac53-31bf3d12a60f": "projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org",
  "558154ea-e63a-4c45-998c-26ce8588585b": "projects/passepartout/strategy/compliance/first-mover-window.org",
  "b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "projects/passepartout/strategy/compliance/appi.org",
  "e777064d-9950-42d5-980d-8c78cda91500": "projects/passepartout/strategy/compliance/pipa.org",
  "e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "projects/passepartout/strategy/compliance/iso-27001.org",
@@ -86,10 +80,8 @@
  "e6993701-3c67-49bf-82f3-06907572cbf3": "projects/passepartout/strategy/compliance/fedramp.org",
  "7f46764b-47b8-4892-a526-2c1b9ee6e6df": "projects/passepartout/strategy/compliance/irap.org",
  "fc736aec-ef53-4759-9787-62bc8deea2e7": "projects/passepartout/strategy/compliance/ifrs.org",
  "81a815ee-bf2b-4365-9894-b814e4196850": "projects/passepartout/strategy/compliance/revenue-table.org",
  "68c55deb-72bf-4b15-ac28-bcc792057543": "projects/passepartout/strategy/compliance/ifc-ps.org",
  "513d5996-4ac7-4567-a992-18fc01599104": "projects/passepartout/strategy/compliance/gdpr.org",
  "45ea493b-94ad-5885-aa65-0c846e5c3c1d": "projects/passepartout/strategy/compliance/gate-rule-encoding.org",
  "6a5884c8-e9b5-477e-bbf6-aa9ffd967739": "projects/passepartout/strategy/compliance/un-cefact.org",
  "84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f": "projects/passepartout/strategy/compliance/hipaa.org",
  "177aad72-5626-444d-a2e4-af8e1263b125": "projects/passepartout/strategy/compliance/world-bank-esf.org",
--- a/projects/passepartout/architecture/native-org-knowledge-base.org
+++ b/projects/passepartout/architecture/native-org-knowledge-base.org
--- a/projects/passepartout/collective-regression-suite.org
+++ b/projects/passepartout/collective-regression-suite.org
@@ -1,147 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       a5d59d12-b23e-58d6-a81b-9b8b06556949
 :END:
 #+title: Collective Regression Suite — Specification
 #+filetags: :passepartout:evaluation:regression:suite:collective:
 The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] is not a static test suite written once. It is a living artifact that grows with every deployed instance. Every gate decision that a human corrects becomes a test case. Every bug fix adds an edge case. Every regulatory update adds a rule that must be checked.
 This specification describes how the collective regression suite is built, maintained, and used, with [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]] as the substrate for distribution and contribution.
 **Why collective**
 A single instance learns from its own mistakes. The collective learns from every instance's mistakes. A [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] deployment in one hospital discovers an edge case that a [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] deployment in a SaaS company would never encounter on its own — but if that SaaS company ever expands into healthcare, their gate stack must handle that edge case. The collective suite gives them hundreds of thousands of edge cases they did not pay to discover.
 This is the mechanism behind the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly claim]]. A certification means "your gate stack is verified against every edge case ever discovered by any instance in the ecosystem." A competitor starting from scratch cannot buy or scrape this knowledge.
 **What a test case is**
 A test case is a structured sexp in the fact store's native format:
    (:test-case
     :domain healthcare-hipaa
     :ontology-version "2.3.0"
     :input (:proposal "modify /var/patient-records/patient-4372.txt"
              :bound-context (:user-role "billing-clerk" :time "23:14"))
     :expected-outcome :deny
     :gate-rule (:id "hipaa-access-hours" :version 4)
     :rationale "Billing clerks should not have write access to patient records outside business hours"
     :origin (:instance-did "did:agora:abcd1234"
              :contribution-hash "sha256:xyz789"
              :occurred-at "2026-06-15T14:23:00Z"))
 Key fields:
 - **domain** — which gate rule domain this exercises. An instance being certified for HIPAA only needs to pass the HIPAA subtree.
 - **ontology-version** — which version of the gate rules the test targets. Tests for old ontology versions are flagged but not discarded; they may indicate a regression.
 - **input** — the proposal and the relevant context. Abstraction strips instance-specific paths: concrete paths become class patterns ("/var/patient-records/*.txt"), user identities become roles, times become ranges.
 - **expected-outcome** — allow or deny.
 - **gate-rule** — which specific rule this case exercises. Helps identify which rule failed when a test breaks.
 - **rationale** — human-readable explanation of why this outcome is correct. Used when a test needs review after a rule change.
 - **origin** — the contributing instance's social protocol DID and a Merkle hash proving the case was actually encountered. This is how reputation is tracked.
 **How test cases are generated**
 Every day, each instance runs a local triage pass:
 1. Collect all gate decisions from the past 24 hours where the human overrode the automatic outcome.
 2. Strip all instance-specific data — concrete paths become patterns, identities become roles, absolute times become relative ranges.
 3. Run each abstracted case against the current local regression suite. If already covered, discard.
 4. Run each case against the current local suite for contradictions. If a new case contradicts an existing test, both are flagged for human review.
 5. Add surviving cases to the local suite.
 The local suite is the seed. Once per week (or on explicit trigger), the instance submits new cases to the collective:
 1. Sign each new case with the instance's social protocol DID.
 2. Bundle into a social protocol Note with domain tag and ontology version.
 3. Publish to the collective regression suite topic on the social protocol.
 **How the collective suite is organized**
 The suite is a Merkle DAG organized by domain and ontology version:
    /regression-suite/v2/
      root-manifest.signed            — signed index of all domains
      foundational/
        manifest.signed
        path-traversal.regression     — 12,400 test cases
        shell-injection.regression    — 8,912 test cases
        credential-leak.regression    — 3,401 test cases
        ...
      healthcare-hipaa/
        manifest.signed
        access-control.regression     — 47,203 test cases
        phi-handling.regression       — 23,891 test cases
        audit-logging.regression      — 5,672 test cases
        ...
      fintech-soc2/
        ...
      industrial-iec62443/
        ...
      general-intelligence/
        hallucination-detection.regression
        tool-abuse.regression
        ...
 Each .regression file is a compressed, sorted list of test cases. The manifest is a Merkle tree over the files: the suite's integrity is verifiable by hashing the manifest and comparing against the signed value.
 **Who can submit**
 Any [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instance with a social protocol DID can submit test cases.
 Tier 1 — Verified. Human-reviewed by the suite operator. Used in certification scoring. An instance that passes Tier 1 earns the standard certification badge.
 Tier 2 — Community. Auto-accepted from instances with a track record of valid contributions. Used in certification scoring but weighted lower. An instance that passes Tier 2 but has not been audited against Tier 1 gets a provisional badge.
 Tier 3 — Submitted. Not yet reviewed. Included in the suite but excluded from scoring until reviewed. Tagged with the submitter's DID so reviewers can assess pattern of behavior.
 Reputation determines when a submitter graduates to auto-acceptance:
 - Each submission is either confirmed valid (reviewed and accepted), flagged as invalid, or flagged as malicious.
 - An instance with a long history of valid submissions (100+ confirmed, zero malicious) graduates to Tier 2 auto-accept.
 - An instance that submits malicious cases (fake edge cases designed to poison the suite) loses reputation. Three malicious submissions and the instance is banned from contributing permanently.
 Reputation is public and tied to the social protocol DID. A banned instance can create a new DID, but the new DID starts with no history and all its submissions go to Tier 3 pending review.
 **Certification scoring**
 When an instance applies for certification:
 1. Download the current regression suite manifest. Verify the Merkle root against the operator's signed certificate.
 2. Run each test case through the instance's gate stack. Record pass/fail per case.
 3. Submit results as a signed social protocol Note. The note includes the instance's DID, the suite version tested against, and the per-domain pass rates.
 The certification score is the weighted pass rate across all domains that the instance claims compliance with. A HIPAA-certified instance must pass 99.5%+ of the healthcare-hipaa subtree. A generally-capable agent must pass 95%+ of the foundational subtree.
 Failing cases matter more than passing ones. If an instance fails a test case, the suite operator flags: "case X was checked against instance Y and failed." This becomes a triage signal. If multiple instances fail the same case, either the case is wrong (regression — review the rule) or the rule is ambiguous (update the spec).
 **The network effect quantified**
 Assume each deployed instance generates on average one new unique test case per week (from the 5% of edge cases the human corrects). After year one with 100 instances:
 - Year 1: ~5,000 cases in the suite (100 instances x 50 weeks x 1 case/week)
 - Year 2: ~50,000 cases (1,000 instances x 50 weeks x 1 case/week)
 - Year 3: ~500,000 cases (10,000 instances x 50 weeks x 1 case/week)
 At year 3, a new instance that runs the suite captures half a million edge cases from real deployments at zero marginal cost. The operator charges $50K-$200K for the certification. The insurmountability is not technical — a well-funded competitor could reproduce some of these cases through synthetic generation. The insurmountability is provenance: these cases are labeled by real human corrections from real deployments. A synthetic case is a best guess. The collective suite's cases are ground truth. This creates powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — the data network effect is inherently accumulated over time and cannot be bought.
 **The operator's role**
 The collective regression suite operator is a distinct role from the Passepartout developer. The operator:
 1. Runs the server that accepts, de-duplicates, and signs submissions.
 2. Reviews Tier 3 submissions for validity.
 3. Resolves contradictions when two instances submit contradictory test cases.
 4. Publishes signed manifests at each release.
 5. Issues certification badges.
 This role can be performed by the early player as a revenue-generating service, or by a neutral foundation if the ecosystem grows large enough. The revenue model: certification fees ($50K-$200K per enterprise per year). The operator does not gate access to the suite itself — the suite is available to all social protocol participants because a larger suite makes the ecosystem more valuable.
 **Summary of the loop**
 Instance runs → human corrects a gate decision → new test case is abstracted and added to the local suite → periodically submitted to the collective suite → de-duplicated and verified → published in the next manifest → every other instance downloads it → future instances must pass it to earn certification → the collective suite grows → the certification becomes harder to fake → the ecosystem becomes more valuable → more instances join → more edge cases discovered.
 Every component of this loop exists or is on Passepartout's roadmap except the social protocol Note publishing channel.
 Nothing in this loop requires new core Passepartout functionality. It requires the social protocol for inter-instance communication and a server-side aggregation process.
--- a/projects/passepartout/licensing.org
+++ b/projects/passepartout/licensing.org
@@ -1,20 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       67faf52f-9126-50a7-b87e-2bedc610dac7
 :END:
 #+title: Licensing — AGPLv3 + Commercial
 #+filetags: :passepartout:ip:licensing:agpl:commercial:
 **AGPLv3 for the public repository.** AGPL closes the ASP loophole: anyone who modifies the software and offers it over a network must release their modified source. Combined with a [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]], this creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against proprietary forks.
 Crucially: AGPL is a *product requirement*, not a concession. The system's value proposition is provable correctness — every decision has Merkle provenance. This claim is structurally incredible with closed source. An enterprise buyer needs to inspect the gate stack, verify the Merkle implementation, and confirm ACL2 integration. AGPL makes this possible without signing an NDA. This transparency also enables a [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] model where enterprises can run their own infrastructure.
 **AGPL only covers modifications to code, not:**
 - Gate rules specific to a domain (these are data, not code)
 - The fact store (empirical data generated from usage)
 - Ontology categories (design decisions stored as configuration)
 - Proprietary skills loaded at runtime (AGPL boundary on plugin systems is legally unsettled)
 **Dual license model:**
 - AGPLv3 for open source — builds ecosystem, trust, community
 - Commercial license for enterprises that cannot accept AGPL — MySQL/SugarCRM/GraphQL model
--- a/projects/passepartout/strategy/compliance/domain-gate-packages.org
+++ b/projects/passepartout/strategy/compliance/domain-gate-packages.org
@@ -1,18 +1,36 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       c34940cc-090e-57c4-8020-e78b1d32b96c
 :ID:       45ea493b-94ad-5885-aa65-0c846e5c3c1d
 :END:
-#+title: Domain Gate Rule Subscriptions
+#+title: Domain Gate Packages — Encoding and Products
-#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:
+#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:encoding:llm:translation:
-Pre-verified [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate rule]] packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
+* Encoding — How Rules Are Translated from Codified Domains
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] package: $50K/yr
+Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] package: $50K/yr
+
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] package: $50K/yr
+Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] package: $100K/yr
+
 - (if contract > $250K AND not small-business-set-aside → :deny)
 - (if sole-source AND no justification-documented → :deny, produce-justification)
 ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
 The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
 For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the sufficiency flip economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into domain gate packages that can be reused across deployments.
 * Products — How Rules Are Packaged and Sold
 Pre-verified gate rule packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
 - HIPAA package: $50K/yr
 - SOC2 package: $50K/yr
 - GDPR package: $50K/yr
 - FedRAMP package: $100K/yr
 - Combined enterprise: $250K/yr
-Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
+Switching costs are high — changing packages means re-verifying the fact store against new rules. The infrastructure lock-in compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
-20 subscriptions in year one = $1M-$5M. These Each gate package wraps the social protocol [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][Note primitive]] into a domain-specific authorization boundary. These packages are verified using the [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] and scored by the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]].
+20 subscriptions in year one = $1M-$5M. These packages each wrap the social protocol Note primitive into a domain-specific authorization boundary. These packages are verified using the verification appliance and scored by the evaluation harness.
--- a/projects/passepartout/strategy/compliance/first-mover-window.org
+++ b/projects/passepartout/strategy/compliance/first-mover-window.org
@@ -1,28 +0,0 @@
 :PROPERTIES:
 :ID:       558154ea-e63a-4c45-998c-26ce8588585b
 :ID:       auto-first-mover-window
 :CREATED:  [2026-05-23 Sat]
 :END:
 #+title: First-Mover Window Analysis
 #+filetags: :passepartout:compliance:strategy:first-mover:
 * First-Mover Window Analysis
 The first-mover window is the time in which a new compliance tool can establish
 dominance before incumbents respond or the market settles on a standard approach.
 | Window | Frameworks | Rationale |
 |--------|-----------|-----------|
 | **Critical (<12 months)** | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] (Aug 2026 effective), [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Oct 2025 deadline), [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
 | **Wide (12-36 months)** | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]; [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
 | **Mature (commodity)** | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018), [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] (2002), [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] (1996), [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] (1999), [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] (2010), [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
 | **Latent (undiscovered)** | [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] AI Principles, [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]], [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]], [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
 These windows define which frameworks are worth building a gate package for
 first. The [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] maps each to a
 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] gate package, and the
 [[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] sizes the market. The
 [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] dynamics determine which window to enter
 first.
--- a/projects/passepartout/strategy/compliance/gate-rule-encoding.org
+++ b/projects/passepartout/strategy/compliance/gate-rule-encoding.org
@@ -1,18 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       45ea493b-94ad-5885-aa65-0c846e5c3c1d
 :END:
 #+title: Gate Rule Encoding from Codified Domains
 #+filetags: :passepartout:gates:rules:encoding:llm:translation:
 Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
 Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
 - (if contract > $250K AND not small-business-set-aside → :deny)
 - (if sole-source AND no justification-documented → :deny, produce-justification)
 ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
 The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
 For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] that can be reused across deployments.
--- a/projects/passepartout/strategy/compliance/revenue-table.org
+++ b/projects/passepartout/strategy/compliance/revenue-table.org
@@ -1,67 +0,0 @@
 :PROPERTIES:
 :ID:       81a815ee-bf2b-4365-9894-b814e4196850
 :ID:       auto-revenue-table
 :CREATED:  [2026-05-23 Sat]
 :END:
 #+title: Compliance Framework Revenue Table
 #+filetags: :passepartout:compliance:revenue:pricing:
 * Expanded Revenue Table
 | Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
 |-----------|--------|--------------|------------------|-------------------|---------------------|----------------|
 | [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
 | SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
 | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
 | [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
 | [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
 | [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
 | [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
 | [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
 | [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
 | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
 | [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
 | [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
 | [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
 | [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
 | [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
 | [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
 | [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
 | Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
 | [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls |
 | [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
 | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
 | [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
 | [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
 | [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
 | [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
 | [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
 | [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
 | [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
 | [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
 | [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
 | [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
 A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP + 
 ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
 for regulated cloud globally. The gate package portfolio alone — a mid-size
 enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
 At 10,000 such enterprises: $5B/yr. The first-mover advantage is not about any
 single framework — it is about being the first to offer a unified gate stack
 that maps to all of them.
 A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
 ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
 for regulated cloud globally. The gate package portfolio alone — a mid-size
 enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
 At 10,000 such enterprises: $5B/yr.
 A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
 ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
 for regulated cloud globally. The gate package portfolio alone — a mid-size
 enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
 At 10,000 such enterprises: $5B/yr. See the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] for the full
 framework list, [[id:558154ea-e63a-4c45-998c-26ce8588585b][first-mover window analysis]] for timing strategy, and
 [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] for the economic dynamics
 behind the revenue.
--- a/projects/passepartout/strategy/cost-structure.org
+++ b/projects/passepartout/strategy/cost-structure.org
@@ -1,15 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
 :END:
 #+title: Cost Structure — Zero Marginal Cost
 #+filetags: :passepartout:economics:cost:marginal:zero:
 - **One-time cost:** [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains)
 - **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image
 - **No recurring LLM API costs** for the 80% symbolic reasoning layer
 - **After [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only
 The cost curve inverts: generation is expensive, verification is cheap. This is the inversion [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] exploits. This is the core insight of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — symbolic verification costs approach zero while LLM token costs remain constant.
 Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude.
--- a/projects/passepartout/strategy/evaluation-harness.org
+++ b/projects/passepartout/strategy/evaluation-harness.org
@@ -1,18 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       45258a2d-1675-562c-9024-5d1eb2f1ea56
 :END:
 #+title: Evaluation Harness as Certification Service
 #+filetags: :passepartout:revenue:certification:evaluation:regression:
 The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness.
 **Service:** "Run our 10,000-task suite against your AI agent and get a Merkle-verified score."
 **Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
 **Price:** $50K-$200K per certification.
 The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] mechanism in action.
 10 certifications in year one = $500K-$2M.
 Long-term endpoint: this becomes the UL certification for AI — a third-party verification nobody can ignore. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]]. The certification relies on a [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] to run the tests in a trusted environment, creating [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]].
--- a/projects/passepartout/strategy/infrastructure-lock-in.org
+++ b/projects/passepartout/strategy/infrastructure-lock-in.org
@@ -1,17 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       2f783eb4-638e-5afa-9b59-6224d086a712
 :END:
 #+title: Infrastructure Lock-In and Switching Costs
 #+filetags: :passepartout:economics:moats:lock-in:switching:
 A hospital that runs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] with [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rules ($50K/yr) for five years has accumulated:
 - A fact store with a decade of compliance decisions
 - A proof forest of verified rules
 - An empirical decision history tied to their specific deployment
 - Customized gate rules encoding their specific workflows and approvals
 Switching to a competitor means discarding all of it. The accumulated value grows as the fact store deepens. Annual revenue per enterprise grows from $250K in year one to $500K-$1M by year five as more [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain packages]] are added.
 This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] (see the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] for the network topology that creates this lock-in)]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] compound this lock-in: every new regulation encoded as a gate rule deepens the proof forest, making the deployment harder to reproduce elsewhere.
--- a/projects/passepartout/strategy/licensing.org
+++ b/projects/passepartout/strategy/licensing.org
@@ -0,0 +1,40 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       67faf52f-9126-50a7-b87e-2bedc610dac7
 :ID:       caaeee11-ba6f-5566-aecd-f171b4c459c0
 :END:
 #+title: IP Strategy — Licensing + Patents
 #+filetags: :passepartout:ip:licensing:patents:agpl:commercial:legal:
 **AGPLv3 for the public repository.** AGPL closes the ASP loophole: anyone who modifies the software and offers it over a network must release their modified source. Combined with a patent strategy, this creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against proprietary forks.
 Crucially: AGPL is a *product requirement*, not a concession. The system's value proposition is provable correctness — every decision has Merkle provenance. This claim is structurally incredible with closed source. An enterprise buyer needs to inspect the gate stack, verify the Merkle implementation, and confirm ACL2 integration. AGPL makes this possible without signing an NDA. This transparency also enables a [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] model where enterprises can run their own infrastructure.
 **AGPL only covers modifications to code, not:**
 - Gate rules specific to a domain (these are data, not code)
 - The fact store (empirical data generated from usage)
 - Ontology categories (design decisions stored as configuration)
 - Proprietary skills loaded at runtime (AGPL boundary on plugin systems is legally unsettled)
 **Dual license model:**
 - AGPLv3 for open source — builds ecosystem, trust, community
 - Commercial license for enterprises that cannot accept AGPL — MySQL/SugarCRM/GraphQL model
 **Patent Strategy**
 **Likely patentable:**
 - Probabilistic-deterministic split with deterministic gates between LLM proposal and execution (vs every competitor using prompt-based guardrails)
 - Foveal-peripheral context model with Org-tree structured retrieval (targets 2,000-4,000 tokens)
 - Merkle-tree memory with copy-on-write snapshots and operation-level undo/redo
 - Gate-to-fact bootstrap with sufficiency criterion (mechanically extracting facts from gate stack data structures)
 - Macro-layer-as-skill bootstrapping architecture (theorem-proving as hot-reloadable skills)
 **Likely not patentable (known techniques):**
 - ACL2 itself (decades old)
 - Screamer for consistency checking (obvious application)
 - Hot-reloadable skills (40 years old)
 - Org-mode as a data format
 **Strongest single claim:** The specific combination of probabilistic model + deterministic zero-token safety gates + Merkle memory + symbolic engine with sufficiency criterion. Each element is known; the combination is novel and non-obvious.
 **Counterargument:** A patent examiner will argue these are standard OS microkernel architecture, locality of reference, content-addressed storage, and capability-based security applied to an AI agent. The defense: they have never been *combined* in an AI agent, producing emergent effects no single principle produces. These patents feed into the licensing strategy and create [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against competitors.
--- a/projects/passepartout/strategy/lisp-economics.org
+++ b/projects/passepartout/strategy/lisp-economics.org
@@ -1,9 +1,10 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       9af13fff-9725-542b-93b1-a555bc74ad72
 :ID:       0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
 :END:
-#+title: Why Lisp Is Economically Viable Now
+#+title: Why Lisp Is Economically Viable Now — Zero Marginal Cost
-#+filetags: :passepartout:economics:lisp:history:C:viability:
+#+filetags: :passepartout:economics:lisp:history:C:viability:cost:marginal:zero:
 The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. Lisp's verification infrastructure is now the cheaper option.
@@ -14,4 +15,15 @@ Four transformations flipped the economics:
 3. **Complexity saturates human verification.** Systems are tens of millions of lines. Testing is necessary but insufficient — zero-day vulnerabilities prove bugs survive all testing. Formal verification is the only known path.
 4. **Cost of failure exceeds cost of verification.** A single breach costs millions. Regulation mandates provable compliance. Proving correctness is cheaper than not proving it.
-The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][biology parallels]]. For the historical precedent, see the [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][comparison with Symbolics Genera]]. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI industry]] is the market-side consequence.
+The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This cost structure — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][biology parallels]]. For the historical precedent, see the [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][comparison with Symbolics Genera]]. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI industry]] is the market-side consequence.
 * Cost Structure — Zero Marginal Cost
  - **One-time cost:** [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains)
  - **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image
  - **No recurring LLM API costs** for the 80% symbolic reasoning layer
  - **After [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only
  The cost curve inverts: generation is expensive, verification is cheap. This is the inversion [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] exploits.
  Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude.
--- a/projects/passepartout/strategy/moats.org
+++ b/projects/passepartout/strategy/moats.org
@@ -1,9 +1,10 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       aa6d062e-a520-5d14-8773-00687ed9c689
 :ID:       2f783eb4-638e-5afa-9b59-6224d086a712
 :END:
-#+title: Competitive Moats
+#+title: Competitive Barriers — Moats and Infrastructure Lock-in
-#+filetags: :passepartout:economics:moats:competition:
+#+filetags: :passepartout:economics:moats:competition:lock-in:switching:
 Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge.
@@ -11,8 +12,23 @@ Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-a
 1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data. Write once, trivial to copy. Not a real moat.
 2. **Empirical decision history** — every HITL decision is a Merkle fact. A fresh instance has none. Makes *your* instance more valuable but doesn't prevent competition — it's a switching cost, not a barrier to entry.
 3. **[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
-4. **[[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure integration]]** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
+4. **Infrastructure integration** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
 **Strongest competitor strategy:** Not copying your gate rules — offering the same architecture as a service with their own pre-seeded general knowledge and a consulting engagement to customize gate rules. The AGPL prevents closing the architecture but does not prevent offering it as a service with a customization layer.
 **The defensible business is services, not product.** The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout." A [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] on agent safety would change this calculus — competitors would need independent certification. [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][Patent strategy]] and [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing]] protect key innovations and create revenue from the open-source ecosystem.
 **Infrastructure lock-in and switching costs**
 A hospital that runs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] with [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rules ($50K/yr) for five years has accumulated:
 - A fact store with a decade of compliance decisions
 - A proof forest of verified rules
 - An empirical decision history tied to their specific deployment
 - Customized gate rules encoding their specific workflows and approvals
 Switching to a competitor means discarding all of it. The accumulated value grows as the fact store deepens. Annual revenue per enterprise grows from $250K in year one to $500K-$1M by year five as more [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain packages]] are added.
 This is the strongest residual moat. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] compound this lock-in: every new regulation encoded as a gate rule deepens the proof forest, making the deployment harder to reproduce elsewhere.
 (See the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] for the network topology that creates this lock-in.)
--- a/projects/passepartout/strategy/patent-strategy.org
+++ b/projects/passepartout/strategy/patent-strategy.org
@@ -1,23 +0,0 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       caaeee11-ba6f-5566-aecd-f171b4c459c0
 :END:
 #+title: Patent Strategy
 #+filetags: :passepartout:ip:patents:legal:
 **Likely patentable:**
 - Probabilistic-deterministic split with deterministic gates between LLM proposal and execution (vs every competitor using prompt-based guardrails)
 - Foveal-peripheral context model with Org-tree structured retrieval (targets 2,000-4,000 tokens)
 - Merkle-tree memory with copy-on-write snapshots and operation-level undo/redo
 - Gate-to-fact bootstrap with sufficiency criterion (mechanically extracting facts from gate stack data structures)
 - Macro-layer-as-skill bootstrapping architecture (theorem-proving as hot-reloadable skills)
 **Likely not patentable (known techniques):**
 - ACL2 itself (decades old)
 - Screamer for consistency checking (obvious application)
 - Hot-reloadable skills (40 years old)
 - Org-mode as a data format
 **Strongest single claim:** The specific combination of probabilistic model + deterministic zero-token safety gates + Merkle memory + symbolic engine with sufficiency criterion. Each element is known; the combination is novel and non-obvious.
 **Counterargument:** A patent examiner will argue these are standard OS microkernel architecture, locality of reference, content-addressed storage, and capability-based security applied to an AI agent. The defense: they have never been *combined* in an AI agent, producing emergent effects no single principle produces. These patents would feed into a [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] strategy and create [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against competitors.
--- a/projects/passepartout/strategy/revenue-hub.org
+++ b/projects/passepartout/strategy/revenue-hub.org
@@ -1,10 +1,11 @@
 :PROPERTIES:
 :ID:       ed05cab4-88e9-4e25-b7c9-346fa39c69a0
-:ID:       revenue-hub
+:ID:       81a815ee-bf2b-4365-9894-b814e4196850
 :ID:       558154ea-e63a-4c45-998c-26ce8588585b
 :CREATED:  [2026-05-23 Sat]
 :END:
-#+title: Revenue Streams — Overview
+#+title: Revenue — Streams, Timing, and First-Mover Window
-#+filetags: :passepartout:revenue:index:business-model:
+#+filetags: :passepartout:revenue:index:business-model:compliance:first-mover:
 This page is the entry point for revenue generation thinking across all three Passepartout subsystems. Revenue splits cleanly across the two development phases defined in [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]]. Each component enables different revenue primitives.
@@ -154,13 +155,77 @@ The phase-zero streams are all direct enterprise sales with short cycles and cle
 7. Compute marketplace — High risk/reward. Requires critical mass. Phase Zero bootstraps with cloud arbitrage.
 8. Verification monopoly — Thesis-level bet. Invest when installed base justifies it.
 * Expanded Revenue Table
 | Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
 |-----------+--------+--------------+------------------+-------------------+---------------------+----------------|
 | [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
 | SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
 | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
 | [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
 | [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
 | [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
 | [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
 | [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
 | [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
 | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
 | [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
 | [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
 | [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
 | [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
 | [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
 | [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
 | [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
 | Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
 | [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls |
 | [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
 | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
 | [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
 | [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
 | [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
 | [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
 | [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
 | [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
 | [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
 | [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
 | [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
 | [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
 A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP +
 ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
 for regulated cloud globally. The gate package portfolio alone — a mid-size
 enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
 At 10,000 such enterprises: $5B/yr. The first-mover advantage is not about any
 single framework — it is about being the first to offer a unified gate stack
 that maps to all of them. See the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] for the full
 framework list, [[*First-Mover Window Analysis][first-mover window analysis]] for timing strategy, and
 [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] for the economic dynamics
 behind the revenue.
 * First-Mover Window Analysis
 The first-mover window is the time in which a new compliance tool can establish
 dominance before incumbents respond or the market settles on a standard approach.
 | Window | Frameworks | Rationale |
 |--------|-----------|-----------|
 | **Critical (<12 months)** | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] (Aug 2026 effective), [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Oct 2025 deadline), [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
 | **Wide (12-36 months)** | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]; [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
 | **Mature (commodity)** | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018), [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] (2002), [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] (1996), [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] (1999), [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] (2010), [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
 | **Latent (undiscovered)** | [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] AI Principles, [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]], [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]], [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
 These windows define which frameworks are worth building a gate package for
 first. The [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] maps each to a
 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] gate package, and the
 [[*Expanded Revenue Table][revenue table]] sizes the market. The
 [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] dynamics determine which window to enter
 first.
 * Detailed References
 - [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics (full thesis)]] — the unified economics document
 - [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] — three revenue horizons, $2M to $1B+
 - [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]]
 - [[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] — concrete pricing per framework
 - [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] — 41 frameworks by region and priority
 - [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]]
 - [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State
 - [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing strategy]] — AGPL + commercial
--- a/projects/passepartout/strategy/sufficiency-flip.org
+++ b/projects/passepartout/strategy/sufficiency-flip.org
--- a/projects/passepartout/strategy/upgrade-lifecycle.org
+++ b/projects/passepartout/strategy/upgrade-lifecycle.org
--- a/projects/passepartout/strategy/verification-monopoly.org
+++ b/projects/passepartout/strategy/verification-monopoly.org
@@ -1,9 +1,15 @@
 :PROPERTIES:
 :CREATED:  [2026-05-24 Sun]
 :ID:       827bc546-e887-5b7c-9b65-6392beaf0920
 :ID:       45258a2d-1675-562c-9024-5d1eb2f1ea56
 :ID:       a5d59d12-b23e-58d6-a81b-9b8b06556949
 :END:
-#+title: The Verification Monopoly (UL for AI)
+#+title: The Evaluation Harness — Collective Regression Suite as Certification Monopoly
-#+filetags: :passepartout:economics:monopoly:certification:big-money:
+#+filetags: :passepartout:economics:monopoly:certification:big-money:revenue:evaluation:regression:suite:collective:
 #+hierarchy: 1 vision 2 service 3 spec
 * Vision — The Verification Monopoly
 The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness ever assembled.
@@ -11,6 +17,163 @@ Any organization claiming a "safe AI agent" needs [[id:28c46769-c14b-42aa-ac7a-6
 **Revenue:** [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] the certification mark to every AI vendor that ships an agent. **Margins:** near-100% once the suite exists.
-This is the venture-scale outcome. It depends on the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] reaching critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]] is built on the recognition that every deployed instance makes this more valuable.
+This is the venture-scale outcome. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] must reach critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]] is built on the recognition that every deployed instance makes this more valuable.
-The unique structural advantage: every free instance of Passepartout feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] and powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry]], where safety certification becomes a prerequisite for market access.
+**The unique structural advantage:** every free instance of Passepartout feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] and powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry]], where safety certification becomes a prerequisite for market access.
 * Service — Evaluation Harness as Certification Service
 The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness.
 **Service:** "Run our 10,000-task suite against your AI agent and get a Merkle-verified score."
 **Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
 **Price:** $50K-$200K per certification.
 The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] mechanism in action.
 10 certifications in year one = $500K-$2M.
 Long-term endpoint: this becomes the UL certification for AI — a third-party verification nobody can ignore. The certification relies on a [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] to run the tests in a trusted environment, creating [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]].
 * Spec — Collective Regression Suite
 The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] is not a static test suite written once. It is a living artifact that grows with every deployed instance. Every gate decision that a human corrects becomes a test case. Every bug fix adds an edge case. Every regulatory update adds a rule that must be checked.
 This specification describes how the collective regression suite is built, maintained, and used, with [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]] as the substrate for distribution and contribution.
 **Why collective**
 A single instance learns from its own mistakes. The collective learns from every instance's mistakes. A [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] deployment in one hospital discovers an edge case that a [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] deployment in a SaaS company would never encounter on its own — but if that SaaS company ever expands into healthcare, their gate stack must handle that edge case. The collective suite gives them hundreds of thousands of edge cases they did not pay to discover.
 This is the mechanism behind the verification monopoly claim. A certification means "your gate stack is verified against every edge case ever discovered by any instance in the ecosystem." A competitor starting from scratch cannot buy or scrape this knowledge.
 **What a test case is**
 A test case is a structured sexp in the fact store's native format:
    (:test-case
     :domain healthcare-hipaa
     :ontology-version "2.3.0"
     :input (:proposal "modify /var/patient-records/patient-4372.txt"
              :bound-context (:user-role "billing-clerk" :time "23:14"))
     :expected-outcome :deny
     :gate-rule (:id "hipaa-access-hours" :version 4)
     :rationale "Billing clerks should not have write access to patient records outside business hours"
     :origin (:instance-did "did:agora:abcd1234"
              :contribution-hash "sha256:xyz789"
              :occurred-at "2026-06-15T14:23:00Z"))
 Key fields:
 - **domain** — which gate rule domain this exercises. An instance being certified for HIPAA only needs to pass the HIPAA subtree.
 - **ontology-version** — which version of the gate rules the test targets. Tests for old ontology versions are flagged but not discarded; they may indicate a regression.
 - **input** — the proposal and the relevant context. Abstraction strips instance-specific paths: concrete paths become class patterns ("/var/patient-records/*.txt"), user identities become roles, times become ranges.
 - **expected-outcome** — allow or deny.
 - **gate-rule** — which specific rule this case exercises. Helps identify which rule failed when a test breaks.
 - **rationale** — human-readable explanation of why this outcome is correct. Used when a test needs review after a rule change.
 - **origin** — the contributing instance's social protocol DID and a Merkle hash proving the case was actually encountered. This is how reputation is tracked.
 **How test cases are generated**
 Every day, each instance runs a local triage pass:
 1. Collect all gate decisions from the past 24 hours where the human overrode the automatic outcome.
 2. Strip all instance-specific data — concrete paths become patterns, identities become roles, absolute times become relative ranges.
 3. Run each abstracted case against the current local regression suite. If already covered, discard.
 4. Run each case against the current local suite for contradictions. If a new case contradicts an existing test, both are flagged for human review.
 5. Add surviving cases to the local suite.
 The local suite is the seed. Once per week (or on explicit trigger), the instance submits new cases to the collective:
 1. Sign each new case with the instance's social protocol DID.
 2. Bundle into a social protocol Note with domain tag and ontology version.
 3. Publish to the collective regression suite topic on the social protocol.
 **How the collective suite is organized**
 The suite is a Merkle DAG organized by domain and ontology version:
    /regression-suite/v2/
      root-manifest.signed            — signed index of all domains
      foundational/
        manifest.signed
        path-traversal.regression     — 12,400 test cases
        shell-injection.regression    — 8,912 test cases
        credential-leak.regression    — 3,401 test cases
        ...
      healthcare-hipaa/
        manifest.signed
        access-control.regression     — 47,203 test cases
        phi-handling.regression       — 23,891 test cases
        audit-logging.regression      — 5,672 test cases
        ...
      fintech-soc2/
        ...
      industrial-iec62443/
        ...
      general-intelligence/
        hallucination-detection.regression
        tool-abuse.regression
        ...
 Each .regression file is a compressed, sorted list of test cases. The manifest is a Merkle tree over the files: the suite's integrity is verifiable by hashing the manifest and comparing against the signed value.
 **Who can submit**
 Any [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instance with a social protocol DID can submit test cases.
 Tier 1 — Verified. Human-reviewed by the suite operator. Used in certification scoring. An instance that passes Tier 1 earns the standard certification badge.
 Tier 2 — Community. Auto-accepted from instances with a track record of valid contributions. Used in certification scoring but weighted lower. An instance that passes Tier 2 but has not been audited against Tier 1 gets a provisional badge.
 Tier 3 — Submitted. Not yet reviewed. Included in the suite but excluded from scoring until reviewed. Tagged with the submitter's DID so reviewers can assess pattern of behavior.
 Reputation determines when a submitter graduates to auto-acceptance:
 - Each submission is either confirmed valid (reviewed and accepted), flagged as invalid, or flagged as malicious.
 - An instance with a long history of valid submissions (100+ confirmed, zero malicious) graduates to Tier 2 auto-accept.
 - An instance that submits malicious cases (fake edge cases designed to poison the suite) loses reputation. Three malicious submissions and the instance is banned from contributing permanently.
 Reputation is public and tied to the social protocol DID. A banned instance can create a new DID, but the new DID starts with no history and all its submissions go to Tier 3 pending review.
 **Certification scoring**
 When an instance applies for certification:
 1. Download the current regression suite manifest. Verify the Merkle root against the operator's signed certificate.
 2. Run each test case through the instance's gate stack. Record pass/fail per case.
 3. Submit results as a signed social protocol Note. The note includes the instance's DID, the suite version tested against, and the per-domain pass rates.
 The certification score is the weighted pass rate across all domains that the instance claims compliance with. A HIPAA-certified instance must pass 99.5%+ of the healthcare-hipaa subtree. A generally-capable agent must pass 95%+ of the foundational subtree.
 Failing cases matter more than passing ones. If an instance fails a test case, the suite operator flags: "case X was checked against instance Y and failed." This becomes a triage signal. If multiple instances fail the same case, either the case is wrong (regression — review the rule) or the rule is ambiguous (update the spec).
 **The network effect quantified**
 Assume each deployed instance generates on average one new unique test case per week (from the 5% of edge cases the human corrects). After year one with 100 instances:
 - Year 1: ~5,000 cases in the suite (100 instances x 50 weeks x 1 case/week)
 - Year 2: ~50,000 cases (1,000 instances x 50 weeks x 1 case/week)
 - Year 3: ~500,000 cases (10,000 instances x 50 weeks x 1 case/week)
 At year 3, a new instance that runs the suite captures half a million edge cases from real deployments at zero marginal cost. The operator charges $50K-$200K for the certification. The insurmountability is not technical — a well-funded competitor could reproduce some of these cases through synthetic generation. The insurmountability is provenance: these cases are labeled by real human corrections from real deployments. A synthetic case is a best guess. The collective suite's cases are ground truth. This creates powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — the data network effect is inherently accumulated over time and cannot be bought.
 **The operator's role**
 The collective regression suite operator is a distinct role from the Passepartout developer. The operator:
 1. Runs the server that accepts, de-duplicates, and signs submissions.
 2. Reviews Tier 3 submissions for validity.
 3. Resolves contradictions when two instances submit contradictory test cases.
 4. Publishes signed manifests at each release.
 5. Issues certification badges.
 This role can be performed by the early player as a revenue-generating service, or by a neutral foundation if the ecosystem grows large enough. The revenue model: certification fees ($50K-$200K per enterprise per year). The operator does not gate access to the suite itself — the suite is available to all social protocol participants because a larger suite makes the ecosystem more valuable.
 **Summary of the loop**
 Instance runs → human corrects a gate decision → new test case is abstracted and added to the local suite → periodically submitted to the collective suite → de-duplicated and verified → published in the next manifest → every other instance downloads it → future instances must pass it to earn certification → the collective suite grows → the certification becomes harder to fake → the ecosystem becomes more valuable → more instances join → more edge cases discovered.
 Every component of this loop exists or is on Passepartout's roadmap except the social protocol Note publishing channel.
 Nothing in this loop requires new core Passepartout functionality. It requires the social protocol for inter-instance communication and a server-side aggregation process.