From cc3976fb7f792cae1423e37b6067c57efa23f288 Mon Sep 17 00:00:00 2001 From: Hermes Date: Sun, 24 May 2026 16:25:55 +0000 Subject: [PATCH] =?UTF-8?q?ideas:=20editorial=20sweep=20=E2=80=94=20atomiz?= =?UTF-8?q?ation,=20interlinking,=20restructuring?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Split competitive-analysis-2026-05.org → TOC + 9 competitor files in ideas/competitors/. Dropped date from filename. All competitor UUIDs generated, TOC keeps original UUID for backlink continuity. - Deleted passepartout-economics.org archive (replaced by 27-node KB). - Inlined 5 'See also' blocks into natural prose (compliance-index, first-mover-window, revenue-table, orders-of-magnitude-time, native-org-knowledge-base). - Linked 7 orphan compliance pages back to compliance index + finished truncated sentences. - Linked all 14 Agora requirement docs from topic-relevant pages (identity→lisp-machine-security, infrastructure→compute-marketplace, social-space→growth-strategy, exchange→agora-contracts, etc.). - Linked ai-industry-impact from investment-thesis, sufficiency-flip, verification-appliance, effects-growth-flywheel (up from 1 to 10+ pages). - Fixed CREATED timestamps to use git commit dates instead of today. - Made all links absolute from root (no port inheritance). - Removed stale agora/docs/ duplicate content. --- .org-ids.json | 119 ++ _index.org | 25 + agora/docs/agora-requirements-00-readme.org | 37 - ideas/_index.org | 9 + ideas/agora-contracts.org | 31 +- ideas/agora-entry-strategy.org | 7 +- ideas/agora-usernames.org | 3 +- ideas/agora.org | 15 +- ideas/agora/agora-requirements-00-readme.org | 41 + .../agora}/agora-requirements-01-overview.org | 18 +- .../agora}/agora-requirements-02-identity.org | 10 +- .../agora-requirements-03-infrastructure.org | 19 +- .../agora-requirements-04-the-primitive.org | 16 +- .../agora}/agora-requirements-05-social.org | 14 +- ...requirements-06-exchange-and-contracts.org | 18 +- ...a-requirements-07-advanced-integration.org | 10 +- .../agora}/agora-requirements-08-library.org | 6 +- .../agora-requirements-09-implementation.org | 10 +- ...-requirements-10-governance-and-assets.org | 6 +- .../agora-requirements-10-user-journey.org | 12 +- .../agora-requirements-11-assessment.org | 16 +- ideas/ai-industry-impact.org | 5 +- ideas/alternative-growth-social-first.org | 25 +- ideas/asset-protection-structures.org | 23 +- ideas/biology-parallels.org | 3 +- ideas/collective-regression-suite.org | 15 +- ideas/common-logic-iso-24707.org | 9 +- ideas/comparison-with-symbolics.org | 5 +- ideas/competitive-analysis-2026-05.org | 463 ----- ideas/competitive-analysis.org | 128 ++ ideas/competitive-landscape-agora.org | 9 +- ideas/competitors/aider.org | 22 + ideas/competitors/claude-code.org | 22 + ideas/competitors/codex-cli.org | 22 + ideas/competitors/continue.org | 22 + ideas/competitors/gemini-cli.org | 22 + ideas/competitors/hermes-agent.org | 22 + ideas/competitors/openclaw.org | 22 + ideas/competitors/opencode.org | 22 + ideas/competitors/thoth.org | 22 + ideas/compliance-framework-mapping.org | 77 +- ideas/compliance/_index.org | 7 + ideas/compliance/appi.org | 5 +- ideas/compliance/apra-cps-234.org | 3 +- ideas/compliance/basel-iii.org | 5 +- ideas/compliance/ccpa-cpra.org | 3 +- ideas/compliance/compliance-index.org | 79 +- ideas/compliance/cra.org | 5 +- ideas/compliance/dora.org | 3 +- ideas/compliance/dpdp-act.org | 2 + ideas/compliance/eidas2.org | 5 +- ideas/compliance/eu-ai-act.org | 9 +- ideas/compliance/fatf.org | 5 +- ideas/compliance/fedramp.org | 7 +- ideas/compliance/first-mover-window.org | 17 +- ideas/compliance/gdpr.org | 7 +- ideas/compliance/glba.org | 3 +- ideas/compliance/hipaa.org | 5 +- ideas/compliance/ifc-ps.org | 3 +- ideas/compliance/ifrs.org | 5 +- ideas/compliance/irap.org | 5 +- ideas/compliance/ismap.org | 7 +- ideas/compliance/iso-27001.org | 3 +- ideas/compliance/iso-27701.org | 7 +- ideas/compliance/lfp-dppp.org | 3 +- ideas/compliance/lgpd.org | 3 +- ideas/compliance/nis2.org | 3 +- ideas/compliance/ny-dfs-500.org | 2 + ideas/compliance/oecd.org | 3 +- ideas/compliance/pipa.org | 3 +- ideas/compliance/privacy-act-aus.org | 3 +- ideas/compliance/quebec-law-25.org | 3 +- ideas/compliance/revenue-table.org | 71 +- ideas/compliance/soc2.org | 7 +- ideas/compliance/sox.org | 3 +- ideas/compliance/uk-gdpr.org | 7 +- ideas/compliance/un-cefact.org | 3 +- ideas/compliance/world-bank-esf.org | 3 +- ideas/compute-marketplace.org | 11 +- ideas/cost-structure.org | 7 +- ideas/domain-gate-packages.org | 15 +- ideas/effects-growth-flywheel.org | 27 +- ideas/evaluation-harness.org | 5 +- ideas/gate-rule-encoding.org | 3 +- ideas/growth-strategy.org | 33 +- ideas/infrastructure-lock-in.org | 7 +- ideas/investment-thesis.org | 15 +- ideas/legal-structure-alternatives.org | 11 +- ideas/legal-structure-practical-setup.org | 13 +- ideas/licensing.org | 5 +- ideas/lisp-economics.org | 3 +- ideas/lisp-machine-security.org | 15 +- ideas/moats.org | 9 +- ideas/native-org-knowledge-base.org | 10 +- ideas/orders-of-magnitude-time.org | 5 +- ideas/outbound-sales-compliance.org | 11 +- ideas/passepartout-economics.org | 1667 ----------------- ideas/patent-strategy.org | 3 +- ideas/pds-as-a-service.org | 5 +- ideas/revenue-hub.org | 39 +- ideas/self-driving-lisp-machine.org | 9 +- ideas/{stoa.org => stoa-overview.org} | 6 +- ideas/stoa/_index.org | 28 + ideas/stoa/stoa-stage-0-now.org | 84 + ideas/stoa/stoa-stage-1-agora.org | 85 + ideas/stoa/stoa-stage-2-logos.org | 84 + ideas/stoa/stoa-stage-3-stoa.org | 134 ++ ideas/stoa/stoa-stage-4-inference.org | 95 + ideas/stoa/stoa-stage-5-weights.org | 88 + ideas/stoa/stoa-stage-6-training.org | 124 ++ ideas/stoa/stoa-stage-7-remaining.org | 171 ++ ideas/stoa/stoa-vision-roadmap.org | 44 + ideas/sufficiency-flip.org | 5 +- ideas/time-estimates.org | 16 +- ideas/triad-index.org | 47 +- ideas/triad-overview.org | 7 +- ideas/triad-systemic-effects.org | 53 +- ideas/upgrade-lifecycle.org | 9 +- ideas/verification-appliance.org | 9 +- ideas/verification-monopoly.org | 9 +- ideas/verified-skill-marketplace.org | 3 +- 121 files changed, 2104 insertions(+), 2644 deletions(-) create mode 100644 .org-ids.json create mode 100644 _index.org delete mode 100644 agora/docs/agora-requirements-00-readme.org create mode 100644 ideas/_index.org create mode 100644 ideas/agora/agora-requirements-00-readme.org rename {agora/docs => ideas/agora}/agora-requirements-01-overview.org (97%) rename {agora/docs => ideas/agora}/agora-requirements-02-identity.org (98%) rename {agora/docs => ideas/agora}/agora-requirements-03-infrastructure.org (97%) rename {agora/docs => ideas/agora}/agora-requirements-04-the-primitive.org (96%) rename {agora/docs => ideas/agora}/agora-requirements-05-social.org (92%) rename {agora/docs => ideas/agora}/agora-requirements-06-exchange-and-contracts.org (93%) rename {agora/docs => ideas/agora}/agora-requirements-07-advanced-integration.org (97%) rename {agora/docs => ideas/agora}/agora-requirements-08-library.org (95%) rename {agora/docs => ideas/agora}/agora-requirements-09-implementation.org (97%) rename {agora/docs => ideas/agora}/agora-requirements-10-governance-and-assets.org (95%) rename {agora/docs => ideas/agora}/agora-requirements-10-user-journey.org (83%) rename {agora/docs => ideas/agora}/agora-requirements-11-assessment.org (84%) delete mode 100644 ideas/competitive-analysis-2026-05.org create mode 100644 ideas/competitive-analysis.org create mode 100644 ideas/competitors/aider.org create mode 100644 ideas/competitors/claude-code.org create mode 100644 ideas/competitors/codex-cli.org create mode 100644 ideas/competitors/continue.org create mode 100644 ideas/competitors/gemini-cli.org create mode 100644 ideas/competitors/hermes-agent.org create mode 100644 ideas/competitors/openclaw.org create mode 100644 ideas/competitors/opencode.org create mode 100644 ideas/competitors/thoth.org create mode 100644 ideas/compliance/_index.org delete mode 100644 ideas/passepartout-economics.org rename ideas/{stoa.org => stoa-overview.org} (57%) create mode 100644 ideas/stoa/_index.org create mode 100644 ideas/stoa/stoa-stage-0-now.org create mode 100644 ideas/stoa/stoa-stage-1-agora.org create mode 100644 ideas/stoa/stoa-stage-2-logos.org create mode 100644 ideas/stoa/stoa-stage-3-stoa.org create mode 100644 ideas/stoa/stoa-stage-4-inference.org create mode 100644 ideas/stoa/stoa-stage-5-weights.org create mode 100644 ideas/stoa/stoa-stage-6-training.org create mode 100644 ideas/stoa/stoa-stage-7-remaining.org create mode 100644 ideas/stoa/stoa-vision-roadmap.org diff --git a/.org-ids.json b/.org-ids.json new file mode 100644 index 0000000..5be7e17 --- /dev/null +++ b/.org-ids.json @@ -0,0 +1,119 @@ +{ + "284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f": "_index.org", + "04c2f221-c54f-51e5-b40a-48822cd16d45": "ideas/common-logic-iso-24707.org", + "42c86e6f-4f27-4993-8238-b7bc7d15fb7b": "ideas/stoa-overview.org", + "2f783eb4-638e-5afa-9b59-6224d086a712": "ideas/infrastructure-lock-in.org", + "1a2b38df-20ba-58ca-ba55-a072be67bd0d": "ideas/pds-as-a-service.org", + "1c95ce7d-a2db-506a-9608-df68f9ae211b": "ideas/lisp-machine-security.org", + "00ab3a4d-e3de-5605-a67d-12935bb36ab5": "ideas/comparison-with-symbolics.org", + "5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "ideas/legal-structure-alternatives.org", + "dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "ideas/time-estimates.org", + "2cdca4b0-6b41-44b4-acb0-af21d0e27b00": "ideas/orders-of-magnitude-time.org", + "caaeee11-ba6f-5566-aecd-f171b4c459c0": "ideas/patent-strategy.org", + "a5d59d12-b23e-58d6-a81b-9b8b06556949": "ideas/collective-regression-suite.org", + "528a0f6c-6fd6-41ed-9d59-237958bdaef2": "ideas/effects-growth-flywheel.org", + "57f9538a-6270-4302-8d07-d742168419eb": "ideas/alternative-growth-social-first.org", + "b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba": "ideas/triad-systemic-effects.org", + "d28adac8-08a1-40c4-ae43-b5d8d7b1743f": "ideas/growth-strategy.org", + "7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "ideas/native-org-knowledge-base.org", + "0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9": "ideas/cost-structure.org", + "45ea493b-94ad-5885-aa65-0c846e5c3c1d": "ideas/gate-rule-encoding.org", + "c34940cc-090e-57c4-8020-e78b1d32b96c": "ideas/domain-gate-packages.org", + "2afd9a3c-e96a-54c7-ac77-a05a28065b4b": "ideas/biology-parallels.org", + "1d074690-a279-59cb-b91d-e9a22ae104ad": "ideas/agora.org", + "5961e469-53a3-5f3c-ab72-3c83ef91963f": "ideas/investment-thesis.org", + "aa6d062e-a520-5d14-8773-00687ed9c689": "ideas/moats.org", + "433236a2-e5ad-41d4-a27e-4682f8bbc207": "ideas/legal-structure-practical-setup.org", + "29e4dbf3-cf19-589c-8b14-389e8a39d564": "ideas/upgrade-lifecycle.org", + "3aa22300-2f25-57b0-8787-9f199cc978b1": "ideas/competitive-analysis.org", + "98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b": "ideas/outbound-sales-compliance.org", + "8c7b9812-f8d6-4347-8915-ce8e520b7914": "ideas/agora-entry-strategy.org", + "329a30cd-55fb-496d-a60b-91388c211bba": "ideas/_index.org", + "67faf52f-9126-50a7-b87e-2bedc610dac7": "ideas/licensing.org", + "36e5b948-e07b-477f-9036-4dfe88254347": "ideas/compliance-framework-mapping.org", + "3c6b0449-a8fb-5b89-b82a-34efb21ef5b5": "ideas/compute-marketplace.org", + "1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f": "ideas/competitive-landscape-agora.org", + "efc76898-03f7-57ba-923d-35d65da88bb7": "ideas/sufficiency-flip.org", + "1c3ec48b-446c-50d2-b53e-126a81f5143f": "ideas/triad-index.org", + "45258a2d-1675-562c-9024-5d1eb2f1ea56": "ideas/evaluation-harness.org", + "2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "ideas/agora-usernames.org", + "ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "ideas/revenue-hub.org", + "d84679f1-c0c5-5be4-b19c-6573560640ee": "ideas/verified-skill-marketplace.org", + "64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "ideas/agora-contracts.org", + "a1fac32a-47de-5fbd-b67d-29152c851747": "ideas/triad-overview.org", + "827bc546-e887-5b7c-9b65-6392beaf0920": "ideas/verification-monopoly.org", + "9af13fff-9725-542b-93b1-a555bc74ad72": "ideas/lisp-economics.org", + "0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "ideas/asset-protection-structures.org", + "13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70": "ideas/self-driving-lisp-machine.org", + "84a537b4-4256-50c8-91f5-dd5b4538418f": "ideas/verification-appliance.org", + "5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "ideas/ai-industry-impact.org", + "c652688a-1ea0-487c-9222-00e954efe8a1": "ideas/competitors/hermes-agent.org", + "e929ff32-28d8-4a29-bf74-d55babc040d1": "ideas/competitors/codex-cli.org", + "416bab7c-4300-4d50-838a-5c7a8ad45d96": "ideas/competitors/thoth.org", + "85ca69dd-d085-4a55-ad11-021910b1f82e": "ideas/competitors/openclaw.org", + "7a060b36-36db-4eb7-b8cc-844bd6ac9d36": "ideas/competitors/opencode.org", + "c3aab2e8-7e43-4abc-93f0-741675cfd78c": "ideas/competitors/aider.org", + "512dd121-2292-4f3d-ac53-31bf3d12a60f": "ideas/competitors/claude-code.org", + "22d0a159-68a2-4587-9375-5046beddc20c": "ideas/competitors/continue.org", + "8d73ccb9-34e4-4899-b0c3-605998e9bebc": "ideas/competitors/gemini-cli.org", + "0f949f6c-4cf1-49eb-b9a4-ebcac27ee548": "ideas/agora/agora-requirements-05-social.org", + "2cace571-76bb-4c34-a5f4-68bc20b2e884": "ideas/agora/agora-requirements-10-user-journey.org", + "df02cddc-944a-4bcd-8ef5-f080870d5f49": "ideas/agora/agora-requirements-08-library.org", + "90484f4a-5b70-4001-93d6-e610e54ed573": "ideas/agora/agora-requirements-06-exchange-and-contracts.org", + "72570648-d943-42e5-a781-3b09791ac6ec": "ideas/agora/agora-requirements-11-assessment.org", + "6fe67db6-25bd-4d11-bd1d-b44ec809e858": "ideas/agora/agora-requirements-02-identity.org", + "f6cfc54b-919b-4311-bcbf-65e976755d40": "ideas/agora/agora-requirements-04-the-primitive.org", + "8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d": "ideas/agora/agora-requirements-09-implementation.org", + "68ffa49f-f0d8-42cf-8b69-ae69de8bb815": "ideas/agora/agora-requirements-10-governance-and-assets.org", + "a3243dd0-3209-423b-98e1-51c3eada2658": "ideas/agora/agora-requirements-07-advanced-integration.org", + "3b43a9b8-31d1-4479-a35f-22273b74f0c7": "ideas/agora/agora-requirements-03-infrastructure.org", + "b25bf753-9799-41ab-82f5-1a1416db756b": "ideas/agora/agora-requirements-01-overview.org", + "10289e64-a4ff-4c34-828f-f3a9c769b73d": "ideas/agora/agora-requirements-00-readme.org", + "558154ea-e63a-4c45-998c-26ce8588585b": "ideas/compliance/first-mover-window.org", + "b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "ideas/compliance/appi.org", + "e777064d-9950-42d5-980d-8c78cda91500": "ideas/compliance/pipa.org", + "e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "ideas/compliance/iso-27001.org", + "4a2bc62b-3f21-4212-9cd9-f9add8fc0be1": "ideas/compliance/glba.org", + "03ebdb80-a9af-4e76-a443-8556424996ed": "ideas/compliance/fatf.org", + "e6993701-3c67-49bf-82f3-06907572cbf3": "ideas/compliance/fedramp.org", + "7f46764b-47b8-4892-a526-2c1b9ee6e6df": "ideas/compliance/irap.org", + "fc736aec-ef53-4759-9787-62bc8deea2e7": "ideas/compliance/ifrs.org", + "81a815ee-bf2b-4365-9894-b814e4196850": "ideas/compliance/revenue-table.org", + "68c55deb-72bf-4b15-ac28-bcc792057543": "ideas/compliance/ifc-ps.org", + "513d5996-4ac7-4567-a992-18fc01599104": "ideas/compliance/gdpr.org", + "6a5884c8-e9b5-477e-bbf6-aa9ffd967739": "ideas/compliance/un-cefact.org", + "84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f": "ideas/compliance/hipaa.org", + "177aad72-5626-444d-a2e4-af8e1263b125": "ideas/compliance/world-bank-esf.org", + "834689e9-be0a-4822-9085-9b6b22294fd2": "ideas/compliance/privacy-act-aus.org", + "904f5f12-ec9a-4cbf-854a-0b9b1e11a521": "ideas/compliance/apra-cps-234.org", + "1c4c91ec-c465-44ab-bd91-4c3b45909ddb": "ideas/compliance/_index.org", + "c871a9f4-dd53-4e93-aa50-6acf0c606a9b": "ideas/compliance/lgpd.org", + "b8cf51e8-5f39-49ad-9547-a792a2e446aa": "ideas/compliance/eidas2.org", + "06fcdb02-2643-4f9d-ab41-e711a99cc390": "ideas/compliance/eu-ai-act.org", + "ed65031c-cbd2-4ad2-bd53-a67791e183cd": "ideas/compliance/soc2.org", + "c9830152-0160-4bdc-ab03-6f308ad43536": "ideas/compliance/sox.org", + "f6a0c00e-e922-44af-99ce-6412c4b73745": "ideas/compliance/quebec-law-25.org", + "748db16a-1382-4e5e-8812-a5d57a8de131": "ideas/compliance/nis2.org", + "87996d87-100c-4bf6-8546-a860b9d7c25b": "ideas/compliance/ccpa-cpra.org", + "ce81fefc-b7a8-4be5-912f-55fd30970b6e": "ideas/compliance/cra.org", + "085b76cc-4a65-4660-9c70-85aee10ca99e": "ideas/compliance/ismap.org", + "e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c": "ideas/compliance/compliance-index.org", + "748b0cc7-7f42-49fb-8ee3-1ae49048a178": "ideas/compliance/iso-27701.org", + "022109ad-f031-44c4-8ea0-0b3c9402ca90": "ideas/compliance/oecd.org", + "fed19a24-ad81-4837-a12b-dafbd3ec110a": "ideas/compliance/dpdp-act.org", + "9bc29937-d59a-4ae4-9623-3d17a1fe6ebb": "ideas/compliance/uk-gdpr.org", + "4eef0993-6671-41cf-ba20-d1443a3ec49d": "ideas/compliance/basel-iii.org", + "581666ba-f72c-406b-8556-93876d2b30bf": "ideas/compliance/ny-dfs-500.org", + "bafdaa23-de0b-444c-9151-c87ac65add32": "ideas/compliance/lfp-dppp.org", + "717ef2df-2a80-4362-b23a-5e7e12554251": "ideas/compliance/dora.org", + "4a1f23b0-abc4-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-3-stoa.org", + "4a1f23b0-abc1-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-0-now.org", + "4a1f23b0-abc3-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-2-logos.org", + "4a1f23b0-abc2-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-1-agora.org", + "4a1f23b0-abc7-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-6-training.org", + "c3b3dc41-945f-54e9-84eb-ca014114f1be": "ideas/stoa/_index.org", + "3f24ad65-0845-4e75-a3d7-dc4de734a6ac": "ideas/stoa/stoa-vision-roadmap.org", + "4a1f23b0-abc8-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-7-remaining.org", + "4a1f23b0-abc6-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-5-weights.org", + "4a1f23b0-abc5-4def-9876-543210abcdef": "ideas/stoa/stoa-stage-4-inference.org" +} \ No newline at end of file diff --git a/_index.org b/_index.org new file mode 100644 index 0000000..9f2c6f9 --- /dev/null +++ b/_index.org @@ -0,0 +1,25 @@ +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f +:END: +#+title: Brain +#+filetags: :index:navigation: + +This is the knowledge base for the [[id:d71df46b-9012-433c-86ce-ec21b78eac5f][triad]] — [[id:42c86e6f-4f27-4993-8238-b7bc7d15fb7b][Stoa (Verified Lisp Machine)]], [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora (Decentralized Protocol)]], and the interconnected concepts around them. + +Start with the [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stoa staged roadmap]] if you are new here: it walks from conventional computing through each stage of verified infrastructure, ending at what remains. + +**Sections:** + +- [[id:42c86e6f-4f27-4993-8238-b7bc7d15fb7b][Stoa — Verified Lisp Machine]] — the staged roadmap from conventional computing through verified [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]], with cost-benefit per stage +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora — Decentralized Social Protocol]] — identity, communication, contracts, governance +- [[id:329a30cd-55fb-496d-a60b-91388c211bba][Ideas]] — all concept pages and analysis + +**Core concept pages:** + +- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification Appliance]] — what a verified Lisp image means, the ACL2 bootstrap +- [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Self-Driving Lisp Machine]] — where [[id:e01b9199-2cba-4ac2-824b-ba1b033cc23e][Passepartout]], Stoa, and Logos converge +- [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine Security]] — Merkle memory, gate stack, structural proofs +- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain Gate Packages]] — capability authorization, the Dispatcher +- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate Rule Encoding]] — how policies are encoded and enforced +- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Triad Index]] — Logos, Stoa, Agora as a system diff --git a/agora/docs/agora-requirements-00-readme.org b/agora/docs/agora-requirements-00-readme.org deleted file mode 100644 index 20814cb..0000000 --- a/agora/docs/agora-requirements-00-readme.org +++ /dev/null @@ -1,37 +0,0 @@ -#+title: Agora: Decentralized Social Network -#+AUTHOR: Amr -#+CREATED: [2026-03-17 Tue] -#+BEGIN_COMMENT -A decentralized social network protocol for the ATmosphere (AT Protocol) ecosystem. -#+END_COMMENT - -* Agora: Decentralized Social Network - -This project contains the specification and analysis for a decentralized social network built on open protocols. - -* Project Tasks - -See the actionable tasks for this project in GTD.org (Agora project) - -* Key Documents - -- [[file:agora-requirements-01-overview.org][01. Overview]] -- [[file:agora-requirements-02-identity.org][02. Identity]] -- [[file:agora-requirements-03-infrastructure.org][03. Infrastructure]] -- [[file:agora-requirements-04-the-primitive.org][04. The Primitive]] -- [[file:agora-requirements-05-social.org][05. Social Spaces]] -- [[file:agora-requirements-05-public-space.org][05. Public Space & Exchange]] -- [[file:agora-requirements-06-exchange.org][06. Exchange]] -- [[file:agora-requirements-06-advanced-integration.org][06. Advanced Integration]] -- [[file:agora-requirements-07-library.org][07. Farcaster & Nostr Integration]] -- [[file:agora-requirements-08-implementation.org][08. Implementation]] -- [[file:agora-requirements-09-strategy.org][09. Strategy]] -- [[file:agora-requirements-10-assessment.org][10. Gap Assessment]] -- [[file:agora-consolidated-gap-analysis.org][Consolidated Gap Analysis]] - -* Status - -- [X] Concept and atomic notes complete -- [X] Comprehensive specification built -- [ ] Governance decision (DEC-001) pending -- [ ] Implementation planning not started \ No newline at end of file diff --git a/ideas/_index.org b/ideas/_index.org new file mode 100644 index 0000000..a6bc0cf --- /dev/null +++ b/ideas/_index.org @@ -0,0 +1,9 @@ +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 329a30cd-55fb-496d-a60b-91388c211bba +:ID: auto-ideas +:END: +#+title: Ideas +#+filetags: :index: + +Section index for ideas. Browse by file. diff --git a/ideas/agora-contracts.org b/ideas/agora-contracts.org index 080b103..e6aa9ac 100644 --- a/ideas/agora-contracts.org +++ b/ideas/agora-contracts.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 64708e1f-00e9-4cb7-b44b-ea0b98e5296d :ID: agora-contracts :CREATED: [2026-05-23 Sat] :END: @@ -14,7 +15,7 @@ Existing smart contract platforms (Ethereum, Solana, Cosmos) verify only that ex - Ethereum: The contract ran according to the EVM bytecode (execution validity) - Agora: The contract is correct with respect to its specification, AND it ran correctly (correctness + execution) -This means Agora contracts can encode real-world regulations ([[file:compliance/hipaa.org][HIPAA]], SOC2, [[file:compliance/gdpr.org][GDPR]]) as gate rules and prove that a contract execution satisfies them. No existing platform does this. +This means Agora contracts can encode real-world regulations ([[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]], [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]], [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]) as gate rules and prove that a contract execution satisfies them. No existing platform does this. * What Contracts Enable @@ -28,7 +29,7 @@ How it works: - Every transaction runs through the symbolic engine and produces a proof log - Any instance can verify any other instance's contract execution by replaying the proof -Revenue: Transaction fee per contract execution in the [[file:compute-marketplace.org][compute marketplace]], deployment fee per verified contract, premium for certification weight. +Revenue: Transaction fee per contract execution in the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], deployment fee per verified contract, premium for certification weight. Comparison: Ethereum collects ~$20B/yr in transaction fees. Agora's verifiably correct contracts target the same market with a stronger value proposition. The limitation is liquidity, not technology — network effects determine adoption. @@ -37,7 +38,7 @@ Comparison: Ethereum collects ~$20B/yr in transaction fees. Agora's verifiably c Organizations running multiple triad instances need contracts that span instances: cross-instance policy, unified compliance, federated identity. Use cases: -- Enterprise: all instances in the finance department must apply the [[file:compliance/sox.org][SOX]] gate rule set +- Enterprise: all instances in the finance department must apply the [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] gate rule set - Consortium: each member instance votes on protocol upgrades - Supply chain: Instance A verifies shipment, Instance B verifies payment, both must agree @@ -69,13 +70,13 @@ Revenue: Attestation fee (one-time or annual), verification fee per reputation q ** 5. Insurance Marketplace -If certification carries legal weight (as described in [[file:compute-marketplace.org][compute marketplace]]), then: +If certification carries legal weight (as described in [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]), then: - Proof insurance: A provider insures their verification results. If a proof turns out wrong, the insurance pays out. Premiums are set by actuarial gate rules based on the provider's track record. - Contract execution insurance: Insure against bugs in contract code (even ACL2-verified contracts can have specification errors). - Reputation staking pool: A reinsurance pool where multiple providers stake against each other's attestations. -Revenue: Premiums, pool fees, actuarial gate rule [[file:licensing.org][licensing]]. +Revenue: Premiums, pool fees, actuarial gate rule [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]]. Why this is defensible: Insurance requires capital and track record. A new entrant cannot bootstrap reputation overnight. The early player accumulates both, creating a moat that compounds with every honest attestation. @@ -92,13 +93,13 @@ Revenue: Commission on each data transaction (the compute marketplace extended t ** 7. Namespace Sub-Leasing and Auction -[[file:agora-usernames.org][Premium usernames]] can be sub-leased between DIDs. The registry takes a commission on each lease. +[[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium usernames]] can be sub-leased between DIDs. The registry takes a commission on each lease. Revenue: Commission per lease transaction, auction fees for contested names, premium for verified ownership. ** 8. Dispute Resolution -When two Agora instances disagree on a contract execution, submit to a verified arbitrator. The arbitrator runs the contract in their own Passepartout and the proof log resolves the ambiguity unambiguously — the dispute is about facts, not interpretations, because the contract terms are formal gate rules. +When two Agora instances disagree on a contract execution, submit to a verified arbitrator. The arbitrator runs the contract in their own [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] and the proof log resolves the ambiguity unambiguously — the dispute is about facts, not interpretations, because the contract terms are formal gate rules. Revenue: Fee per resolution, premium for reputation-weighted arbitration (arbitrators with long track records charge more). @@ -108,7 +109,7 @@ Revenue: Fee per resolution, premium for reputation-weighted arbitration (arbitr |----------+-----------+--------------+-------+------------| | Smart contracts (general) | $20B/yr (Ethereum) | Transaction fees | End State | Installed base | | Contract templates | New market | Per-template sale | Zero | Gate rule SDK | -| Governance (multi-instance) | New market | Annual license | Zero | [[file:stoa.org][Stoa]] premium | +| Governance (multi-instance) | New market | Annual license | Zero | [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] premium | | Liquid democracy | New market | Per-vote fee | End State | Installed base | | Attestation | New market | Per-attestation | Zero | DID registry | | Insurance marketplace | $1T+ (global insurance) | Premiums | End State | Installed base + capital | @@ -127,13 +128,13 @@ The compute marketplace and the contract platform reinforce each other: - Attestation bridges them: a compute provider's track record is a verifiable contract history - Insurance prices compute risk based on attestation -The triad's network effects compound when all three layers (compute, contracts, attestation) are active simultaneously. Any one layer without the others is weaker — together they create the [[file:verification-monopoly.org][verification monopoly]]. +The triad's network effects compound when all three layers (compute, contracts, attestation) are active simultaneously. Any one layer without the others is weaker — together they create the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]]. * References -- [[file:agora.org][Agora overview]] -- [[file:agora-usernames.org][Premium username registry]] -- [[file:pds-as-a-service.org][PDS as a service]] -- [[file:compute-marketplace.org][Compute marketplace]] -- [[file:revenue-hub.org][Revenue streams overview]] -- [[file:verification-monopoly.org][Verification monopoly]] +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]] +- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]] +- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] +- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] +- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] +- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The [[id:90484f4a-5b70-4001-93d6-e610e54ed573][Agora Exchange requirements]] specify the contract and exchange layer in detail. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]]] diff --git a/ideas/agora-entry-strategy.org b/ideas/agora-entry-strategy.org index 903d97c..2fccd0b 100644 --- a/ideas/agora-entry-strategy.org +++ b/ideas/agora-entry-strategy.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 8c7b9812-f8d6-4347-8915-ce8e520b7914 :ID: agora-entry-strategy :CREATED: [2026-05-23 Sat] :END: @@ -175,9 +176,9 @@ Organized communities are the entry point because they force the Agora to be the * References -- [[file:agora.org][Agora overview]] +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]] - Agora Protocol Overview — Platform Replacement Strategy - Social Space — Collective Personas and Governance - Exchange and Contracts — SCAL, Escrow, Arbitration -- [[file:alternative-growth-social-first.org][Social-first growth scenario]] -- [[file:competitive-landscape-agora.org][Full competitive landscape]] +- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]] +- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Full competitive landscape]] diff --git a/ideas/agora-usernames.org b/ideas/agora-usernames.org index c16eb04..cbc14d9 100644 --- a/ideas/agora-usernames.org +++ b/ideas/agora-usernames.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 2e390c1d-65f3-5fb3-b898-ac3fc4291ee7 :END: #+title: Premium Username Registry on Agora @@ -10,4 +11,4 @@ The DID system is permissionless — anyone generates their own DID via HD key d - **Premium tier:** short names (2-3 chars), common words, brand names, squatter prevention via auction or annual lease - **Revenue model:** $5-$50/year per premium username, auction revenue for highly contested names (single-letter, common surnames). ENS-style: registration fees fund development, not speculation. -At scale: 1M premium usernames at $10/yr average = $10M/yr recurring. The namespace registry is a natural monopoly — the early player's registry is the most widely accepted, so every new user registers there. Network effects lock in. The premium username registry works together with a [[file:pds-as-a-service.org][PDS as a service]] offering and a [[file:compute-marketplace.org][Compute marketplace]] to form a complete revenue ecosystem. +At scale: 1M premium usernames at $10/yr average = $10M/yr recurring. The namespace registry is a natural monopoly — the early player's registry is the most widely accepted, so every new user registers there. Network effects lock in. The premium username registry works together with a [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] offering and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] to form a complete revenue ecosystem. diff --git a/ideas/agora.org b/ideas/agora.org index 8e0c822..d421a2c 100644 --- a/ideas/agora.org +++ b/ideas/agora.org @@ -1,25 +1,26 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 1d074690-a279-59cb-b91d-e9a22ae104ad :END: #+title: Agora — The Society (Decentralized Network) #+filetags: :passepartout:agora:network:dids: -Agora is the decentralized identity and communication layer that connects Passepartout instances: +Agora is the decentralized identity and communication layer that connects [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances: - **Self-sovereign identity** via HD key derivation (BIP-44) - **Encrypted messaging** via DIDComm (agent-to-agent and agent-to-human) - **Notes** as atomic, content-addressed, signed data units (mapped from Passepartout memory-objects) - **Relay Network** for censorship-resistant message routing - **Personal Data Store (PDS)** — the Merkle fact store exposed as a network-addressable service -- **Compute marketplace** where instances offer symbolic engine capacity +- **[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]** where instances offer symbolic engine capacity - **Contracts and liquid democracy** infrastructure The PDS is Passepartout's in-process memory — the Merkle tree, the fact store, the memory-objects. Every memory-object already has a SHA-256 hash, which maps directly to Agora's CIDv1 content addressing. Revenue paths from Agora: -- [[file:agora-usernames.org][Premium username registry]] — $10M/yr at scale -- [[file:pds-as-a-service.org][PDS as a service]] — $18M/yr at scale -- [[file:compute-marketplace.org][Compute marketplace]] — venture-scale -- [[file:agora-contracts.org][Smart contracts + contract marketplace]] — the kill app +- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]] — $10M/yr at scale +- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] — $18M/yr at scale +- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — venture-scale +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Smart contracts + contract marketplace]] — the kill app -See [[file:revenue-hub.org][Revenue streams overview]] for the full picture across all triad components. +See [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] for the full picture across all triad components. diff --git a/ideas/agora/agora-requirements-00-readme.org b/ideas/agora/agora-requirements-00-readme.org new file mode 100644 index 0000000..1f24852 --- /dev/null +++ b/ideas/agora/agora-requirements-00-readme.org @@ -0,0 +1,41 @@ +#+title: Agora: Decentralized Social Network +#+AUTHOR: Amr +#+CREATED: [2026-03-17 Tue] +#+BEGIN_COMMENT +A decentralized social network protocol for the ATmosphere (AT Protocol) ecosystem. +#+END_COMMENT + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 10289e64-a4ff-4c34-828f-f3a9c769b73d +:END: +* [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]: Decentralized Social Network + +This project contains the specification and analysis for a decentralized social network built on open protocols. + +* Project Tasks + +See the actionable tasks for this project in GTD.org (Agora project) + +* Key Documents + +- [[id:b25bf753-9799-41ab-82f5-1a1416db756b][01. Overview]] +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02. Identity]] +- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03. Infrastructure]] +- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][04. The Primitive]] +- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][05. Social Spaces]] +- +- +- +- +- +- +- +- + +* Status + +- [X] Concept and atomic notes complete +- [X] Comprehensive specification built +- [ ] Governance decision (DEC-001) pending +- [ ] Implementation planning not started \ No newline at end of file diff --git a/agora/docs/agora-requirements-01-overview.org b/ideas/agora/agora-requirements-01-overview.org similarity index 97% rename from agora/docs/agora-requirements-01-overview.org rename to ideas/agora/agora-requirements-01-overview.org index 4c87d69..570ebc9 100644 --- a/agora/docs/agora-requirements-01-overview.org +++ b/ideas/agora/agora-requirements-01-overview.org @@ -5,7 +5,11 @@ #+ID: agora-requirements-01-overview #+STARTUP: content -* 1. Introduction to the Agora Protocol +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: b25bf753-9799-41ab-82f5-1a1416db756b +:END: +* 1. Introduction to the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] Protocol The Agora Protocol defines a novel architecture for decentralized digital interaction. Its primary objective is to replace extractive, centralized platforms—the era of *"Digital Feudalism"* where corporations own user data and control visibility via secret algorithms—with a decentralized *"Social Operating System"* that provides Identity, Justice, and Commerce for sovereign individuals and communities. @@ -13,7 +17,7 @@ Agora returns power to the edges by providing a modular protocol stack where tru * 2. Foundational Principles -Agora's design is predicated upon a set of core principles that collectively ensure a robust, user-centric decentralized network. +Agora's design is predicated upon a set of core principles that collectively ensure a robust, user-centric [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][decentralized network]]. ** 2.1. User Sovereignty and Data Ownership @@ -39,7 +43,7 @@ Agora's unique capabilities stem from the synergistic integration of three prima At the heart of Agora's data model is the "Note"—the atomic, universal unit of information. Every piece of content or interaction within the protocol, regardless of its semantic meaning (e.g., a social post, a message, a contract, an encyclopedia entry, a product listing), is encapsulated within a Note. -For a comprehensive technical breakdown of the Note's structure, cryptographic hashing, and content flag schema, see *[[file:agora-requirements-04-the-primitive.org][04: The Primitive]]*. +For a comprehensive technical breakdown of the Note's structure, cryptographic hashing, and content flag schema, see *[[id:f6cfc54b-919b-4311-bcbf-65e976755d40][04: The Primitive]]*. *** 3.1.2. Benefits of the Unified Note Primitive @@ -57,7 +61,7 @@ Agora's identity system grants users absolute control over their digital presenc The Master Key serves as the absolute root of a user's digital being within Agora. - *Root of Trust:* A single, securely generated and stored secret seed from which all other identities are derived. - *Hierarchical Derivation:* Utilizes a BIP-44 compatible HD derivation path (`m/44'/1'/account'/persona'/key_purpose/key_index`) to generate an infinite number of unlinkable Personas, each acting as a sovereign sub-root for its own functional keys. -- *Secure Storage:* Recommended for offline storage or within Hardware Security Modules (HSMs) to ensure maximum protection. +- *Secure Storage:* Recommended for offline storage or within [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] Security Modules (HSMs) to ensure maximum protection. *** 3.2.2. Personas: Functional Digital Identities @@ -250,9 +254,9 @@ Reduce "empty feed" problem by immediately showing relevant content based on use - Show "Your Twitter follows on Agora" for easy reconnecting. - Surface collectives matching imported community memberships. -** The "Four Orders of Growth" (Scaling Sequence) +** The "Four Orders of [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][Growth]]" (Scaling Sequence) -Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives." Agora follows a strictly defined orders-of-magnitude growth strategy: +Scaling a decentralized network requires shifting from "Hand-holding" to "Protocol Incentives." Agora follows a strictly defined orders-of-magnitude [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][growth strategy]]: *** Order 1: The First 1,000 (The "Founders") - *Target:* Technical enthusiasts, privacy advocates, and niche professional guilds (e.g., decentralized AI devs). @@ -392,7 +396,7 @@ As a decentralized protocol with no central authority, Agora is designed to oper - *Micro-Payments:* Lightning Network payments generally fall below traditional AML/KYC thresholds. - *Non-Custodial:* Agora is non-custodial. Users control their own keys and funds. -** Data Privacy (GDPR/CCPA) +** Data Privacy ([[id:c0fdec00-8a44-43f0-ac81-e8dc61411865][GDPR]]/CCPA) - *The "Right to be Forgotten":* In a CID-based system, data is not "deleted" but can be "un-indexed" or its decryption keys revoked. - *Sovereign Control:* Users have absolute control over their own data in their PDS. diff --git a/agora/docs/agora-requirements-02-identity.org b/ideas/agora/agora-requirements-02-identity.org similarity index 98% rename from agora/docs/agora-requirements-02-identity.org rename to ideas/agora/agora-requirements-02-identity.org index 47b29c3..7ec0df1 100644 --- a/agora/docs/agora-requirements-02-identity.org +++ b/ideas/agora/agora-requirements-02-identity.org @@ -1,9 +1,13 @@ #+title: Identity: The Genesis of Your Digital Being -* Identity: The Genesis of Your Digital Being +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 6fe67db6-25bd-4d11-bd1d-b44ec809e858 +:END: +* [[id:750876d3-0cf8-4818-a323-a4f974870f4f][Identity: The Genesis of Your Digital Being]] ** Master Key (Psyche) -The Master Key, often referred to as "Psyche" (Latin for soul or animating principle), is the absolute foundation of your digital identity in Agora. It serves as your unassailable root of trust, from which every other functional identity (your Personas) is cryptographically derived. This section meticulously outlines the Master Key's core requirements, elucidates how it empowers flexible organizational structures, and details the robust mechanisms for its secure management and resilient recovery. It is the ultimate key to your self-sovereignty. +The Master Key, often referred to as "Psyche" (Latin for soul or animating principle), is the absolute foundation of your digital identity in [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]. It serves as your unassailable root of trust, from which every other functional identity (your Personas) is cryptographically derived. This section meticulously outlines the Master Key's core requirements, elucidates how it empowers flexible organizational structures, and details the robust mechanisms for its secure management and resilient recovery. It is the ultimate key to your self-sovereignty. *** Requirements & The Root of Trust @@ -12,7 +16,7 @@ The Master Key, often referred to as "Psyche" (Latin for soul or animating princ - All functional identities (Personas) MUST be derived from this single Master Key seed using Hierarchical Deterministic (HD) derivation, providing an organized and secure structure for digital identities. - The Master Key MUST be generated from a minimum of 256 bits of high-quality, cryptographically secure entropy. - The Master Key MUST be encoded as a BIP-39 mnemonic phrase (typically 24 words) for human-readable, offline backup and disaster recovery. -- The Master Key MUST be stored offline (e.g., on paper, engraved metal) or within a tamper-resistant hardware security module (HSM) for maximum protection against compromise. +- The Master Key MUST be stored offline (e.g., on paper, engraved metal) or within a tamper-resistant [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] security module (HSM) for maximum protection against compromise. - The system MUST utilize a custom HD derivation path: `m/44'/1'/account'/persona'/key_purpose/key_index`, uniquely identifying Agora's identity structure within the broader BIP-44 ecosystem. (*Note: Index `1'` is utilized for the experimental/testnet phase; a unique permanent index will be registered for the Agora Mainnet via SLIP-0044.*) - This path allows each Persona to act as a "Sub-Root," deriving its own autonomous functional keys (e.g., for Bitcoin, Lightning, PGP, or SSH) without requiring access to the Master Key once the Persona's extended private key (xpriv) is provisioned to a device. - Each `persona'` index within this derivation path MUST represent a distinct DID (Decentralized Identifier), ensuring global uniqueness and unlinkability. diff --git a/agora/docs/agora-requirements-03-infrastructure.org b/ideas/agora/agora-requirements-03-infrastructure.org similarity index 97% rename from agora/docs/agora-requirements-03-infrastructure.org rename to ideas/agora/agora-requirements-03-infrastructure.org index 0e3a4d9..41c8c61 100644 --- a/agora/docs/agora-requirements-03-infrastructure.org +++ b/ideas/agora/agora-requirements-03-infrastructure.org @@ -5,9 +5,13 @@ #+ID: agora-requirements-03-infrastructure #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 3b43a9b8-31d1-4479-a35f-22273b74f0c7 +:END: * The Sovereign Infrastructure: Your Digital Foundation -Agora's infrastructure is meticulously architected to deliver on the promise of true digital sovereignty. Unlike traditional platforms that centralize control, Agora distributes power to the edges—directly into the hands of users. This section details the foundational infrastructure that makes self-sovereign identity, data ownership, decentralized communication, and global discovery not just possible, but practical and scalable. +[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]'s infrastructure is meticulously architected to deliver on the promise of true digital sovereignty. Unlike traditional platforms that centralize control, Agora distributes power to the edges—directly into the hands of users. This section details the foundational infrastructure that makes self-sovereign identity, data ownership, decentralized communication, and global discovery not just possible, but practical and scalable. ** Personal Data Store (PDS): Your Digital Fortress @@ -53,7 +57,7 @@ To send a private message: *** PDS Migration: Seamless Sovereignty Transfer -PDS Migration represents a fundamental capability of Agora's architecture—the seamless, user-initiated transfer of one's entire digital corpus from one Personal Data Store to another. Unlike traditional platforms where data migration is often complex, permission-based, or impossible, Agora treats PDS Migration as a first-class operation. This is not an edge case, but a core feature that ensures users retain ultimate sovereignty over their data throughout its lifecycle. Whether changing hosting providers, upgrading hardware, or responding to security incidents, PDS Migration ensures users are never trapped by infrastructure choices. +PDS Migration represents a fundamental capability of Agora's architecture—the seamless, user-initiated transfer of one's entire digital corpus from one Personal Data Store to another. Unlike traditional platforms where data migration is often complex, permission-based, or impossible, Agora treats PDS Migration as a first-class operation. This is not an edge case, but a core feature that ensures users retain ultimate sovereignty over their data throughout its lifecycle. Whether changing hosting providers, upgrading [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]], or responding to security incidents, PDS Migration ensures users are never trapped by infrastructure choices. **** Concept @@ -610,10 +614,9 @@ For Collectives, NGOs, or LLCs managing sensitive operations, relying on "free" - *Fees:* Reasonable pricing? - *Users:* Number of active personas (network effect) - ** Search & Indexing: The Firehose Indexers -In a decentralized network, finding historical content or discovering new Personas requires specialized indexing infrastructure. Indexing Nodes are high-performance servers that ingest the public Relay firehose to provide full-text search and complex discovery services. +In a [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][decentralized network]], finding historical content or discovering new Personas requires specialized indexing infrastructure. Indexing Nodes are high-performance servers that ingest the public Relay firehose to provide full-text search and complex discovery services. *** Requirements - Indexing Nodes MUST ingest public Content Objects from the Relay firehose. @@ -813,10 +816,10 @@ The adoption of a PDS-proximate / thin client architecture is a strategic impera ** Related Documents -- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure and core encryption primitives. -- [[file:agora-requirements-05-social.org][Social]] - Messaging models, social publishing, and the attention marketplace. -- [[file:agora-requirements-02-identity.org][Identity]] - Master Key (Psyche) and Persona governance. -- [[file:agora-requirements-06-exchange-and-contracts.org][Exchange and Contracts]] - Economic primitives, fee structures, and the SCAL layer. +- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure and core encryption primitives. +- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Messaging models, social publishing, and the attention marketplace. +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Master Key (Psyche) and Persona governance. +- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][Exchange and Contracts]] - Economic primitives, fee structures, and the SCAL layer. ** Gaps diff --git a/agora/docs/agora-requirements-04-the-primitive.org b/ideas/agora/agora-requirements-04-the-primitive.org similarity index 96% rename from agora/docs/agora-requirements-04-the-primitive.org rename to ideas/agora/agora-requirements-04-the-primitive.org index a6eb39e..43338ae 100644 --- a/agora/docs/agora-requirements-04-the-primitive.org +++ b/ideas/agora/agora-requirements-04-the-primitive.org @@ -5,7 +5,11 @@ #+ID: agora-requirements-04-the-primitive #+STARTUP: content -* The Primitive: The Atomic Foundation of Agora +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: f6cfc54b-919b-4311-bcbf-65e976755d40 +:END: +* The Primitive: The Atomic Foundation of [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] ** Concept: The Universal Data Primitive @@ -158,7 +162,7 @@ Agora implements strict validation to ensure network integrity. }, "contract": { "type": "object", - "description": "Optional rules of engagement governing the payload (e.g. licensing, price).", + "description": "Optional rules of engagement governing the payload (e.g. [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], price).", "additionalProperties": true }, "payload": { @@ -414,10 +418,10 @@ Validation error: Notifications (`notify`) require the target DID to be present ** Related Documents -- [[file:agora-requirements-02-identity.org][Identity]] - Personas and contracts -- [[file:agora-requirements-03-infrastructure.org][Infrastructure]] - PDS and Relay -- [[file:agora-requirements-05-social.org][Social]] - Relationships and communication -- [[file:agora-requirements-06-exchange.org][Exchange]] - Economic layer +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Personas and contracts +- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure]] - PDS and Relay +- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Relationships and communication +- Exchange (see Exchange and Contracts spec) - Economic layer ** Gaps diff --git a/agora/docs/agora-requirements-05-social.org b/ideas/agora/agora-requirements-05-social.org similarity index 92% rename from agora/docs/agora-requirements-05-social.org rename to ideas/agora/agora-requirements-05-social.org index dee8260..3b48e9e 100644 --- a/agora/docs/agora-requirements-05-social.org +++ b/ideas/agora/agora-requirements-05-social.org @@ -5,9 +5,13 @@ #+ID: agora-requirements-05-social-space #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 0f949f6c-4cf1-49eb-b9a4-ebcac27ee548 +:END: * Social Space: Where Human Connection Becomes Sovereign -The Social Space is where Agora's revolutionary architecture transforms how humans connect, communicate, and transact. Unlike traditional platforms that own your relationships and monetize your attention, Agora puts you in complete control of your social graph. Every interaction—from a casual conversation to a binding commercial contract—is self-owned, cryptographically secured, and entirely under your sovereignty. This is social interaction reimagined for a decentralized future. +The Social Space is where [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]'s revolutionary architecture transforms how humans connect, communicate, and transact. Unlike traditional platforms that own your relationships and monetize your attention, Agora puts you in complete control of your social graph. Every interaction—from a casual conversation to a binding commercial contract—is self-owned, cryptographically secured, and entirely under your sovereignty. This is social interaction reimagined for a decentralized future. ** Concept @@ -131,7 +135,7 @@ A Profile is a public-facing presentation of a Persona. Agora supports multiple - Profile updates create new CIDs, preserving a verifiable history of the identity's presentation. *** Profile as Static Site -Personas can publish their profiles and professional portfolios as decentralized static websites using the native hosting model (see [[file:agora-requirements-03-infrastructure.org][Infrastructure]]). Agora-aware browsers render these natively from CIDs, while legacy browsers access them via Gateways with automated SSL and domain mapping. +Personas can publish their profiles and professional portfolios as decentralized static websites using the native hosting model (see [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure]]). Agora-aware browsers render these natively from CIDs, while legacy browsers access them via Gateways with automated SSL and domain mapping. ** The Attention Marketplace (The Information Router) @@ -176,6 +180,6 @@ Moderation is treated as "Competitive Labeling." Users subscribe to multiple Lab ** Related Documents -- [[file:agora-requirements-06-exchange-and-contracts.org][06: Exchange and Contracts]] - Economic layer and human connection formalization. -- [[file:agora-requirements-02-identity.org][02: Identity]] - Personas and Master Keys. -- [[file:agora-requirements-03-infrastructure.org][03: Infrastructure]] - PDS and Relays. +- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06: Exchange and Contracts]] - Economic layer and human connection formalization. +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]] - Personas and Master Keys. +- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03: Infrastructure]] - PDS and Relays. diff --git a/agora/docs/agora-requirements-06-exchange-and-contracts.org b/ideas/agora/agora-requirements-06-exchange-and-contracts.org similarity index 93% rename from agora/docs/agora-requirements-06-exchange-and-contracts.org rename to ideas/agora/agora-requirements-06-exchange-and-contracts.org index 8d5c52b..fe18d51 100644 --- a/agora/docs/agora-requirements-06-exchange-and-contracts.org +++ b/ideas/agora/agora-requirements-06-exchange-and-contracts.org @@ -5,11 +5,15 @@ #+ID: agora-requirements-06-exchange #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 90484f4a-5b70-4001-93d6-e610e54ed573 +:END: * Exchange ** Concept -The Exchange layer provides the economic substrate of Agora: value transfer via the Lightning Network, multi-currency support, and payment primitives. Built on top of Content Objects (see [[file:agora-requirements-04-the-primitive.org][The Primitive]]) and Social relationships (see [[file:agora-requirements-05-social.org][Social]]). +The Exchange layer provides the economic substrate of [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]: value transfer via the Lightning Network, multi-currency support, and payment primitives. Built on top of Content Objects (see [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]]) and Social relationships (see [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]]). ** Lightning Native @@ -191,7 +195,7 @@ Payment for task completion: To enable Personas to execute binding agreements with decentralized dispute resolution, Agora implements SCAL. A contract in this system is not a static PDF; it is an executable cryptographic object. *** 1. The Ricardian Contract Module -Agora contracts follow the Ricardian model, ensuring they are both human-readable and machine-executable. +[[id:b265f66d-f7b9-4ebd-b4e3-a82cefe23981][Agora contracts]] follow the Ricardian model, ensuring they are both human-readable and machine-executable. - *Natural Language (The Markdown):* The human-readable terms of the agreement (e.g., "Person A delivers 100 bricks to Person B by Friday"). - *Machine Logic (The JSON-LD):* The executable parameters embedded in the Note's metadata (e.g., `due_date: 2026-01-16`, `price_sats: 50000`, `arbitrator_did: did:key:xyz`). - *The Merkle Link:* Both parts are hashed together into a single Content Identifier (CID). If a single comma is changed in the text, the hash changes, breaking the digital contract. This ensures the "Code" and the "Law" remain identical. @@ -210,7 +214,7 @@ To automate the release of HODL invoices without manual buyer intervention, SCAL - *Digital Goods:* Support for Zero-Knowledge Proofs (ZKP). The payment is released automatically once the client cryptographically verifies that the received file hash matches the contracted payload. *** 4. Multi-Level Arbitration & The Ricardian Evidence Vault -To address disputes without a central state, contracts reference a tiered system of human judgment (The "Circles" Model). As detailed in the [[file:agora-requirements-10-governance-and-assets.org][Governance]] specifications, this involves escalating from Local Elders to specialized Guilds, and finally to Global Juries. +To address disputes without a central state, contracts reference a tiered system of human judgment (The "Circles" Model). As detailed in the [[id:68ffa49f-f0d8-42cf-8b69-ae69de8bb815][Governance]] specifications, this involves escalating from Local Elders to specialized Guilds, and finally to Global Juries. - *Web of Trust (WoT) Level 1:* Arbitrators at Level 1 are selected based on Transitive Trust (e.g., the system finds a mutual connection trusted by both parties within 3 degrees of separation). - *Ricardian Evidence Vault:* During a dispute, parties upload encrypted "Evidence Blobs" to their PDS. Using Zero-Knowledge Proofs (ZKPs) or Shared Keys, they grant the current level of arbitrators temporary read-access to the evidence without making it public. - *Real-Time Adjudication:* If live hearings are required, the system MUST support VoIP/WebRTC signaling conducted over an authenticated DIDComm v2 channel, utilizing "blind" Community TURN servers if direct P2P fails. @@ -264,7 +268,7 @@ In environments with weak state enforcement, Agora enables the use of physical a - *The Pledge:* A user links a Digital Twin token (representing a physical asset like a car or machine) to a Civil Contract Note. - *The Lock:* The contract's logic "freezes" the Digital Twin token. While the user maintains physical possession of the asset, they are cryptographically barred from selling or transferring the digital title until the contract obligations (e.g., a loan repayment) are met. -- *Enforcement:* Severe defaults can trigger the "IoT Stick" (see [[file:agora-requirements-07-advanced-integration.org][Advanced Integration]]), where an IoT-enabled smart lock physically disables the asset based on an Arbitration (HDR) ruling. +- *Enforcement:* Severe defaults can trigger the "IoT Stick" (see [[id:a3243dd0-3209-423b-98e1-51c3eada2658][Advanced Integration]]), where an IoT-enabled smart lock physically disables the asset based on an Arbitration (HDR) ruling. ** Advanced Exchange Features @@ -297,9 +301,9 @@ Agora handles recurring payments natively without centralized payment processors ** Related Documents -- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure -- [[file:agora-requirements-05-social.org][Social]] - Connection types for economic relationships -- [[file:agora-requirements-02-identity.org][Identity]] - Contracts and attestations +- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure +- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Connection types for economic relationships +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Contracts and attestations ** Gaps diff --git a/agora/docs/agora-requirements-07-advanced-integration.org b/ideas/agora/agora-requirements-07-advanced-integration.org similarity index 97% rename from agora/docs/agora-requirements-07-advanced-integration.org rename to ideas/agora/agora-requirements-07-advanced-integration.org index 6ba12bf..e5175bb 100644 --- a/agora/docs/agora-requirements-07-advanced-integration.org +++ b/ideas/agora/agora-requirements-07-advanced-integration.org @@ -5,13 +5,17 @@ #+ID: agora-requirements-06-advanced-integration #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: a3243dd0-3209-423b-98e1-51c3eada2658 +:END: * Advanced Integration ** AI Integration *** Overview -Agora enables AI at multiple layers: as sovereign actors, personal assistants, algorithms, and collaborative agents. All AI interactions are economically mediated via Lightning and respect user data sovereignty. +[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] enables AI at multiple layers: as sovereign actors, personal assistants, algorithms, and collaborative agents. All AI interactions are economically mediated via Lightning and respect user data sovereignty. *** AI Personas (Sovereign AI Actors) @@ -27,7 +31,7 @@ Agora enables AI at multiple layers: as sovereign actors, personal assistants, a - AI providers set their own pricing; market competition drives efficiency. **** Execution Tiers & Compute Swarms -- *Tier 1 (On-Device):* Models run locally using WebNN or local NPU/GPU. Zero privacy leak, no query fees, hardware-limited. +- *Tier 1 (On-Device):* Models run locally using WebNN or local NPU/GPU. Zero privacy leak, no query fees, [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]-limited. - *Tier 2 (Cloud):* Access to state-of-the-art models. Queries encrypted with X25519. Provider sees query but not user identity if anonymous persona used. - *Tier 3 (Compute Swarms):* Decentralized P2P AI Marketplace. For heavy tasks (e.g., generating 4K video or training a guild-wide model), the network taps into the spare GPU power of the community. Nodes that provide "Compute" are rewarded with sats. @@ -67,7 +71,7 @@ AI algorithms that process content for curation, moderation, sorting, and rankin - The system MUST support a marketplace of open-source "Sorting Algorithms" for feed display. - Algorithms MUST run locally on the client or as trusted services in the user's PDS. - Algorithms MUST be content-addressed (CID) for integrity verification. -- Algorithm developers can monetize via licensing fees (Lightning). +- Algorithm developers can monetize via [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] fees (Lightning). **** Curation Algorithms - *Feed Ranking:* Sort posts by relevance, recency, engagement, or custom criteria. diff --git a/agora/docs/agora-requirements-08-library.org b/ideas/agora/agora-requirements-08-library.org similarity index 95% rename from agora/docs/agora-requirements-08-library.org rename to ideas/agora/agora-requirements-08-library.org index b0eb219..7cc6b2d 100644 --- a/agora/docs/agora-requirements-08-library.org +++ b/ideas/agora/agora-requirements-08-library.org @@ -5,6 +5,10 @@ #+ID: agora-requirements-07-library #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: df02cddc-944a-4bcd-8ef5-f080870d5f49 +:END: * Library ** Concept @@ -39,7 +43,7 @@ The Library consists of three core components: - Full-text search across documents, subtitles, metadata - Tag-based organization (genre, year, creator, etc.) - Content deduplication via CID comparison -- Integration with Agora's discovery layer for shared content +- Integration with [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]'s discovery layer for shared content *** Library Managers diff --git a/agora/docs/agora-requirements-09-implementation.org b/ideas/agora/agora-requirements-09-implementation.org similarity index 97% rename from agora/docs/agora-requirements-09-implementation.org rename to ideas/agora/agora-requirements-09-implementation.org index 139aa97..b177867 100644 --- a/agora/docs/agora-requirements-09-implementation.org +++ b/ideas/agora/agora-requirements-09-implementation.org @@ -5,11 +5,15 @@ #+ID: agora-requirements-08-implementation #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d +:END: * Implementation ** Client Architecture -Sovereign iOS/Android clients with hardware-backed security and offline-first design. +Sovereign iOS/Android clients with [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]-backed security and offline-first design. *** Requirements @@ -66,7 +70,7 @@ The client MUST be capable of handling asynchronous events pushed from the Gover *** Protocol-First Design -Agora is a set of open protocols, not a single API service. Developers build against the *Agora Specification (v1.0)*, which defines the core data formats and transport methods. +[[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] is a set of open protocols, not a single API service. Developers build against the *Agora Specification (v1.0)*, which defines the core data formats and transport methods. *** Core Protocol Versioning @@ -141,7 +145,7 @@ Agora's decentralized and sovereign nature requires a multi-layered testing stra *** Agora-to-Web Gateways -See [[file:agora-requirements-03-infrastructure.org][Infrastructure - Agora-to-Web Gateways]] for detailed requirements. Implementation notes: +See [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure - Agora-to-Web Gateways]] for detailed requirements. Implementation notes: - Clients SHOULD provide links to Gateway-rendered versions of public content for sharing with non-Agora users. - Clients MAY embed Gateway content in web views for hybrid experiences. diff --git a/agora/docs/agora-requirements-10-governance-and-assets.org b/ideas/agora/agora-requirements-10-governance-and-assets.org similarity index 95% rename from agora/docs/agora-requirements-10-governance-and-assets.org rename to ideas/agora/agora-requirements-10-governance-and-assets.org index da0ed98..01d711e 100644 --- a/agora/docs/agora-requirements-10-governance-and-assets.org +++ b/ideas/agora/agora-requirements-10-governance-and-assets.org @@ -4,11 +4,15 @@ #+ID: agora-requirements-10-governance #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 68ffa49f-f0d8-42cf-8b69-ae69de8bb815 +:END: * Governance and Physical Assets ** Overview -This section expands Agora's capabilities beyond digital communication and into physical reality and organizational coordination. By integrating Physical Asset Linking (PAL) and the Governance Executable Module (GEM), Agora empowers Collectives to manage real-world resources and execute democratic decisions autonomously via smart contracts. +This section expands [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]'s capabilities beyond digital communication and into physical reality and organizational coordination. By integrating Physical Asset Linking (PAL) and the Governance Executable Module (GEM), Agora empowers Collectives to manage real-world resources and execute democratic decisions autonomously via smart contracts. ** Governance Executable Module (GEM) diff --git a/agora/docs/agora-requirements-10-user-journey.org b/ideas/agora/agora-requirements-10-user-journey.org similarity index 83% rename from agora/docs/agora-requirements-10-user-journey.org rename to ideas/agora/agora-requirements-10-user-journey.org index 7d6fd54..764121f 100644 --- a/agora/docs/agora-requirements-10-user-journey.org +++ b/ideas/agora/agora-requirements-10-user-journey.org @@ -2,9 +2,13 @@ #+AUTHOR: Project Agora #+DATE: 2026-03-26 +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 2cace571-76bb-4c34-a5f4-68bc20b2e884 +:END: * The Sovereign User Journey -This document outlines the cohesive, narrative user journey of the Agora platform, illustrating how the underlying technical primitives (Master Keys, DIDs, PDS, Lightning, and Smart Contracts) translate into a seamless product experience. +This document outlines the cohesive, narrative user journey of the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] platform, illustrating how the underlying technical primitives (Master Keys, DIDs, PDS, Lightning, and Smart Contracts) translate into a seamless product experience. ** Phase 1: Onboarding (The Birth of the Persona) @@ -28,6 +32,6 @@ This document outlines the cohesive, narrative user journey of the Agora platfor - *The Delivery:* User B delivers the chair. User A scans a QR code physically attached to the chair, which acts as the cryptographic release of the Preimage, instantly settling the smart contract and paying User B. * Related Documents -- [[file:agora-requirements-02-identity.org][02 Identity (Master Keys & Personas)]] -- [[file:agora-requirements-03-infrastructure.org][03 Infrastructure (PDS & WebRTC Seeding)]] -- [[file:agora-requirements-06-exchange-and-contracts.org][06 Exchange & Contracts (HODL Escrows & Arbitration)]] \ No newline at end of file +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02 Identity (Master Keys & Personas)]] +- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03 Infrastructure (PDS & WebRTC Seeding)]] +- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06 Exchange & Contracts (HODL Escrows & Arbitration)]] \ No newline at end of file diff --git a/agora/docs/agora-requirements-11-assessment.org b/ideas/agora/agora-requirements-11-assessment.org similarity index 84% rename from agora/docs/agora-requirements-11-assessment.org rename to ideas/agora/agora-requirements-11-assessment.org index 4ec2fe2..3df5a4f 100644 --- a/agora/docs/agora-requirements-11-assessment.org +++ b/ideas/agora/agora-requirements-11-assessment.org @@ -5,16 +5,20 @@ #+ID: agora-requirements-10-assessment #+STARTUP: content +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 72570648-d943-42e5-a781-3b09791ac6ec +:END: * Realistic Assessment: Practicality, Technology, and Performance -The Agora Protocol, following the integration of the Aletheia architecture, represents a significant leap beyond simple social networking into a comprehensive "Sovereign Social Operating System." This assessment evaluates the protocol's viability across three critical pillars. +The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] Protocol, following the integration of the Aletheia architecture, represents a significant leap beyond simple social networking into a comprehensive "Sovereign Social Operating System." This assessment evaluates the protocol's viability across three critical pillars. ** 1. Practicality: The Sovereignty vs. UX Trade-off Agora's practicality hinges on whether users can manage its cryptographic complexity without constant friction. *** Strengths -- *Functional Autonomy:* The "Sub-Root" HD derivation path (`m/44'/1'/account'/persona'/key_purpose/key_index`) is a major practical win. By allowing devices to derive operational keys (Lightning, PGP) autonomously, Agora reduces the "Hardware Wallet Fatigue" that plagues self-sovereign systems. +- *Functional Autonomy:* The "Sub-Root" HD derivation path (`m/44'/1'/account'/persona'/key_purpose/key_index`) is a major practical win. By allowing devices to derive operational keys (Lightning, PGP) autonomously, Agora reduces the "[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] Wallet Fatigue" that plagues self-sovereign systems. - *Unified Logic:* The "Everything is a Note" model simplifies the backend infrastructure (PDS/Relays), as they only need to handle a single data structure regardless of whether it's a social post or a legal contract. *** Challenges @@ -28,7 +32,7 @@ The technical stack is grounded in industry-standard primitives used in Bitcoin *** Technological Pillars - *Identity:* Leveraging BIP-44 and Ed25519 provides a battle-tested foundation for unlinkable personas. - *Privacy:* The combination of E2EE (Double Ratchet/MLS), Blinded Sharding, and Zero-Knowledge Proofs (ZKPs) for cross-persona Notes places Agora at the forefront of privacy-preserving social protocols. -- *Commerce:* Integrating LSATs and HODL invoices directly into the content layer (SCAL) is technically sound but relies heavily on the continued growth and stability of the Lightning Network. +- *Commerce:* Integrating LSATs and HODL invoices directly into the content layer (SCAL) is technically sound but relies heavily on the continued [[id:26f3e845-5eb4-4bcd-9cff-28e219934841][growth]] and stability of the Lightning Network. *** Critical Risks - *ZKP Complexity:* Implementing efficient ZKPs for identity linking that run on mobile hardware is technically non-trivial and may require specialized libraries or "Prover" sub-agents. @@ -67,6 +71,6 @@ Agora is technically viable but architecturally demanding. It is not a project t ** Related Documents -- [[file:agora-requirements-01-overview.org][01: Overview]] -- [[file:agora-requirements-02-identity.org][02: Identity]] -- [[file:agora-requirements-09-implementation.org][09: Implementation]] +- [[id:b25bf753-9799-41ab-82f5-1a1416db756b][01: Overview]] +- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]] +- [[id:8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d][09: Implementation]] diff --git a/ideas/ai-industry-impact.org b/ideas/ai-industry-impact.org index 3b36c01..ebfa31d 100644 --- a/ideas/ai-industry-impact.org +++ b/ideas/ai-industry-impact.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542 :END: #+title: Impact on the AI and GPU Industry @@ -6,10 +7,10 @@ If a symbolic-bootstrapping architecture becomes popular, the industry structure shifts fundamentally: -**Token demand compresses.** The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is built on per-token pricing. A mature Passepartout reduces token consumption to the unfamiliar 10% I/O boundary. Steady-state per-user LLM consumption drops by an order of magnitude. +**Token demand compresses.** The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is built on per-token pricing. A mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] reduces token consumption to the unfamiliar 10% I/O boundary. Steady-state per-user LLM consumption drops by an order of magnitude. **GPU inference demand plateaus in regulated industries.** Inference demand drops 80-90% in any sector where the rule book is published — which covers most economically significant sectors (finance, healthcare, industrial, government procurement, legal compliance). Nvidia's growth narrative shifts from "every transaction goes through a GPU" to "every training run needs a GPU." **Hyperscaler competition shifts.** The race shifts from "who has the most H100s" to "who has the best domain-specific gate rules." Google's industry data advantage matters more than Azure's raw compute. -**New hardware tier emerges:** CPU-native [[file:self-driving-lisp-machine.org][verification appliances running Lisp microcode]] on RISC-V cores. Low volume (hundreds of thousands/year), high margin ($5K-50K/unit). Manufacturable at older fab nodes (28nm, 45nm) — no dependency on TSMC's leading edge. This hardware embodies [[file:lisp-economics.org][Lisp economics]] — the cost of verification approaches zero once the symbolic engine is running on dedicated silicon. The outcome is a [[file:verification-monopoly.org][verification monopoly]] for agent safety — the same certification dynamic UL provides for electrical safety. +**New hardware tier emerges:** CPU-native [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][verification appliances running Lisp microcode]] on RISC-V cores. Low volume (hundreds of thousands/year), high margin ($5K-50K/unit). Manufacturable at older fab nodes (28nm, 45nm) — no dependency on TSMC's leading edge. This hardware embodies [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of verification approaches zero once the symbolic engine is running on dedicated silicon. The outcome is a [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] for agent safety — the same certification dynamic UL provides for electrical safety. diff --git a/ideas/alternative-growth-social-first.org b/ideas/alternative-growth-social-first.org index 1576b17..ac2f3a9 100644 --- a/ideas/alternative-growth-social-first.org +++ b/ideas/alternative-growth-social-first.org @@ -1,15 +1,16 @@ :PROPERTIES: +:ID: 57f9538a-6270-4302-8d07-d742168419eb :ID: alternative-growth-social-first :CREATED: [2026-05-23 Sat] :END: #+title: Alternative Growth — Social-First Scenario #+filetags: :passepartout:growth:strategy:alternative: -The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. The triad components (Logos, [[file:stoa.org][Stoa]], [[file:agora.org][Agora]]) are the same; the order of operations and the primary growth levers differ fundamentally. +The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. The triad components (Logos, [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]], [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]) are the same; the order of operations and the primary growth levers differ fundamentally. * Why This Path Exists -The institution-first scenario ([[file:growth-strategy.org][growth strategy]]) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But the triad ships with a second product that has nothing to do with verification: the Agora, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The Agora replaces all four with one provable layer. +The institution-first scenario ([[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth strategy]]) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But the triad ships with a second product that has nothing to do with verification: the Agora, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The Agora replaces all four with one provable layer. The social-first scenario leans into what the Agora is /as a product/, not what the triad is /as a technology/. Publishing, payments, contracts, and identity are all mass-market primitives. They can grow without ever mentioning ACL2, gate rules, or compliance. Verification is the infrastructure underneath, invisible to users until they need it. @@ -31,7 +32,7 @@ Growth lever: Multi-vector network effects. The Agora grows not on a single curv 1. Publishing: each new creator attracts readers, who may become creators 2. Payments: each new payment user creates liquidity that makes the network more useful for everyone 3. Contracts: each new contract written on the Agora creates a template and a precedent -4. PDS: each new PDS increases the federation surface and the [[file:compute-marketplace.org][compute marketplace]] supply +4. PDS: each new PDS increases the federation surface and the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] supply Any of these can be the primary growth vector in a given market. If publishing stalls in one region, payments might take off. This redundancy dramatically increases the probability that /some/ vector finds PMF. @@ -45,7 +46,7 @@ Tactics: 4. /PDS hosting as infrastructure./ The PDS is the backbone, not the headline. Freemium model: first 1GB free, $5-15/mo for unlimited. The PDS stores your identity, content, contracts, and payment history in one place. The value prop: /one account, one data store, one reputation, everywhere/. -5. /Fee-based revenue./ The Agora takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data [[file:licensing.org][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow. +5. /Fee-based revenue./ The Agora takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow. Revenue: | Stream | Year 1 target | Mature | @@ -134,7 +135,7 @@ Customer: At this scale, the Agora is the default identity and communication lay Growth lever: Default status. The network is the path of least resistance. A new social platform would need to replicate not just the user base but the entire attestation history, compute marketplace, and institutional infrastructure. The moat is not legal (regulation) but practical (installed base + cumulative value). -Tactics: Similar end state to the institution-first scenario — [[file:verification-monopoly.org][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat: +Tactics: Similar end state to the institution-first scenario — [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat: - Institution-first moat: regulatory lock-in. You comply because the law requires it. - Social-first moat: installed-base lock-in. You join because everyone is there. @@ -172,7 +173,7 @@ The multi-vector growth also matters. The institution-first path has one entry v The fee-based revenue model further improves Phase 0 economics. Payment processing fees scale with transaction volume, not user count. A small number of high-value users (freelancers sending invoices, creators selling subscriptions) can generate meaningful revenue before the network reaches critical mass. -However: the core tension remains. The team building the triad is a deep-tech verification team — their competence is ACL2, gate rules, provably correct systems. The social-first path requires the team to also be a consumer product team — UX design, growth loops, community management, creator partnerships, payment infrastructure, fraud detection. That is not /impossible/ (the team can hire) but it is a different company than the one building Passepartout. +However: the core tension remains. The team building the triad is a deep-tech verification team — their competence is ACL2, gate rules, provably correct systems. The social-first path requires the team to also be a consumer product team — UX design, growth loops, community management, creator partnerships, payment infrastructure, fraud detection. That is not /impossible/ (the team can hire) but it is a different company than the one building [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]. The institution-first path monetizes the team's /existing/ competence from day one. The social-first path requires building a second competence (consumer platform) that does not exist yet. This is the real distinction, not the product's inherent potential. @@ -182,12 +183,12 @@ The hybrid path may be the strongest: ship the four-layer Agora as a public plat * References -- [[file:growth-strategy.org][Primary growth strategy — institution-first]] -- [[file:revenue-hub.org][Revenue streams by component]] -- [[file:agora-contracts.org][Agora contract platform details]] -- [[file:effects-growth-flywheel.org][Effects and growth as interleaved curves]] -- [[file:time-estimates.org][Development timeline — Phase Zero and End State]] +- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Primary growth strategy — institution-first]] +- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams by component]] +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform details]] +- [[id:528a0f6c-6fd6-41ed-9d59-237958bdaef2][Effects and growth as interleaved curves]] +- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline — Phase Zero and End State]] #+begin_quote -The social-first path is attractive because the end state is stronger. But the path to it requires building a consumer product alongside the deep-tech verification infrastructure — essentially running two startups in parallel. The institution-first path is the higher-probability bet because it monetizes the core technical advantage from day one. +The social-first path is attractive because the end state is stronger. But the path to it requires building a consumer product alongside the deep-tech verification infrastructure — essentially running two startups in parallel. The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Agora Social Space requirements]] describe the community interaction model that makes the social-first path viable.. The institution-first path is the higher-probability bet because it monetizes the core technical advantage from day one. #+end_quote diff --git a/ideas/asset-protection-structures.org b/ideas/asset-protection-structures.org index b07774f..2806d0c 100644 --- a/ideas/asset-protection-structures.org +++ b/ideas/asset-protection-structures.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 0a4e0b8f-25e0-4b78-9633-fc37d03cefe9 :ID: asset-protection-structures :CREATED: [2026-05-23 Sat] :END: @@ -11,11 +12,11 @@ Research on corporate structures for a US-incorporated tech company with offshor The triad has three distinct asset classes, each with different protection needs: -1. /IP (Logos):/ Passepartout codebase, gate rules, ACL2 proof libraries, the [[file:verification-monopoly.org][verification monopoly]]. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable. +1. /IP (Logos):/ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] codebase, gate rules, ACL2 proof libraries, the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]]. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable. -2. /Platform ([[file:agora.org][Agora]]):/ The network itself — user base, reputation graph, contract history, protocol specification. This is harder to value and harder to protect because its value is partly in the user base. But the code, protocol spec, and network infrastructure can be owned separately. +2. /Platform ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]):/ The network itself — user base, reputation graph, contract history, protocol specification. This is harder to value and harder to protect because its value is partly in the user base. But the code, protocol spec, and network infrastructure can be owned separately. -3. /Revenue streams:/ Enterprise compliance contracts, transaction fees, PDS hosting subscriptions. These flow through the operating company. A judgment against the operating company attaches to the revenue in that entity. +3. /[[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]:/ Enterprise compliance contracts, transaction fees, PDS hosting subscriptions. These flow through the operating company. A judgment against the operating company attaches to the revenue in that entity. * Common Structures @@ -35,7 +36,7 @@ Assessment: Fine for Phase 0. Upgrade when revenue exceeds liability risk tolera - Delaware C-Corp is the operating company (sells verification, runs the Agora PDS infrastructure) - A separate IP holding company in BVI, Cayman, or Nevis owns the Passepartout code, gate rules, ACL2 libraries, and the Agora protocol spec - The operating company licenses the IP from the holding company at arm's-length royalty rates -- The holding company accumulates IP [[file:licensing.org][licensing]] revenue in the offshore jurisdiction +- The holding company accumulates IP [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] revenue in the offshore jurisdiction Pros: Strong IP protection — a judgment against the operating company cannot reach the IP (the operating company doesn't own it). Profits from licensing are outside US tax jurisdiction until repatriated. Cons: US tax reform (TCJA 2017) introduced GILTI (Global Intangible Low-Taxed Income) — this structure is less tax-effective than pre-2017. Transfer pricing documentation required. Increases administrative complexity. @@ -52,7 +53,7 @@ Cons: Complex, expensive to set up and maintain. Many investors are uncomfortabl ** Structure D: Delaware C-Corp + Delaware LLC Series + Offshore - Delaware C-Corp as parent -- Each business line (Logos verification, Agora network, [[file:compute-marketplace.org][compute marketplace]], PDS hosting) is a separate Delaware series LLC +- Each business line (Logos verification, Agora network, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], PDS hosting) is a separate Delaware series LLC - IP held in an offshore company, licensed to each series LLC - Series LLCs protect assets within each series from liabilities arising in other series @@ -63,7 +64,7 @@ Cons: Series LLC is legally untested in many jurisdictions. Some states don't re ** The IP is the crown jewel -The verification monopoly /is/ the moat. The ACL2 proof libraries, gate rule library, and regression suite are accumulated over years and cannot be recreated quickly. These must be owned by a separate entity from the operating company. If the operating company is sued, the IP survives. +[[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] /is/ the moat. The ACL2 proof libraries, gate rule library, and regression suite are accumulated over years and cannot be recreated quickly. These must be owned by a separate entity from the operating company. If the operating company is sued, the IP survives. ** The Agora network is harder to protect** @@ -118,7 +119,7 @@ If the Agora has 100K+ users and payment volume, separate the business lines int When the cumulative value justifies the cost and complexity: move the BVI IP Co ownership into an irrevocable offshore trust with the founders as beneficiaries. -* What This Means for the Growth Strategy +* What This Means for the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth Strategy]] The institution-first path (enterprise compliance) and the social-first path (Agora communities) have /different liability profiles/ that push toward different structures: @@ -132,7 +133,7 @@ The combined strategy (both engines) makes the Phase 1 structure (Delaware OpCo This is preliminary research. Specific recommendations require a US corporate lawyer (incorporation), an international tax lawyer (offshore structure), and an asset protection specialist (trust/AP structure). The right order: incorporate in Delaware when ready, then hire a lawyer to plan the offshore structure before significant revenue or users accumulate. -- [[file:growth-strategy.org][Combined growth strategy]] -- [[file:competitive-landscape-agora.org][Agora competitive landscape]] -- [[file:agora-entry-strategy.org][Entry strategy — organized communities]] -- [[file:outbound-sales-compliance.org][Outbound sales compliance framework]] +- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]] +- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]] +- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]] +- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]] diff --git a/ideas/biology-parallels.org b/ideas/biology-parallels.org index f45c157..894f1b1 100644 --- a/ideas/biology-parallels.org +++ b/ideas/biology-parallels.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 2afd9a3c-e96a-54c7-ac77-a05a28065b4b :END: #+title: Biology as Proof of the Lisp Model @@ -14,4 +15,4 @@ Striking parallels between microbiology and the Lisp model: 6. **Duck typing** — protein folding depends on chemical environment, not type declarations 7. **Concurrent real-time GC** — apoptosis breaks down cell components for recycling by neighboring cells -Biology chose the Lisp model because it is more robust, adaptable, and evolvable. Evolution optimized for survival in an unpredictable environment, not peak single-thread throughput. Biology is the proof that the Lisp model can be efficient at planetary scale, running on hardware that self-assembles from food. See [[file:lisp-economics.org][Lisp economics]] for how these biological parallels inform the business model. +Biology chose the Lisp model because it is more robust, adaptable, and evolvable. Evolution optimized for survival in an unpredictable environment, not peak single-thread throughput. Biology is the proof that the Lisp model can be efficient at planetary scale, running on hardware that self-assembles from food. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] for how these biological parallels inform the business model. diff --git a/ideas/collective-regression-suite.org b/ideas/collective-regression-suite.org index 0b798f9..01ee441 100644 --- a/ideas/collective-regression-suite.org +++ b/ideas/collective-regression-suite.org @@ -1,18 +1,19 @@ :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 [[file:evaluation-harness.org][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. +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 [[file:agora.org][Agora]] as the substrate for distribution and contribution. +This specification describes how the collective regression suite is built, maintained, and used, with [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] 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 [[file:compliance/hipaa.org][HIPAA]] deployment in one hospital discovers an edge case that a [[file:compliance/soc2.org][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. +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 [[file:verification-monopoly.org][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. +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** @@ -87,7 +88,7 @@ Each .regression file is a compressed, sorted list of test cases. The manifest i **Who can submit** -Any Passepartout instance with an Agora DID can submit test cases. But not all submissions are treated equally. The suite maintains a three-tier system: +Any [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instance with an Agora DID can submit test cases. But not all submissions are treated equally. The suite maintains a three-tier system: Tier 1 — Verified. Human-reviewed by the suite operator. Used in certification scoring. An instance that passes Tier 1 earns the standard certification badge. @@ -123,7 +124,7 @@ Assume each deployed instance generates on average one new unique test case per - 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 [[file:moats.org][moats]] — the data network effect is inherently accumulated over time and cannot be bought. +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** @@ -143,4 +144,4 @@ Instance runs → human corrects a gate decision → new test case is abstracted Every component of this loop exists or is on Passepartout's roadmap except the Agora Note publishing channel. The gate stack generates the raw signal. The abstraction pass strips instance details. The local triage de-duplicates. The Agora DID provides authentication. The Merkle root provides integrity. The certification badge provides monetization. -Nothing in this loop requires new core Passepartout functionality. It requires the Agora protocol for inter-instance communication and a server-side aggregation process. Both are roadmap items, but neither depends on the self-driving Lisp Machine. The suite itself is the [[file:infrastructure-lock-in.org][infrastructure lock-in]] — once an enterprise has certified against it, switching to a competitor means rebuilding their compliance from scratch. +Nothing in this loop requires new core Passepartout functionality. It requires the Agora protocol for inter-instance communication and a server-side aggregation process. Both are roadmap items, but neither depends on [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][the self-driving Lisp Machine]]. The suite itself is the [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] — once an enterprise has certified against it, switching to a competitor means rebuilding their compliance from scratch. diff --git a/ideas/common-logic-iso-24707.org b/ideas/common-logic-iso-24707.org index 0eae456..3da6bf6 100644 --- a/ideas/common-logic-iso-24707.org +++ b/ideas/common-logic-iso-24707.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 04c2f221-c54f-51e5-b40a-48822cd16d45 :END: #+title: Common Logic (ISO 24707) — Relevance to Passepartout @@ -8,13 +9,13 @@ Common Logic (ISO/IEC 24707) is a framework for first-order logic languages desi Three standard dialects: CLIF (Common Logic Interchange Format), CGIF (Conceptual Graph Interchange Format), XCL (XML-based). Additionally, RDF and OWL can be mapped to CL, making them interoperable with any CL dialect. -**Relevance to Passepartout** +**Relevance to [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]** -The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances ([[file:agora.org][Agora]] sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[file:gate-rule-encoding.org][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas. +The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas. The dialect architecture mirrors Passepartout. CL's defining insight: define abstract semantics, let any concrete syntax map to it, get interoperability for free. This is the exact same pattern as Passepartout's "one gate stack, many skills" — the gate stack defines the security ontology (abstract semantics), and skills (dialects) map their operations to it. CL's approach validates Passepartout's design choice and provides a theoretical framework for it. -ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for [[file:compliance/hipaa.org][HIPAA]], SOC2, [[file:compliance/fedramp.org][FedRAMP]], and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires. +ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]], [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]], [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]], and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires. The RDF/OWL bridge. CL has defined translations to RDF and OWL. This means Passepartout can consume knowledge from the semantic web without building a separate RDF parser. The fact store stays in plists internally; CL is the serialization and interchange layer. Any enterprise knowledge graph expressed in OWL can be ingested as CLIF, translated to plists, and verified by ACL2. @@ -43,4 +44,4 @@ Common Logic is relevant not as something to implement or replace, but as: 4. A bridge to RDF/OWL data sources 5. A cautionary example for the CIC prover design (careful about higher-order scope) -The right time to integrate it: when Agora Notes need a standard knowledge interchange format for inter-instance communication. Before that, it is a reference worth reading but not implementing. The CL approach informs the [[file:sufficiency-flip.org][sufficiency flip]] strategy and the [[file:cost-structure.org][cost structure]] of encoding domain knowledge. +The right time to integrate it: when Agora Notes need a standard knowledge interchange format for inter-instance communication. Before that, it is a reference worth reading but not implementing. The CL approach informs the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] strategy and the [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] of encoding domain knowledge. diff --git a/ideas/comparison-with-symbolics.org b/ideas/comparison-with-symbolics.org index ff5de46..dc1aca8 100644 --- a/ideas/comparison-with-symbolics.org +++ b/ideas/comparison-with-symbolics.org @@ -1,10 +1,11 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 00ab3a4d-e3de-5605-a67d-12935bb36ab5 :END: #+title: Comparison with Symbolics Genera #+filetags: :passepartout:history:symbolics:comparison: -| | Symbolics Genera (1980s) | Passepartout (2020s) | +| | Symbolics Genera (1980s) | [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] (2020s) | |---|---|---| | Lines | ~1,000,000 | ~21,000 (self-driving target) | | Developer-years | ~10 years, large team | ~1 year, 1-3 devs | @@ -13,4 +14,4 @@ | Market | $50K-$100K/seat | $5K-$50K/appliance | | Scope | Full OS + environment | Cognitive agent + hardware acceleration | -The Symbolics comparison is instructive: they built a full Lisp OS from scratch. Passepartout runs on Linux, providing the OS layer for free. The hardware integration is a PCIe card, not a replacement of the entire host. The scope is dramatically smaller — ~2% of the code for a fraction of the functionality that matters most. This illustrates the fundamental principles of [[file:lisp-economics.org][Lisp economics]] — the cost of building a Lisp-based system has dropped by orders of magnitude since the 1980s. The [[file:self-driving-lisp-machine.org][Self-driving Lisp Machine]] is the modern analogue: a hardware accelerator rather than a complete computer. +The Symbolics comparison is instructive: they built a full Lisp OS from scratch. Passepartout runs on Linux, providing the OS layer for free. The hardware integration is a PCIe card, not a replacement of the entire host. The scope is dramatically smaller — ~2% of the code for a fraction of the functionality that matters most. This illustrates the fundamental principles of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of building a Lisp-based system has dropped by [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders of magnitude]] since the 1980s. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Self-driving Lisp Machine]] is the modern analogue: a hardware accelerator rather than a complete computer. diff --git a/ideas/competitive-analysis-2026-05.org b/ideas/competitive-analysis-2026-05.org deleted file mode 100644 index 72f483e..0000000 --- a/ideas/competitive-analysis-2026-05.org +++ /dev/null @@ -1,463 +0,0 @@ -:PROPERTIES: -:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1 -:CREATED: [2026-05-22 Thu] -:END: -#+title: Competitive Analysis — AI Agent Landscape (May 2026) -#+filetags: :passepartout:strategy:competitive: - -* Overview - -Analyzed 9 competitor codebases alongside Passepartout. The competitive landscape -divides into three categories: - -1. Coding agents (Aider, OpenCode, Codex CLI, Claude Code, Gemini CLI) -2. Personal AI assistants (Hermes, OpenClaw, Thoth) -3. CI/check-based systems (Continue) - -None of the nine compete with Passepartout on all axes simultaneously. Passepartout's -strongest differentiators — Org-mode data model, deterministic gate stack, ACL2 -verification, Merkle-treed memory, and the triad architecture — are absent from -every competitor. - -* Category 1: Coding Agents - -** Aider (Python, ~40K lines, MIT) - -Language: Python. ~6.8M pip installs. The oldest and most mature open-source -coding agent. - -Architecture: Chat-based Coder class with 5 edit formats (diff, udiff, patch, -whole, architect). Uses litellm for universal provider access (50+ providers). -RepoMap provides codebase awareness via cosine-similarity embedding. - -Safety model: Purely prompt-based plus user-confirmation dialogs. No deterministic -gate stack. No sandboxing. No model output validator. The allowed_to_edit() gate -is a single user confirmation call. --yes flag auto-approves. Aider can edit its -own source code with no special protection — self-modification is undetectable. - -Data model: Ad-hoc. Chat messages in memory. Git commits for persistence. RepoMap -is a cosine-similarity index. No persistent memory across sessions. No knowledge -graph. - -Self-modification: Full. No guard against editing its own files. - -Verification: None. - -Key gap vs Passepartout: No safety gates, no persistent memory model, no knowledge -representation, no verification, no self-modification protection, no architecture -for neurosymbolic reasoning. It is a thin shell around litellm + edit format -parsers. - -** OpenCode (TypeScript/Bun, anomalyco/opencode, 163K★) - -The dominant open-source coding agent by adoption. Bun runtime, Effect-TS -functional core, Solid.js TUI, Turborepo monorepo. - -Architecture: Dual LLM runtime — default AI SDK (streamText/generateText) + -opt-in native Effect-Schema runtime (@opencode-ai/llm) with 4-axis route -decomposition (Protocol/Endpoint/Auth/Framing). 30+ provider plugins. -Agent workflow DSL with plan/build agent switching. Agent Communication -Protocol (ACP) for inter-agent messaging. Subagents inherit permission -boundaries from parent. 18+ built-in tools + custom tools from config. -Effect-TS ScopedCache per-project state management. - -Safety model: Explicitly documentes /not/ sandboxing the agent. The -permission system is rule-based (glob matching, actions: allow/ask/deny) -and exists as a UX feature, not security isolation. Built-in agents have -carefully scoped defaults (build allows most, prompts on doom_loop; -plan denies all edits except plan files; explore denies everything except -grep/glob/bash/webfetch/read; question defaults to deny). Permission -rules are inherited by subagents. Shell tool dynamically scans commands -for filesystem-impacting operations to determine ask patterns. - -Data model: SQLite via Drizzle ORM with bun:sqlite or better-sqlite3. -Key tables: SessionTable (project, workspace, parent hierarchy, cost, -tokens, model JSON, agent config JSON, permission JSON, revert snapshot), -MessageTable, PartTable. Project model stores worktree, VCS, sandbox -config. Config is JSON-chain (user home → project root → worktree) with -remote config fetch and mergeDeep with concatenating array semantics. -20 config modules covering agents, permissions, providers, MCP, LSP, -plugins, skills, references, variable. - -Self-modification: Agent.generate() interface lets the LLM create new -agent definitions — the system grows its own subagent roster. Skills -system loads domain-specific knowledge packs dynamically. - -Verification: None. - -Key gap vs Passepartout: No deterministic safety architecture, no -knowledge graph, no Org-mode, no verification/proof system, no -neurosymbolic architecture. The permission system is explicitly labeled -\"not security isolation\" — it's UX, not a gate stack. Largest userbase -and most polished product of any coding agent, but architecturally -conventional. - -** Codex CLI (OpenAI, Rust, ~950K lines) - -OpenAI's open-source coding agent. Rust, Sandboxed. - -Architecture: ~116 crate Rust workspace with a protocol layer (SQ/EQ session types), -sandbox manager (macOS Seatbelt, Linux nsjail), multi-provider support (via defined -protocol, not directly), configurable TUI. - -Safety model: Most sophisticated safety system of any coding agent analyzed. -Multi-layer: -- Process hardening (macOS Seatbelt with 4 profile tiers) -- Execution policy engine (defined policy in execpolicy crate) -- Sandboxing via nsjail on Linux, seatbelt on macOS -- Guardian module for tool permission gating -- No prompt-based safety — all deterministic through policy definitions - -Data model: Protocol-defined session types. Structured request/response models. -Config through TOML files with schema validation. - -Self-modification: Protected by sandbox — the agent cannot escape to modify its -own binary or config without explicit policy override. - -Verification: None (no proof system). - -Key gap vs Passepartout: No knowledge graph (Org or otherwise), no persistent -memory model, no deterministic gate stack for agent behavior (only OS-level -sandboxing), no ACL2/prover, no neurosymbolic architecture. Strongest sandbox -but weakest cognitive architecture. - -** Claude Code (Anthropic, TypeScript/Bun, ~512K lines leaked) - -Anthropic's proprietary coding agent. Only available via leaked source analysis. -Not open source. - -Architecture: Bun-bundled TypeScript single-file executable. Ink/React terminal UI. -23+ core tools. Subagent forking with byte-identical API prefixes for prompt cache -sharing. Multi-agent coordination mode. - -Safety model: Layered deterministic safety — NOT prompt-based: -1. Permission mode system (7 modes: default, acceptEdits, bypassPermissions, etc.) -2. Persistent permission rules (alwaysAllow, alwaysDeny, alwaysAsk, rule sources - from userSettings, projectSettings, localSettings, policySettings) -3. Bash security validator — 2,592 lines of dedicated code with 23+ named - security checks using tree-sitter AST parsing -4. Sandbox runtime for filesystem/network containment -5. Path/mode validation -6. Optional ML bash classifier (ant-only feature) - -This is the most sophisticated safety system of any coding agent. Passepartout's -gate stack is architecturally similar (deterministic multi-layer) but Claude -Code's implementation is vastly more mature — 2,592 lines of bash validation -alone is ~50x the equivalent in Passepartout. - -Data model: File-based markdown memdir at ~/.claude/projects//memory/. -4 memory types: user, feedback, project, reference. YAML frontmatter in .md files. -PROJECT.md and CLAUDE.md for project-level config. No database. - -Self-modification: HIGH. Skill system writes SKILL.md files that change future -behavior. Plugin system, cron scheduling, agent spawning. - -Verification: None. - -Key gap vs Passepartout: No proof system, no neurosymbolic architecture, no -self-verification, no persistent knowledge graph (flat markdown files, not -Org-mode with cross-references), markdown data model lacks semantic depth. -Proprietary — Anthropic controls it completely. Linux-only (uses macOS sandbox -profiles natively). The permission rules system is impressive but structurally -inferior to Passepartout's gate stack because rules are heuristic (regex-based -pattern matching) rather than typed (type-level gates with structural guarantees). - -** Gemini CLI (Google, TypeScript, ~525K lines, Apache 2.0) - -Google's open-source coding agent. Node.js 20+, Ink/React TUI. - -Architecture: 7-package npm monorepo. Core backend handles Gemini API orchestration, -tool execution, policy engine, safety checks, sandbox management, session management, -MCP client. 7-strategy composite model routing chain. - -Safety model: Multi-layered: -1. CONSECA (Contextual Security Checker) — AI-driven per-request policy generation - using a separate Gemini Flash model. Principle of least privilege. -2. Policy engine — 4 approval modes (PLAN, DEFAULT, AUTO_EDIT, YOLO), hierarchical - rules with priority scores and wildcard matching -3. 6 sandbox methods (macOS Seatbelt, Docker/Podman, bwrap, gVisor, LXC, Windows) -4. Trusted folders with discovery phase and path traversal protection -5. Policy integrity verification via cryptographic hashes -6. Built-in safety checkers (AllowedPathChecker, CONSECA) -7. Loop detection service - -Data model: JSONL session files. Turn-based conversation model. 4-layer config -precedence (system-defaults → user → project → system-override). TOML policy files. - -Self-modification: Modifiable hooks system, MCP extensions, custom commands. -Core binaries are protected on disk by file permissions. - -Verification: None. - -Key gap vs Passepartout: No proof system, no persistent knowledge graph, no -self-verification, no neurosymbolic architecture, lock-in to Google Gemini models -(though it can use others via routing). The CONSECA approach is interesting -(AI-generated policies) but introduces a second LLM call for every security -decision — the opposite of Passepartout's approach of zero-token deterministic gating. - -* Category 2: Personal AI Assistants - -** Hermes Agent (Python, ~17K core, MIT) - -The agent running this conversation. Python, OpenAI-format conversations. - -Architecture: Synchronous conversation loop with OpenAI-format messages. 60+ -built-in tools. 109+ providers via pluggable transport layer. 15+ messaging -platforms via gateway. MCP client (native, not bridge). Ink/React TUI as Node.js -subprocess. Cron jobs, Kanban board, subagent delegation. - -Safety model: Multi-layer but NOT a deterministic gate stack: -1. Message sanitization (surrogates, control chars, malformed JSON) -2. Tirith binary scanner (pre-execution terminal command analysis) -3. Command approval system (manual/smart/off modes) -4. Memory injection detection (prompt injection pattern matching) -5. Secret/PII redaction -6. Tool call guardrails (loop detection) -7. MCP security (env filtering, credential stripping) -8. Context fencing (memory injection span scrubbing) - -These are all heuristic or prompt-based — no structural type-level gates. -Tirith is a separate binary, not in-process. The approval system is good but -reactive (LLM proposes → system blocks) rather than preventive (type system -prevents by construction). - -Data model: SQLite session DB (FTS5 full-text search). File-based memory -(MEMORY.md + USER.md). YAML config. No knowledge graph. No Org-mode. - -Self-modification: Skill system writes SKILL.md files. Memory tool edits -MEMORY.md/USER.md. Config YAML editable. Core Python code is read-only in -execution but the LLM could request modifications to its own source files -(no gate specifically prevents this). - -Verification: None. - -Key gap vs Passepartout: No deterministic gate stack (heuristic layers, not -structural/typed), no knowledge graph, no Org-mode, no neurosymbolic architecture, -no self-verification, no proof system. Hermes's strength is breadth — -109 providers, 15 platforms, MCP ecosystem, big tool surface. But it has no -depth in safety, knowledge representation, or reasoning architecture. - -** OpenClaw (TypeScript/Node.js, ~3.5M lines) - -The largest codebase analyzed. Personal AI assistant with 25+ messaging channel -support. - -Architecture: pnpm workspace with ~135 bundled plugins. Gateway control plane -routes messages through multi-agent routing. Per-agent sessions, workspaces, -skill registries. Companion native apps (macOS, iOS, Android). - -Safety model: Tiered — main agent runs tools directly on host (trusted-operator), -non-main sessions sandboxed via Docker (read-only rootfs, capability dropping, -seccomp/AppArmor, memory/cpu/PID limits, SSH/OpenShell backends). - -Data model: Typed JSON/YAML config (openclaw.json). Multi-source model catalog. -Plugin SDK with narrow typed subpath exports. - -Self-modification: ACP (Agent Control Protocol) for spawning child sessions. -Skill system with npm distribution and ClawHub registry. - -Verification: None. - -Key gap vs Passepartout: Same as Hermes — no gate stack, no knowledge graph, -no Org-mode, no verification, no neurosymbolic architecture. Differentiated by -vastly broader channel support and mature plugin ecosystem. But architecturally -conventional — LLM + tools + channels, no cognitive architecture innovation. - -** Thoth (Python, ~151K lines, Apache 2.0) - -https://github.com/siddsachar/Thoth — Personal AI Sovereignty. Local-first -desktop AI assistant with knowledge graph, tools, voice, vision, shell, -browser automation, workflow engine, and messaging channels. - -Architecture: LangGraph create_react_agent (prebuilt ReAct pattern). Dual-mode -streaming via agent.stream(). NiceGUI web UI served by Python app.py with -desktop launcher (tray icon, Ollama auto-start, browser/OS window). Context -trimming via tiktoken to ~85% of model window, base64 data redaction, stale -browser snapshot compression (keeps last 8), MD5 tool result dedup, old tool -result summarization. 50-step recursion limit (chat), 100 (tasks), 120 (Developer -Studio). Agent graph cached by tool set + model override. Checkpoints via -LangGraph's SQLite-backed checkpointer. 30+ tool modules. - -Safety model: Shell command classification (tools/shell_tool.py) with 17 blocked -patterns (rm -rf /, mkfs, dd of=/dev/, shutdown, fork bombs, pipe-to-bash, etc.), -30+ safe auto-execute prefixes (ls, cat, grep, git status, etc.), needs-approval -for compound commands (;, &&, ||, |, $(), backticks). Interactive interrupt() for -non-safe shell — LangGraph human-in-the-loop pauses the graph. Per-workflow safety -modes: block (default, refuse non-safe), approve (pause), allow_all. -Prompt-injection defense: scans tool outputs and user inputs for 5 categories -(role overrides, instruction hijacking, data exfiltration, invisible unicode, -hidden HTML directives) — detection-only, no stripping. Filesystem workspace -boundary (~/Documents/Thoth). Opt-in Docker Sandbox for Developer Studio. -Destructive ops (file delete, moderate shell, Gmail send, calendar delete, -memory/task/tracker delete) require confirmation. MCP servers disabled until -tested. Custom Tools reviewed and promoted. No sandboxing of agent runtime -itself — agent runs in-process. No response-level guardrails. - -Data model: SQLite (WAL mode) at ~/.thoth/memory.db — shared between knowledge -graph and legacy memory. Knowledge graph: SQLite (durable) + NetworkX MultiDiGraph -(in-memory, rebuilt on startup) + FAISS vector index (semantic recall, rebuilt on -every entity write). 11 entity types (person, preference, fact, event, place, -project, organisation, concept, skill, media, self_knowledge). 67+ typed relations -with 30+ LLM-produced aliases mapped to canonical forms. Dream Cycle refinement -pipeline for entity dedup/merge/stale-confidence decay. Config: JSON files -(skills_config.json, api_keys.json, providers.json, channels_config.json). Keys in -OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret -Service/KWallet). Memory extraction background daemon scanning past conversations -every ~2 hours. - -Self-modification: Agent CAN create/update/delete skills via dedicated tools -(thoth_create_skill, thoth_patch_skill, thoth_delete_skill). SKILL.md files with -YAML frontmatter at ~/.thoth/skills/. Bundled skills (read-only) at app root; -user skills override by name. Skill patching requires user confirmation + auto -backup. Maximum 1 patch proposal per conversation. Tool guides cannot be patched. -Self-knowledge block injected into system prompt. No tool to modify agent.py, -prompts.py, or system prompt directly. Developer Studio provides code editing -through approval-gated tools (tool-assisted human workflow, not agent self-mod). - -Verification: None formal. Update signature verification (updater.py). -Comprehensive test suite at tests/test_suite.py. No tool-call verification beyond -LangGraph schema validation. No output verification or fact-checking. - -Key differentiators vs other assistants: LangGraph ReAct agent with structured -streaming event model. Personal knowledge graph (11 entity types, 67 relations, -NetworkX + FAISS). Developer Studio (Docker sandbox, code threads, Git operations, -approval modes). Designer Studio (decks, documents, landing pages, sandboxed -interactive runtime). 5 messaging channels (Telegram, Discord, Slack, WhatsApp, -SMS) with streaming, reactions, media processing. Background workflow engine -(schedules, webhooks, step pipelines, conditions, approvals, concurrency groups). -30+ tool modules including browser automation, shell, Gmail, Calendar, X, image/ -video generation. 39 curated Ollama tool-calling models. 10 LLM providers (Ollama, -OpenAI, Anthropic, Google AI/Gemini, xAI/Grok, MiniMax, OpenRouter, Ollama Cloud, -ChatGPT/Codex subscription, custom endpoints). MCP client (stdio, Streamable HTTP, -SSE) with namespaced tools, approval gates. No accounts, no telemetry, no hosted -server. Local-first with OS credential store. - -Key gap vs Passepartout: No deterministic gate stack — shell safety is pattern -list (17 blocked, 30 safe), not typed gates. No sandboxed agent runtime. No -proof system. No output guardrails. No neurosymbolic architecture. No Org-mode. -No Merkle-tree memory. Knowledge graph (SQLite+FAISS) is richer than Hermes but -is LLM-driven entity extraction — no structural integrity guarantees. Thoth's -differentiation from Hermes/OpenClaw is the knowledge graph + Developer/Designer -studios + embedded LangGraph framework — a broader product scope, but still -architecturally conventional (LLM + tools + channels + KG), not a new cognitive -architecture. - -* Category 3: CI/Check Systems - -** Continue (TypeScript, ~328K lines, Apache 2.0) - -Source-controlled AI checks for CI/CD. Markdown-as-gate-policy. - -Architecture: Shared core (@continuedev/core) with ~80 provider implementations, -tool-calling engine, config system (YAML/JSON/Markdown). Serves CLI (Ink/React TUI -+ headless CI mode), IDE extensions (VS Code, JetBrains), web dashboard. - -Safety model: Three permission levels (allow/ask/exclude). Precedence: mode policies -→ CLI flags → permissions.yaml → built-in defaults. Terminal security package for -shell command analysis via shell-quote parsing. Workspace-scoped file access. - -Data model: Markdown files for checks, agents, rules. Source-controlled in-repo. -YAML frontmatter for metadata. - -Self-modification: Checks source-controlled — any change goes through git. - -Verification: None (the checks are themselves unverified). - -Key gap vs Passepartout: The "checks as markdown" concept is philosophically -similar to Passepartout's gate rules (deterministic policies checked before -execution) but the implementation is dramatically simpler — regex-based policy -objects, not a type-level gate stack with structural guarantees. No persistent -agent, no memory, no knowledge graph, no neurosymbolic architecture. It is a -gate system without an agent to gate. - -* The Passepartout Advantage - -| Dimension | Passepartout | Best Competitor | Gap | -|-----------|--------------|-----------------|-----| -| Safety model | Type-level gates + 11-vector deterministic stack | Claude Code (7 permission modes + 23 bash checks) | Structural vs heuristic. Passepartout's type-level gates prevent self-modification at the category level; competitors block patterns. | -| Knowledge model | Org-mode (tree, properties, TODOs, timestamps, cross-refs, IDs, tags) | Claude Code (flat markdown memdir) | Org-mode's semantic richness is ~15 primitives markdown doesn't have. | -| Memory integrity | Merkle tree + SHA-256 + rollback | Hermes (file-based); Claude Code (flat files + git) | Content-addressed, tamper-evident memory no competitor has. | -| Self-verification | ACL2 → CIC prover (planned) | None | No competitor does provable correctness. | -| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. | -| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. | -| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). | -| Triad | Passepartout + [[file:stoa.org][Stoa]] + [[file:agora.org][Agora]] | None | No competitor is building a full computing stack + social network. | -| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. | - -* Where Competitors Lead - -| Dimension | Leader | Passepartout Status | -|-----------|--------|---------------------| -| Safety implementation maturity | Claude Code (2,592 lines bash security) | Gate stack exists but bash validation is minimal in comparison | -| Provider breadth | Hermes (109+), OpenClaw (50+) | 8 providers — adequate but not competitive | -| Channel/platform support | OpenClaw (25+ channels) | TUI only — no multi-channel | -| Plugin ecosystem | OpenClaw (ClawHub, npm registry) | No plugin marketplace | -| Subagent delegation | Claude Code (fork with context inheritance) | Planned via Screamer planner | -| Codebase size / features shipped | All competitors have working products | In development | -| MCP integration | Hermes, Codex (native), Continue | Planned | -| Sandboxing | Codex CLI (Seatbelt+nsjail), Gemini CLI (6 methods) | None | -| Business model | Hermes (MIT+services), Codex (tokens) | AGPL + appliances + SaaS | -| Cross-platform | Claude Code (macOS/*nix), Codex (macOS) | Linux only | - -* Strategic Positioning - -Passepartout is not competing in the existing AI agent market. It is building a -new category: provable personal infrastructure. - -Competitors optimize for: -- Token efficiency (Aider's edit formats, OpenCode's LSP integration) -- Model flexibility (Hermes' 109 providers) -- Platform reach (OpenClaw's 25 channels) -- UI polish (Gemini CLI's Ink/React, Claude Code's permission dialogs) -- Sandbox security (Codex's Seatbelt, Gemini's gVisor) - -Passepartout optimizes for: -- Provable correctness (ACL2 → CIC) -- Data integrity (Merkle tree) -- Cognitive architecture (10-80-10 symbolic-first) -- Safety by construction (type-level gates) -- Unified data model (Org-mode as everything) -- Network effects (Agora) -- Full-stack ownership (Stoa) - -These are not axes any competitor cares about. The risk is not that a competitor -builds a better Passepartout — it's that the market never develops a preference -for provable agents. If token-burning LLM agents remain the default and users -don't demand verification, the entire category Passepartout addresses may not -exist yet. - -* Immediate Implications for Development - -1. Claude Code's safety system is the benchmark to exceed. The type-level gate - architecture is theoretically superior to Claude Code's heuristic patterns, - but the implementation needs to prove it catches things Claude Code - misses. - -2. No competitor has anything resembling a neurosymbolic architecture. The 10-80-10 - plan has zero competition — but that also means zero market validation. - -3. The Org-mode bet is invisible to competitors. They don't see the advantage - because they've never tried to build a knowledge graph from flat markdown files. - This is Passepartout's widest moat — it depends on a skill (Org-mode literate - programming) that no competitor's team has. - -4. Hermes is the closest full-stack competitor (tools, skills, cron, subagents, - multi-platform), but architecturally conventional. For Hermes to match - Passepartout, it would need to be rewritten. - -5. The coding agents (Aider, OpenCode, Codex) are not competitors — they are - single-purpose tools Passepartout could eventually replace entirely when the - planner matures. - -* File references - -Repository dumps and analysis artifacts at /tmp/: -- /tmp/aider/ — Aider source (Python) -- /tmp/opencode/ — OpenCode archived source (Go) -- /tmp/codex/ — OpenAI Codex CLI (Rust) -- /tmp/claude-code-leaked-source/ — Claude Code leaked (TypeScript/Bun) -- /tmp/gemini-cli/ — Google Gemini CLI (TypeScript) -- /tmp/openclaw/ — OpenClaw source (TypeScript) -- /tmp/thoth/ — Thoth source (Python) -- /tmp/continue/ — Continue source (TypeScript) -- /usr/local/lib/hermes-agent/ — Hermes Agent (Python) diff --git a/ideas/competitive-analysis.org b/ideas/competitive-analysis.org new file mode 100644 index 0000000..6dd71dc --- /dev/null +++ b/ideas/competitive-analysis.org @@ -0,0 +1,128 @@ +:PROPERTIES: +:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1 +:CREATED: [2026-05-22 Thu] +:END: +#+title: Competitive Analysis — AI Agent Landscape +#+filetags: :passepartout:strategy:competitive: + +* Overview + +Analyzed 9 competitor codebases alongside Passepartout. The competitive landscape +divides into three categories: + +1. Coding agents — Aider, OpenCode, Codex CLI, Claude Code, Gemini CLI +2. Personal AI assistants — [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]], OpenClaw, [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]] +3. CI/check-based systems — Continue + +None of the nine compete with Passepartout on all axes simultaneously. Passepartout's +strongest differentiators — Org-mode data model, deterministic gate stack, ACL2 +verification, Merkle-treed memory, and the triad architecture — are absent from +every competitor. + +* Category 1: Coding Agents + +- [[id:c3aab2e8-7e43-4abc-93f0-741675cfd78c][Aider]] — Python, ~40K lines, MIT. Oldest open-source coding agent. Chat-based Coder class with 5 edit formats. Purely prompt-based safety. +- [[id:7a060b36-36db-4eb7-b8cc-844bd6ac9d36][OpenCode]] — TypeScript/Bun, 163K★. Dominant open-source coding agent. Dual LLM runtime, ACP inter-agent protocol, SQLite state. +- [[id:e929ff32-28d8-4a29-bf74-d55babc040d1][Codex CLI]] — Rust, ~950K lines, OpenAI. Strongest sandboxing (Seatbelt/nsjail). Execution policy engine. No knowledge graph. +- [[id:512dd121-2292-4f3d-ac53-31bf3d12a60f][Claude Code]] — TypeScript/Bun, ~512K lines leaked. Most mature safety system (2,592 lines bash security). 7 permission modes. Proprietary. +- [[id:8d73ccb9-34e4-4899-b0c3-605998e9bebc][Gemini CLI]] — TypeScript, ~525K lines, Apache 2.0. CONSECA AI-driven policy generation. 6 sandbox methods. Google-locked. + +* Category 2: Personal AI Assistants + +- [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]] — Python, ~17K core, MIT. Running this conversation. 109+ providers, 15+ messaging platforms, MCP client. Heuristic safety layers. +- [[id:85ca69dd-d085-4a55-ad11-021910b1f82e][OpenClaw]] — TypeScript/Node.js, ~3.5M lines. Largest codebase. 25+ messaging channels, 135 bundled plugins. Tiered sandboxing. +- [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]] — Python, ~151K lines, Apache 2.0. Personal knowledge graph (11 entity types, 67 relations, NetworkX+FAISS). LangGraph ReAct agent. Developer Studio. + +* Category 3: CI/Check Systems + +- [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] — TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy. No persistent agent. + +* The Passepartout Advantage + +| Dimension | Passepartout | Best Competitor | Gap | +|-----------|--------------|-----------------|-----| +| Safety model | Type-level gates + 11-vector deterministic stack | Claude Code (7 permission modes + 23 bash checks) | Structural vs heuristic. Passepartout's type-level gates prevent self-modification at the category level; competitors block patterns. | +| Knowledge model | Org-mode (tree, properties, TODOs, timestamps, cross-refs, IDs, tags) | Claude Code (flat markdown memdir) | Org-mode's semantic richness is ~15 primitives markdown doesn't have. | +| Memory integrity | Merkle tree + SHA-256 + rollback | Hermes (file-based); Claude Code (flat files + git) | Content-addressed, tamper-evident memory no competitor has. | +| Self-verification | ACL2 → CIC prover (planned) | None | No competitor does provable correctness. | +| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. | +| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. | +| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). | +| Triad | Passepartout + [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | None | No competitor is building a full computing stack + social network. | +| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. | + +* Where Competitors Lead + +| Dimension | Leader | Passepartout Status | +|-----------|--------|---------------------| +| Safety implementation maturity | Claude Code (2,592 lines bash security) | Gate stack exists but bash validation is minimal in comparison | +| Provider breadth | Hermes (109+), OpenClaw (50+) | 8 providers — adequate but not competitive | +| Channel/platform support | OpenClaw (25+ channels) | TUI only — no multi-channel | +| Plugin ecosystem | OpenClaw (ClawHub, npm registry) | No plugin marketplace | +| Subagent delegation | Claude Code (fork with context inheritance) | Planned via Screamer planner | +| Codebase size / features shipped | All competitors have working products | In development | +| MCP integration | Hermes, Codex (native), Continue | Planned | +| Sandboxing | Codex CLI (Seatbelt+nsjail), Gemini CLI (6 methods) | None | +| Business model | Hermes (MIT+services), Codex (tokens) | AGPL + appliances + SaaS | +| Cross-platform | Claude Code (macOS/*nix), Codex (macOS) | Linux only | + +* Strategic Positioning + +Passepartout is not competing in the existing AI agent market. It is building a +new category: provable personal infrastructure. + +Competitors optimize for: +- Token efficiency (Aider's edit formats, OpenCode's LSP integration) +- Model flexibility (Hermes' 109 providers) +- Platform reach (OpenClaw's 25 channels) +- UI polish (Gemini CLI's Ink/React, Claude Code's permission dialogs) +- Sandbox security (Codex's Seatbelt, Gemini's gVisor) + +Passepartout optimizes for: +- Provable correctness (ACL2 → CIC) +- Data integrity (Merkle tree) +- Cognitive architecture (10-80-10 symbolic-first) +- Safety by construction (type-level gates) +- Unified data model (Org-mode as everything) +- Network effects (Agora) +- Full-stack ownership (Stoa) + +These are not axes any competitor cares about. The risk is not that a competitor +builds a better Passepartout — it's that the market never develops a preference +for provable agents. If token-burning LLM agents remain the default and users +don't demand verification, the entire category Passepartout addresses may not +exist yet. + +* Immediate Implications for Development + +1. Claude Code's safety system is the benchmark to exceed. The type-level gate + architecture is theoretically superior to Claude Code's heuristic patterns, + but the implementation needs to prove it catches things Claude Code misses. + +2. No competitor has anything resembling a neurosymbolic architecture. The 10-80-10 + plan has zero competition — but that also means zero market validation. + +3. The Org-mode bet is invisible to competitors. They don't see the advantage + because they've never tried to build a knowledge graph from flat markdown files. + This is Passepartout's widest moat — it depends on a skill (Org-mode literate + programming) that no competitor's team has. + +4. Hermes is the closest full-stack competitor (tools, skills, cron, subagents, + multi-platform), but architecturally conventional. + +5. The coding agents (Aider, OpenCode, Codex) are not competitors — they are + single-purpose tools Passepartout could eventually replace entirely when the + planner matures. + +* File references + +Repository dumps and analysis artifacts at /tmp/: +- /tmp/aider/ — Aider source (Python) +- /tmp/opencode/ — OpenCode archived source +- /tmp/codex/ — OpenAI Codex CLI (Rust) +- /tmp/claude-code-leaked-source/ — Claude Code leaked (TypeScript/Bun) +- /tmp/gemini-cli/ — Google Gemini CLI (TypeScript) +- /tmp/openclaw/ — OpenClaw source (TypeScript) +- /tmp/thoth/ — Thoth source (Python) +- /tmp/continue/ — Continue source (TypeScript) +- /usr/local/lib/hermes-agent/ — Hermes Agent (Python) diff --git a/ideas/competitive-landscape-agora.org b/ideas/competitive-landscape-agora.org index 3118b1d..30310fa 100644 --- a/ideas/competitive-landscape-agora.org +++ b/ideas/competitive-landscape-agora.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f :ID: competitive-landscape-agora :CREATED: [2026-05-23 Sat] :END: @@ -138,7 +139,7 @@ This page maps every platform the Agora replaces, organized by domain, with the - *Agora replacement:* Agora naming registry with similar auction model. But integrated with PDS, messaging, contracts, and payments — a name in the Agora is a full identity, not just a pointer to a wallet. - *Agora advantage:* Names come with native capabilities (PDS, messaging, contracts). ENS is names-only. -* The Competitive Analysis: What This Changes +* The [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][Competitive Analysis]]: What This Changes The Agora is not competing with any single product. It is competing with the /aggregate/ of 20+ products — and the friction of managing 20+ separate accounts, logins, reputations, and data silos. @@ -211,9 +212,9 @@ The OnlyFans/Patreon entry vector is the strongest Phase 1 play: a community wit * References -- [[file:agora.org][Agora overview]] (brain docs) -- [[file:agora-contracts.org][Agora contract platform]] -- [[file:alternative-growth-social-first.org][Social-first growth scenario]] +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]] (brain docs) +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform]] +- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]] - Agora Protocol Overview (spec repo) - Social Space specification - Exchange and Contracts specification diff --git a/ideas/competitors/aider.org b/ideas/competitors/aider.org new file mode 100644 index 0000000..e5d30f9 --- /dev/null +++ b/ideas/competitors/aider.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: c3aab2e8-7e43-4abc-93f0-741675cfd78c +:CREATED: [2026-05-22 Thu] +:END: +#+title: Aider — AI Coding Agent +#+filetags: :passepartout:strategy:competitive:aider: + +Language: Python. ~6.8M pip installs. ~40K lines. MIT license. The oldest and most mature open-source coding agent. + +Architecture: Chat-based Coder class with 5 edit formats (diff, udiff, patch, whole, architect). Uses litellm for universal provider access (50+ providers). RepoMap provides codebase awareness via cosine-similarity embedding. + +Safety model: Purely prompt-based plus user-confirmation dialogs. No deterministic gate stack. No sandboxing. No model output validator. The allowed_to_edit() gate is a single user confirmation call. --yes flag auto-approves. Aider can edit its own source code with no special protection — self-modification is undetectable. + +Data model: Ad-hoc. Chat messages in memory. Git commits for persistence. RepoMap is a cosine-similarity index. No persistent memory across sessions. No knowledge graph. + +Self-modification: Full. No guard against editing its own files. + +Verification: None. + +Key gap vs Passepartout: No safety gates, no persistent memory model, no knowledge representation, no verification, no self-modification protection, no architecture for neurosymbolic reasoning. It is a thin shell around litellm + edit format parsers. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/claude-code.org b/ideas/competitors/claude-code.org new file mode 100644 index 0000000..21bb539 --- /dev/null +++ b/ideas/competitors/claude-code.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 512dd121-2292-4f3d-ac53-31bf3d12a60f +:CREATED: [2026-05-22 Thu] +:END: +#+title: Claude Code — Anthropic AI Coding Agent +#+filetags: :passepartout:strategy:competitive:claude-code: + +Anthropic's proprietary coding agent. TypeScript/Bun, ~512K lines (leaked source analysis). Not open source. + +Architecture: Bun-bundled TypeScript single-file executable. Ink/React terminal UI. 23+ core tools. Subagent forking with byte-identical API prefixes for prompt cache sharing. Multi-agent coordination mode. + +Safety model: Layered deterministic safety — NOT prompt-based: 7 permission modes, persistent permission rules (alwaysAllow/alwaysDeny/alwaysAsk from 4 sources), bash security validator at 2,592 lines with 23+ named security checks using tree-sitter AST parsing, sandbox runtime, path/mode validation, optional ML bash classifier. This is the most sophisticated safety system of any coding agent analyzed. + +Data model: File-based markdown memdir at ~/.claude/projects//memory/. 4 memory types: user, feedback, project, reference. YAML frontmatter in .md files. PROJECT.md and CLAUDE.md for project config. No database. + +Self-modification: HIGH. Skill system writes SKILL.md files. Plugin system, cron scheduling, agent spawning. + +Verification: None. + +Key gap vs Passepartout: No proof system, no neurosymbolic architecture, no self-verification, no persistent knowledge graph (flat markdown files, not Org-mode with cross-references), markdown data model lacks semantic depth. Proprietary — Anthropic controls it completely. The permission rules system is impressive but structurally inferior to Passepartout's gate stack because rules are heuristic (regex-based pattern matching) rather than typed (type-level gates with structural guarantees). + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/codex-cli.org b/ideas/competitors/codex-cli.org new file mode 100644 index 0000000..c9ef9c3 --- /dev/null +++ b/ideas/competitors/codex-cli.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: e929ff32-28d8-4a29-bf74-d55babc040d1 +:CREATED: [2026-05-22 Thu] +:END: +#+title: Codex CLI — OpenAI AI Coding Agent +#+filetags: :passepartout:strategy:competitive:codex: + +OpenAI's open-source coding agent. Rust, ~950K lines, sandboxed. + +Architecture: ~116 crate Rust workspace with a protocol layer (SQ/EQ session types), sandbox manager (macOS Seatbelt, Linux nsjail), multi-provider support, configurable TUI. + +Safety model: Most sophisticated safety system of any coding agent analyzed. Multi-layer: process hardening (macOS Seatbelt with 4 profile tiers), execution policy engine, sandboxing via nsjail/Seatbelt, Guardian module for tool permission gating. No prompt-based safety — all deterministic through policy definitions. + +Data model: Protocol-defined session types. Structured request/response models. Config through TOML files with schema validation. + +Self-modification: Protected by sandbox — the agent cannot escape to modify its own binary or config without explicit policy override. + +Verification: None (no proof system). + +Key gap vs Passepartout: No knowledge graph, no persistent memory model, no deterministic gate stack for agent behavior (only OS-level sandboxing), no ACL2/prover, no neurosymbolic architecture. Strongest sandbox but weakest cognitive architecture. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/continue.org b/ideas/competitors/continue.org new file mode 100644 index 0000000..eb1a6f8 --- /dev/null +++ b/ideas/competitors/continue.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 22d0a159-68a2-4587-9375-5046beddc20c +:CREATED: [2026-05-22 Thu] +:END: +#+title: Continue — CI/Check System +#+filetags: :passepartout:strategy:competitive:continue: + +TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy. + +Architecture: Shared core (@continuedev/core) with ~80 provider implementations, tool-calling engine, config system (YAML/JSON/Markdown). Serves CLI (Ink/React TUI + headless CI mode), IDE extensions (VS Code, JetBrains), web dashboard. + +Safety model: Three permission levels (allow/ask/exclude). Precedence: mode policies → CLI flags → permissions.yaml → built-in defaults. Terminal security package for shell command analysis via shell-quote parsing. Workspace-scoped file access. + +Data model: Markdown files for checks, agents, rules. Source-controlled in-repo. YAML frontmatter for metadata. + +Self-modification: Checks source-controlled — any change goes through git. + +Verification: None (the checks are themselves unverified). + +Key gap vs Passepartout: The checks-as-markdown concept is philosophically similar to Passepartout's gate rules (deterministic policies checked before execution) but the implementation is dramatically simpler — regex-based policy objects, not a type-level gate stack with structural guarantees. No persistent agent, no memory, no knowledge graph, no neurosymbolic architecture. It is a gate system without an agent to gate. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/gemini-cli.org b/ideas/competitors/gemini-cli.org new file mode 100644 index 0000000..47d2356 --- /dev/null +++ b/ideas/competitors/gemini-cli.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 8d73ccb9-34e4-4899-b0c3-605998e9bebc +:CREATED: [2026-05-22 Thu] +:END: +#+title: Gemini CLI — Google AI Coding Agent +#+filetags: :passepartout:strategy:competitive:gemini: + +Google's open-source coding agent. TypeScript, ~525K lines, Apache 2.0. Node.js 20+, Ink/React TUI. + +Architecture: 7-package npm monorepo. Core backend handles Gemini API orchestration, tool execution, policy engine, safety checks, sandbox management, session management, MCP client. 7-strategy composite model routing chain. + +Safety model: Multi-layered: CONSECA (Contextual Security Checker) — AI-driven per-request policy generation using a separate Gemini Flash model. 4 approval modes (PLAN/DEFAULT/AUTO_EDIT/YOLO). 6 sandbox methods (macOS Seatbelt, Docker/Podman, bwrap, gVisor, LXC, Windows). Trusted folders with path traversal protection. Policy integrity via cryptographic hashes. Loop detection. + +Data model: JSONL session files. Turn-based conversation model. 4-layer config precedence (system-defaults → user → project → system-override). TOML policy files. + +Self-modification: Modifiable hooks system, MCP extensions, custom commands. Core binaries are protected on disk by file permissions. + +Verification: None. + +Key gap vs Passepartout: No proof system, no persistent knowledge graph, no self-verification, no neurosymbolic architecture, lock-in to Google Gemini models. CONSECA is interesting (AI-generated policies) but introduces a second LLM call for every security decision — the opposite of Passepartout's zero-token deterministic gating. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/hermes-agent.org b/ideas/competitors/hermes-agent.org new file mode 100644 index 0000000..a5fd615 --- /dev/null +++ b/ideas/competitors/hermes-agent.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: c652688a-1ea0-487c-9222-00e954efe8a1 +:CREATED: [2026-05-22 Thu] +:END: +#+title: Hermes Agent — Personal AI Assistant +#+filetags: :passepartout:strategy:competitive:hermes: + +The agent running this conversation. Python, ~17K core lines, MIT. + +Architecture: Synchronous conversation loop with OpenAI-format messages. 60+ built-in tools. 109+ providers via pluggable transport layer. 15+ messaging platforms via gateway. MCP client (native, not bridge). Ink/React TUI as Node.js subprocess. Cron jobs, Kanban board, subagent delegation. + +Safety model: Multi-layer but NOT a deterministic gate stack: message sanitization, Tirith binary scanner, command approval system, memory injection detection, secret/PII redaction, tool call guardrails, MCP security, context fencing. All heuristic or prompt-based — no structural type-level gates. + +Data model: SQLite session DB (FTS5 full-text search). File-based memory (MEMORY.md + USER.md). YAML config. No knowledge graph. No Org-mode. + +Self-modification: Skill system writes SKILL.md files. Memory tool edits MEMORY.md/USER.md. Core Python code is read-only in execution but no gate specifically prevents the LLM from requesting source modifications. + +Verification: None. + +Key gap vs Passepartout: No deterministic gate stack (heuristic layers, not structural/typed), no knowledge graph, no Org-mode, no neurosymbolic architecture, no self-verification, no proof system. Hermes's strength is breadth — 109 providers, 15 platforms, MCP ecosystem. But it has no depth in safety, knowledge representation, or reasoning architecture. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/openclaw.org b/ideas/competitors/openclaw.org new file mode 100644 index 0000000..e3e3fcd --- /dev/null +++ b/ideas/competitors/openclaw.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 85ca69dd-d085-4a55-ad11-021910b1f82e +:CREATED: [2026-05-22 Thu] +:END: +#+title: OpenClaw — Personal AI Assistant +#+filetags: :passepartout:strategy:competitive:openclaw: + +TypeScript/Node.js, ~3.5M lines. The largest codebase analyzed. Personal AI assistant with 25+ messaging channel support. + +Architecture: pnpm workspace with ~135 bundled plugins. Gateway control plane routes messages through multi-agent routing. Per-agent sessions, workspaces, skill registries. Companion native apps (macOS, iOS, Android). + +Safety model: Tiered — main agent runs tools directly on host (trusted-operator), non-main sessions sandboxed via Docker (read-only rootfs, capability dropping, seccomp/AppArmor, memory/cpu/PID limits, SSH/OpenShell backends). + +Data model: Typed JSON/YAML config (openclaw.json). Multi-source model catalog. Plugin SDK with narrow typed subpath exports. + +Self-modification: ACP (Agent Control Protocol) for spawning child sessions. Skill system with npm distribution and ClawHub registry. + +Verification: None. + +Key gap vs Passepartout: Same as Hermes — no gate stack, no knowledge graph, no Org-mode, no verification, no neurosymbolic architecture. Differentiated by vastly broader channel support and mature plugin ecosystem. But architecturally conventional — LLM + tools + channels, no cognitive architecture innovation. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/opencode.org b/ideas/competitors/opencode.org new file mode 100644 index 0000000..0f6282a --- /dev/null +++ b/ideas/competitors/opencode.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 7a060b36-36db-4eb7-b8cc-844bd6ac9d36 +:CREATED: [2026-05-22 Thu] +:END: +#+title: OpenCode — AI Coding Agent +#+filetags: :passepartout:strategy:competitive:opencode: + +TypeScript/Bun. anomalyco/opencode, 163K★. The dominant open-source coding agent by adoption. Bun runtime, Effect-TS functional core, Solid.js TUI, Turborepo monorepo. + +Architecture: Dual LLM runtime — default AI SDK (streamText/generateText) + opt-in native Effect-Schema runtime with 4-axis route decomposition (Protocol/Endpoint/Auth/Framing). 30+ provider plugins. Agent workflow DSL with plan/build agent switching. Agent Communication Protocol (ACP) for inter-agent messaging. Subagents inherit permission boundaries from parent. 18+ built-in tools + custom tools from config. Effect-TS ScopedCache per-project state management. + +Safety model: Explicitly documents not sandboxing the agent. Permission system is rule-based (glob matching, actions: allow/ask/deny) and exists as a UX feature, not security isolation. Built-in agents have carefully scoped defaults. Permission rules inherited by subagents. + +Data model: SQLite via Drizzle ORM with bun:sqlite or better-sqlite3. Key tables: SessionTable, MessageTable, PartTable. Project model stores worktree, VCS, sandbox config. Config is JSON-chain with remote config fetch. + +Self-modification: Agent.generate() interface lets the LLM create new agent definitions — the system grows its own subagent roster. Skills system loads domain-specific knowledge packs dynamically. + +Verification: None. + +Key gap vs Passepartout: No deterministic safety architecture, no knowledge graph, no Org-mode, no verification/proof system, no neurosymbolic architecture. The permission system is explicitly labeled not security isolation — it's UX, not a gate stack. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/competitors/thoth.org b/ideas/competitors/thoth.org new file mode 100644 index 0000000..6badb7b --- /dev/null +++ b/ideas/competitors/thoth.org @@ -0,0 +1,22 @@ +:PROPERTIES: +:ID: 416bab7c-4300-4d50-838a-5c7a8ad45d96 +:CREATED: [2026-05-22 Thu] +:END: +#+title: Thoth — Personal AI Sovereignty +#+filetags: :passepartout:strategy:competitive:thoth: + +https://github.com/siddsachar/Thoth — Python, ~151K lines, Apache 2.0. Local-first desktop AI assistant with knowledge graph, tools, voice, vision, shell, browser automation, workflow engine, and messaging channels. + +Architecture: LangGraph create_react_agent (prebuilt ReAct pattern). Dual-mode streaming. NiceGUI web UI with desktop launcher. Context trimming via tiktoken, base64 data redaction, stale browser snapshot compression, MD5 tool result dedup, old tool result summarization. Agent graph cached by tool set + model override. Checkpoints via LangGraph's SQLite-backed checkpointer. 30+ tool modules. + +Safety model: Shell command classification with 17 blocked patterns, 30+ safe auto-execute prefixes, needs-approval for compound commands. Interactive interrupt for non-safe shell. Per-workflow safety modes (block/approve/allow_all). Prompt-injection defense (5 categories, detection-only). Filesystem workspace boundary. Opt-in Docker Sandbox. Destructive ops require confirmation. No sandboxing of agent runtime itself. + +Data model: SQLite (WAL mode) at ~/.thoth/memory.db — shared between knowledge graph and legacy memory. Knowledge graph: SQLite (durable) + NetworkX MultiDiGraph (in-memory, rebuilt on startup) + FAISS vector index (semantic recall). 11 entity types, 67+ typed relations with 30+ LLM-produced aliases. Dream Cycle refinement pipeline. Config: JSON files. Keys in OS credential store. + +Self-modification: Agent CAN create/update/delete skills via dedicated tools. Skill patching requires user confirmation + auto backup. Maximum 1 patch proposal per conversation. No tool to modify system prompts directly. + +Verification: None formal. Update signature verification. + +Key gap vs Passepartout: No deterministic gate stack — shell safety is pattern list, not typed gates. No proof system. No output guardrails. No neurosymbolic architecture. No Org-mode. No Merkle-tree memory. Knowledge graph is LLM-driven entity extraction — no structural integrity guarantees. Thoth's differentiation is the knowledge graph + Developer/Designer studios + embedded LangGraph framework, but still architecturally conventional. + +See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison. diff --git a/ideas/compliance-framework-mapping.org b/ideas/compliance-framework-mapping.org index b6c0ed3..d80b054 100644 --- a/ideas/compliance-framework-mapping.org +++ b/ideas/compliance-framework-mapping.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 36e5b948-e07b-477f-9036-4dfe88254347 :ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c :CREATED: [2026-05-23 Sat] :UPDATED: [2026-05-23 Sat] @@ -6,43 +7,43 @@ #+title: Compliance Framework Mapping — Global Regulated Industries #+filetags: :passepartout:triad:compliance:global:index: -This file has been split into atomic framework notes under [[file:compliance/][compliance/]]. +This file has been split into atomic framework notes under [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]. -See [[file:compliance/compliance-index.org][Compliance framework index]] for the hub with per-framework links. -See [[file:compliance/first-mover-window.org][First-mover window analysis]] for timing. -See [[file:compliance/revenue-table.org][[[file:compliance/revenue-table.org][Revenue table]]]] for pricing and TAM. +See [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] for the hub with per-framework links. +See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] for timing. +See [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for pricing and TAM. -Each framework is its own file in [[file:compliance/][compliance/]]: -- [[file:compliance/hipaa.org][HIPAA]] -- [[file:compliance/soc2.org][SOC 2]] -- [[file:compliance/gdpr.org][GDPR]] -- [[file:compliance/fedramp.org][[[file:compliance/fedramp.org][FedRAMP]]]] -- [[file:compliance/sox.org][SOX]] -- [[file:compliance/glba.org][GLBA]] -- [[file:compliance/ny-dfs-500.org][[[file:compliance/ny-dfs-500.org][NY DFS 500]]]] -- [[file:compliance/ccpa-cpra.org][CCPA/CPRA]] -- [[file:compliance/quebec-law-25.org][[[file:compliance/quebec-law-25.org][Quebec Law 25]]]] -- [[file:compliance/uk-gdpr.org][[[file:compliance/uk-gdpr.org][UK [[file:compliance/gdpr.org][GDPR]]]]]] -- [[file:compliance/nis2.org][NIS2]] -- [[file:compliance/eu-ai-act.org][[[file:compliance/eu-ai-act.org][EU AI Act]]]] -- [[file:compliance/dora.org][DORA]] -- [[file:compliance/eidas2.org][eIDAS 2.0]] -- [[file:compliance/cra.org][CRA]] -- [[file:compliance/appi.org][APPI]] -- [[file:compliance/ismap.org][ISMAP]] -- [[file:compliance/pipa.org][PIPA]] -- [[file:compliance/privacy-act-aus.org][Privacy Act Australia]] -- [[file:compliance/apra-cps-234.org][[[file:compliance/apra-cps-234.org][APRA CPS 234]]]] -- [[file:compliance/irap.org][IRAP]] -- [[file:compliance/dpdp-act.org][[[file:compliance/dpdp-act.org][DPDP Act]] India]] -- [[file:compliance/lgpd.org][LGPD Brazil]] -- [[file:compliance/lfp-dppp.org][LFPDPPP Mexico]] -- [[file:compliance/iso-27001.org][[[file:compliance/iso-27001.org][ISO 27001]]]] -- [[file:compliance/iso-27701.org][[[file:compliance/iso-27701.org][ISO 27701]]]] -- [[file:compliance/basel-iii.org][[[file:compliance/basel-iii.org][Basel III]]]] -- [[file:compliance/fatf.org][FATF AML/CFT]] -- [[file:compliance/ifrs.org][IFRS]] -- [[file:compliance/oecd.org][OECD Privacy/AI]] -- [[file:compliance/world-bank-esf.org][[[file:compliance/world-bank-esf.org][World Bank ESF]]]] -- [[file:compliance/ifc-ps.org][IFC PS]] -- [[file:compliance/un-cefact.org][UN/CEFACT]] +Each framework is its own file in [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]: +- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] +- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]] +- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] +- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] +- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] +- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] +- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] +- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] +- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]] +- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] +- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] +- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] +- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] +- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] +- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] +- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] +- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] +- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] +- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act Australia]] +- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] +- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] +- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] +- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD Brazil]] +- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP Mexico]] +- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] +- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] +- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] +- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF AML/CFT]] +- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] +- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Privacy/AI]] +- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] +- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] +- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] diff --git a/ideas/compliance/_index.org b/ideas/compliance/_index.org new file mode 100644 index 0000000..58da368 --- /dev/null +++ b/ideas/compliance/_index.org @@ -0,0 +1,7 @@ +#+title: Compliance +#+filetags: :compliance:index: + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 1c4c91ec-c465-44ab-bd91-4c3b45909ddb +:END: \ No newline at end of file diff --git a/ideas/compliance/appi.org b/ideas/compliance/appi.org index a71889a..36e5dbb 100644 --- a/ideas/compliance/appi.org +++ b/ideas/compliance/appi.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: b852ec69-0fc2-435c-ae1e-6b83e49b3ca3 :ID: auto-appi :CREATED: [2026-05-23 Sat] :END: @@ -23,4 +24,6 @@ Japanese residents. Why it matters: APPI's cross-border transfer restrictions require fine-grained control over which data leaves Japan. The gate stack can encode "this data has APPI cross-border consent flag = false → block egress." First-mover advantage -is moderate — few non-Japanese vendors target APPI specifically, and the 2022 +is moderate — few non-Japanese vendors target APPI specifically, and the 2022 report. First-mover advantage is moderate — few non-Japanese vendors target APPI specifically, and the 2022 amendments created a market for dedicated APPI tooling. + +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/apra-cps-234.org b/ideas/compliance/apra-cps-234.org index 78186eb..691f9a3 100644 --- a/ideas/compliance/apra-cps-234.org +++ b/ideas/compliance/apra-cps-234.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 904f5f12-ec9a-4cbf-854a-0b9b1e11a521 :ID: auto-apra-cps-234 :CREATED: [2026-05-23 Sat] :END: @@ -21,7 +22,7 @@ license cancellation for non-compliance. Personal liability for board and senior management. Why it matters: CPS 234's control testing requirement creates demand for -continuous verification — exactly what the gate stack and [[file:../evaluation-harness.org][evaluation harness]] +continuous verification — exactly what the gate stack and [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] provide. First-mover advantage: CPS 234 is mature (2019) but enforcement is escalating. No vendor provides a deterministic control-testing pipeline. diff --git a/ideas/compliance/basel-iii.org b/ideas/compliance/basel-iii.org index cd1f865..7ff9236 100644 --- a/ideas/compliance/basel-iii.org +++ b/ideas/compliance/basel-iii.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 4eef0993-6671-41cf-ba20-d1443a3ec49d :ID: auto-basel-iii :CREATED: [2026-05-23 Sat] :END: @@ -24,4 +25,6 @@ verification-friendly. The gate stack can encode credit risk weight mappings and produce auditable proof that capital calculations follow the correct methodology. First-mover advantage: Basel compliance is done via spreadsheets and specialized risk platforms. No platform uses formal verification for -risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB +risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB is a trivial expense relative to the capital requirement penalty of getting the mapping wrong. + +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/ccpa-cpra.org b/ideas/compliance/ccpa-cpra.org index 2e9a642..21685ce 100644 --- a/ideas/compliance/ccpa-cpra.org +++ b/ideas/compliance/ccpa-cpra.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 87996d87-100c-4bf6-8546-a860b9d7c25b :ID: auto-ccpa-cpra :CREATED: [2026-05-23 Sat] :END: @@ -6,7 +7,7 @@ #+filetags: :passepartout:compliance:framework:ccpa: -California's comprehensive privacy law — the closest US analogue to [[file:gdpr.org][GDPR]]. +California's comprehensive privacy law — the closest US analogue to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]. CPRA (effective 2023) amended and strengthened CCPA. Key rights: right to know, delete, opt out of sale/sharing, correct inaccurate data, limit use of sensitive PI. Private right of action for data breaches. diff --git a/ideas/compliance/compliance-index.org b/ideas/compliance/compliance-index.org index 54e114d..9343cb3 100644 --- a/ideas/compliance/compliance-index.org +++ b/ideas/compliance/compliance-index.org @@ -6,63 +6,63 @@ #+title: Compliance Framework Index — Global Regulated Industries #+filetags: :passepartout:triad:compliance:global:index:hub: -The [[file:../verification-monopoly.org][verification monopoly]] and domain gate package revenue streams depend on +The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and domain gate package [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue streams]] depend on selling into regulated industries. These industries buy compliance, not software. Each framework below maps to a gate package the triad can sell — ACL2-verified gate rules that produce deterministic audit trails. -See [[file:first-mover-window.org][First-mover window analysis]] and [[file:revenue-table.org][Revenue table]] for the consolidated view. +See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for the consolidated view. * US Frameworks -- [[file:hipaa.org][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs) -- [[file:soc2.org][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs) -- [[file:fedramp.org][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers) -- [[file:sox.org][SOX]] — Financial controls ($50K/yr, 10K orgs) -- [[file:glba.org][GLBA]] — Financial privacy ($40K/yr, 20K orgs) -- [[file:ny-dfs-500.org][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs) -- [[file:ccpa-cpra.org][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs) +- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs) +- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs) +- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers) +- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] — Financial controls ($50K/yr, 10K orgs) +- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] — Financial privacy ($40K/yr, 20K orgs) +- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs) +- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs) * Canada -- [[file:quebec-law-25.org][Quebec Law 25]] — Provincial privacy ($25K/yr, 10K+ orgs) +- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]] — Provincial privacy ($25K/yr, 10K+ orgs) * UK and EU -- [[file:gdpr.org][GDPR]] — EU privacy ($50K/yr, 500K+ orgs) -- [[file:uk-gdpr.org][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs) -- [[file:nis2.org][NIS2]] — Network security ($50K/yr, 160K orgs) -- [[file:eu-ai-act.org][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs) -- [[file:dora.org][DORA]] — Financial resilience ($50K/yr, 22K+ orgs) -- [[file:eidas2.org][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs) -- [[file:cra.org][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs) +- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] — EU privacy ($50K/yr, 500K+ orgs) +- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs) +- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] — Network security ($50K/yr, 160K orgs) +- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs) +- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] — Financial resilience ($50K/yr, 22K+ orgs) +- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs) +- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs) * Asia-Pacific -- [[file:appi.org][APPI]] — Japan privacy ($40K/yr, 100K+ orgs) -- [[file:ismap.org][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers) -- [[file:pipa.org][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs) -- [[file:privacy-act-aus.org][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs) -- [[file:apra-cps-234.org][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs) -- [[file:irap.org][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers) -- [[file:dpdp-act.org][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs) +- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] — Japan privacy ($40K/yr, 100K+ orgs) +- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers) +- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs) +- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs) +- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs) +- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers) +- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs) * Latin America -- [[file:lgpd.org][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs) -- [[file:lfp-dppp.org][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs) +- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs) +- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs) * International -- [[file:iso-27001.org][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs) -- [[file:iso-27701.org][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs) -- [[file:basel-iii.org][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs) -- [[file:fatf.org][FATF]] — AML/CFT ($50K/yr, 50K+ orgs) -- [[file:ifrs.org][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs) -- [[file:oecd.org][OECD Guidelines]] — Privacy/AI principles (indirect) -- [[file:world-bank-esf.org][World Bank ESF]] — Development finance ($50K/yr) -- [[file:ifc-ps.org][IFC PS]] — Project finance ($50K/yr) -- [[file:un-cefact.org][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs) +- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs) +- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs) +- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs) +- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] — AML/CFT ($50K/yr, 50K+ orgs) +- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs) +- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Guidelines]] — Privacy/AI principles (indirect) +- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] — Development finance ($50K/yr) +- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] — Project finance ($50K/yr) +- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs) * Strategic View @@ -74,6 +74,9 @@ See [[file:first-mover-window.org][First-mover window analysis]] and [[file:reve | Latin America | 2 | ~$7B | LGPD (largest LATAM market) | | International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) | -Next: [[file:first-mover-window.org][First-mover window analysis]] | [[file:revenue-table.org][Full revenue table]] -See also: [[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/domain-gate-packages.org][[[file:../domain-gate-packages.org][Domain gate packages]]]], -[[file:../../ideas/compute-marketplace.org][[[file:../compute-marketplace.org][Compute marketplace]]]], [[file:../../ideas/infrastructure-lock-in.org][Infrastructure lock-in]] +The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] is enforced through +[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] running on a +[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], creating +[[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] that compounds with every framework +added. See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and +[[id:81a815ee-bf2b-4365-9894-b814e4196850][Full revenue table]] for the consolidated view. diff --git a/ideas/compliance/cra.org b/ideas/compliance/cra.org index 947ed7d..863cc4e 100644 --- a/ideas/compliance/cra.org +++ b/ideas/compliance/cra.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: ce81fefc-b7a8-4be5-912f-55fd30970b6e :ID: auto-cra :CREATED: [2026-05-23 Sat] :END: @@ -23,8 +24,8 @@ Penalties: Up to 15M EUR or 2.5% of global turnover for non-compliance with reporting obligations. Why it matters: CRA's CE marking requirement creates a certification pipeline -that the [[file:../verification-appliance.org][verification appliance]] can supply. If Passepartout's gate stack is -itself CRA-compliant (verified by the [[file:../evaluation-harness.org][evaluation harness]]), it becomes the +that the [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] can supply. If [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack is +itself CRA-compliant (verified by the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]), it becomes the compliance infrastructure for any product built on it. First-mover advantage: Class II products require notified body assessment — the bottleneck is notified body capacity. The gate stack's automated evidence pipeline bypasses the diff --git a/ideas/compliance/dora.org b/ideas/compliance/dora.org index f31b23e..4a585fc 100644 --- a/ideas/compliance/dora.org +++ b/ideas/compliance/dora.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 717ef2df-2a80-4362-b23a-5e7e12554251 :ID: auto-dora :CREATED: [2026-05-23 Sat] :END: @@ -22,7 +23,7 @@ Penalties: Up to 2% of average daily turnover × number of days breached, or Why it matters: DORA's third-party risk management requirement is a natural gate stack use case — every ICT provider access must be gated, logged, and auditable. -TLPT (threat-led penetration testing) maps to the [[file:../evaluation-harness.org][evaluation harness]]. First-mover +TLPT (threat-led penetration testing) maps to the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]. First-mover advantage is extremely time-sensitive: DORA is already in effect (January 2025). Financial institutions are scrambling for compliance tooling. A DORA gate package at $50K/yr with zero incremental cost per additional user is an immediate sale. diff --git a/ideas/compliance/dpdp-act.org b/ideas/compliance/dpdp-act.org index 776d8f3..9163326 100644 --- a/ideas/compliance/dpdp-act.org +++ b/ideas/compliance/dpdp-act.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: fed19a24-ad81-4837-a12b-dafbd3ec110a :ID: auto-dpdp-act :CREATED: [2026-05-23 Sat] :END: @@ -28,3 +29,4 @@ consent-managed data access model maps directly to DPDP's consent framework. A DPDP gate package at $30K/yr (discounted for India market) captures a market of hundreds of thousands of businesses with no incumbent vendor. +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/eidas2.org b/ideas/compliance/eidas2.org index ab74bd6..8847886 100644 --- a/ideas/compliance/eidas2.org +++ b/ideas/compliance/eidas2.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: b8cf51e8-5f39-49ad-9547-a792a2e446aa :ID: auto-eidas2 :CREATED: [2026-05-23 Sat] :END: @@ -23,4 +24,6 @@ access to the EU digital identity market. Why it matters: eIDAS 2.0 creates a verified digital identity layer across the EU. The gate stack can integrate with eIDAS wallets as the identity provider for gate rules — "only X, authenticated via eIDAS wallet, may approve this -transaction." First-mover advantage: wallets are being built now; the provider +transaction." First-mover advantage: wallets are being built now; the provider — the one that First-mover advantage: wallets are being built now; the provider that integrates with the gate stack first becomes the compliance standard for eIDAS-authenticated transactions. + +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/eu-ai-act.org b/ideas/compliance/eu-ai-act.org index a8a0a72..cb60ea1 100644 --- a/ideas/compliance/eu-ai-act.org +++ b/ideas/compliance/eu-ai-act.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 06fcdb02-2643-4f9d-ab41-e711a99cc390 :ID: auto-eu-ai-act :CREATED: [2026-05-23 Sat] :END: @@ -18,15 +19,15 @@ Who must comply: Providers and deployers of AI systems in the EU. Extraterritori if the AI system output is used in the EU. Scope covers GPAI (general-purpose AI) with additional obligations for systemic-risk GPAI. -Penalties: Up to 35M EUR or 7% of global turnover (higher than [[file:gdpr.org][GDPR]]). +Penalties: Up to 35M EUR or 7% of global turnover (higher than [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]). Why it matters: The EU AI Act's conformity assessment requirement creates an -instant certification market. Passepartout's gate stack can serve as the +instant certification market. [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack can serve as the human oversight and accuracy/robustness infrastructure for any AI system -deployed through it. The [[file:verification-monopoly.org][verification monopoly]] argument applies at maximum +deployed through it. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] argument applies at maximum force: an ACL2-verified gate stack is the most defensible approach to AI Act compliance. First-mover advantage: the regulation takes effect August 2026. No certification body or tool vendor has an ACL2-based compliance pipeline. First to market captures the standard-setting role. -** DORA (Digital Operational Resilience Act) +** [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA (Digital Operational Resilience Act)]] diff --git a/ideas/compliance/fatf.org b/ideas/compliance/fatf.org index 5d69f25..752333c 100644 --- a/ideas/compliance/fatf.org +++ b/ideas/compliance/fatf.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 03ebdb80-a9af-4e76-a443-8556424996ed :ID: auto-fatf :CREATED: [2026-05-23 Sat] :END: @@ -29,4 +30,6 @@ costs — Iran and North Korea are black-listed. Why it matters: FATF's CDD requirements are the most widespread and rule-complex compliance obligation globally. The gate stack can encode tiered CDD rules, prove that every customer onboarding followed the correct -verification path, and produce an auditable trail for every suspicion +verification path, and produce an auditable trail for every suspicion report. First-mover advantage is significant — no vendor offers verifiable AML gate automation at scale. + +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/fedramp.org b/ideas/compliance/fedramp.org index 096c22c..7cc72c6 100644 --- a/ideas/compliance/fedramp.org +++ b/ideas/compliance/fedramp.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: e6993701-3c67-49bf-82f3-06907572cbf3 :ID: auto-fedramp :CREATED: [2026-05-23 Sat] :END: @@ -46,14 +47,14 @@ contracts. FedRAMP is a procurement gate, not a regulatory one. FedRAMP is the highest bar and the most expensive certification to obtain. Few cloud providers achieve it (fewer than 300 authorized products as of 2025). But those that do capture the US government market with minimal competition. -For the triad: a [[file:compute-marketplace.org][compute marketplace]] provider with FedRAMP Moderate or High +For the triad: a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with FedRAMP Moderate or High authorization can sell to every federal agency. The gate stack's deterministic audit trail maps directly to FedRAMP's continuous monitoring requirement — producing verifiable evidence of control effectiveness on every access, not just during the annual assessment. This is what justifies the -[[file:domain-gate-packages.org][FedRAMP gate package]] at $100K/yr (the highest price) — it is not a software +[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][FedRAMP gate package]] at $100K/yr (the highest price) — it is not a software package, it is the evidence pipeline for a certification that costs $1M-$5M -and 12-36 months to obtain independently. The [[file:verification-monopoly.org][verification monopoly]] argument +and 12-36 months to obtain independently. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] argument applies hardest here: an agency that has relied on a FedRAMP-authorized compute provider for five years cannot switch without re-running the entire authorization process with a new provider. diff --git a/ideas/compliance/first-mover-window.org b/ideas/compliance/first-mover-window.org index f63ed5d..c013fbe 100644 --- a/ideas/compliance/first-mover-window.org +++ b/ideas/compliance/first-mover-window.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 558154ea-e63a-4c45-998c-26ce8588585b :ID: auto-first-mover-window :CREATED: [2026-05-23 Sat] :END: @@ -12,12 +13,16 @@ dominance before incumbents respond or the market settles on a standard approach | Window | Frameworks | Rationale | |--------|-----------|-----------| -| **Critical (<12 months)** | [[file:eu-ai-act.org][EU AI Act]] (Aug 2026 effective), [[file:nis2.org][NIS2]] (Oct 2025 deadline), [[file:dora.org][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. | -| **Wide (12-36 months)** | [[file:dpdp-act.org][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[file:quebec-law-25.org][Quebec Law 25]]; [[file:cra.org][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. | -| **Mature (commodity)** | [[file:gdpr.org][GDPR]] (2018), [[file:sox.org][SOX]] (2002), [[file:hipaa.org][HIPAA]] (1996), [[file:glba.org][GLBA]] (1999), [[file:basel-iii.org][Basel III]] (2010), [[file:fatf.org][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. | -| **Latent (undiscovered)** | [[file:oecd.org][OECD]] AI Principles, UN/CEFACT, [[file:world-bank-esf.org][World Bank ESF]], [[file:ifc-ps.org][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. | +| **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. | -See also: [[file:compliance-index.org][Compliance index]], [[file:revenue-table.org][Revenue table]], -[[file:../../ideas/verification-appliance.org][[[file:../verification-appliance.org][Verification appliance]]]], [[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]] +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. diff --git a/ideas/compliance/gdpr.org b/ideas/compliance/gdpr.org index 4662ba4..352658e 100644 --- a/ideas/compliance/gdpr.org +++ b/ideas/compliance/gdpr.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 513d5996-4ac7-4567-a992-18fc01599104 :ID: auto-gdpr :CREATED: [2026-05-23 Sat] :END: @@ -44,11 +45,11 @@ GDPR is the most extraterritorial and aggressively enforced privacy framework. The gate stack's principle of least privilege maps naturally to GDPR's data minimization requirement. Every data access is gated by a verified rule that states the purpose — the proof log is a built-in DPIA artifact. For the -[[file:compute-marketplace.org][compute marketplace]]: a provider processing proofs on EU users' gate data must +[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]: a provider processing proofs on EU users' gate data must maintain DPAs with all clients. Proof logs themselves may constitute personal data if they reference natural persons (names in access rules, etc.), creating a demand for privacy-preserving proof techniques. This is why the -[[file:domain-gate-packages.org][GDPR gate package]] includes data-processing agreement templates and +[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][GDPR gate package]] includes data-processing agreement templates and purpose-boundary gate rules that are independently verified by the provider's -[[file:evaluation-harness.org][evaluation harness]]. +[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]. diff --git a/ideas/compliance/glba.org b/ideas/compliance/glba.org index 07bcb0f..714b3be 100644 --- a/ideas/compliance/glba.org +++ b/ideas/compliance/glba.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 4a2bc62b-3f21-4212-9cd9-f9add8fc0be1 :ID: auto-glba :CREATED: [2026-05-23 Sat] :END: @@ -19,5 +20,5 @@ and directors personally liable. Why it matters: The Safeguards Rule maps directly to gate stack access controls. Every NPI access is gated; the proof log is the security program's evidence. First-mover advantage is narrow (GLBA is well-understood) but the market is -large because every financial institution that dodges [[file:hipaa.org][HIPAA]] still faces GLBA. +large because every financial institution that dodges [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] still faces GLBA. diff --git a/ideas/compliance/hipaa.org b/ideas/compliance/hipaa.org index e5e56d4..c19a6a6 100644 --- a/ideas/compliance/hipaa.org +++ b/ideas/compliance/hipaa.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f :ID: auto-hipaa :CREATED: [2026-05-23 Sat] :END: @@ -34,11 +35,11 @@ imprisonment). State AGs can also bring civil actions. ** Why it matters for the triad HIPAA is the largest single compliance market in US healthcare — every hospital, -clinic, insurer, and health-tech vendor must comply. The [[file:domain-gate-packages.org][HIPAA gate package]] +clinic, insurer, and health-tech vendor must comply. The [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][HIPAA gate package]] ($50K/yr) encodes the Privacy Rule and Security Rule as ACL2-verifiable gate constraints. Every PHI access attempt passes through the gate stack, producing a machine-checkable audit trail that satisfies the Security Rule's audit control requirement automatically. No separate logging infrastructure needed. Over a five-year deployment, the accumulated fact store and proof history create -[[file:infrastructure-lock-in.org][infrastructure lock-in]] — switching to a competitor means discarding all of it. +[[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] — switching to a competitor means discarding all of it. diff --git a/ideas/compliance/ifc-ps.org b/ideas/compliance/ifc-ps.org index 1efdc40..79f2f80 100644 --- a/ideas/compliance/ifc-ps.org +++ b/ideas/compliance/ifc-ps.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 68c55deb-72bf-4b15-ac28-bcc792057543 :ID: auto-ifc-ps :CREATED: [2026-05-23 Sat] :END: @@ -15,7 +16,7 @@ disbursement unless ESS5 resettlement plan is verified complete." First-mover advantage: World Bank compliance is entirely document-based (reports, audits, site visits). A verified gate system is unprecedented. -** IFC Performance Standards (PS) +** [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFC Performance Standards]] (PS) International Finance Corporation's standards for environmental and social sustainability in private sector investment. Eight standards: PS1 (risk diff --git a/ideas/compliance/ifrs.org b/ideas/compliance/ifrs.org index ad81940..57f6379 100644 --- a/ideas/compliance/ifrs.org +++ b/ideas/compliance/ifrs.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: fc736aec-ef53-4759-9787-62bc8deea2e7 :ID: auto-ifrs :CREATED: [2026-05-23 Sat] :END: @@ -23,4 +24,6 @@ most rule-complex — requiring actuarial models, expected credit loss calculati and contract classification algorithms. Who must comply: Publicly listed companies in 166 jurisdictions including the -EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most +EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most of Asia. IFRS 17 alone affects 5K+ insurers with complex actuarial compliance requirements that no automated verification solution currently addresses. + +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/irap.org b/ideas/compliance/irap.org index e7ac012..122b94f 100644 --- a/ideas/compliance/irap.org +++ b/ideas/compliance/irap.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 7f46764b-47b8-4892-a526-2c1b9ee6e6df :ID: auto-irap :CREATED: [2026-05-23 Sat] :END: @@ -9,14 +10,14 @@ ** IRAP (Infosec Registered Assessors Program) Australian government's cloud security assessment program — analogous to -[[file:fedramp.org][FedRAMP]]. Cloud services used by Australian government agencies must have an +[[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]. Cloud services used by Australian government agencies must have an IRAP assessment. Managed by the Australian Cyber Security Centre (ACSC). Assessment levels: Protected (highest), Secret (top secret), Unclassified DLM. Who must comply: Cloud providers selling to Australian federal, state, and local government agencies. Also critical infrastructure providers. -Why it matters: Like FedRAMP and [[file:ismap.org][ISMAP]], IRAP is a procurement gate. An IRAP +Why it matters: Like FedRAMP and [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]], IRAP is a procurement gate. An IRAP Protected-level assessment is expensive and takes 6-12 months. First-mover advantage: the gate stack's deterministic audit trail can be the primary evidence artifact, reducing assessment scope/cost. diff --git a/ideas/compliance/ismap.org b/ideas/compliance/ismap.org index 27a04f8..ca8f0c9 100644 --- a/ideas/compliance/ismap.org +++ b/ideas/compliance/ismap.org @@ -1,16 +1,17 @@ :PROPERTIES: +:ID: 085b76cc-4a65-4660-9c70-85aee10ca99e :ID: auto-ismap :CREATED: [2026-05-23 Sat] :END: #+title: ISMAP (Government Security Framework — Japan) #+filetags: :passepartout:compliance:framework:ismap: -is moderate — few non-Japanese vendors target [[file:appi.org][APPI]] specifically, and the 2022 +is moderate — few non-Japanese vendors target [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] specifically, and the 2022 amendments added requirements that created compliance gaps. ** ISMAP (Government Information System Security Management and Assessment Program) -Japan's government cloud security program — analogous to [[file:fedramp.org][FedRAMP]]. Cloud services +Japan's government cloud security program — analogous to [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]. Cloud services used by Japanese government agencies must be ISMAP-authorized. Managed by the Digital Agency and the Information-technology Promotion Agency (IPA). @@ -18,7 +19,7 @@ Who must comply: Cloud service providers selling to Japanese national and local government agencies. Why it matters: Like FedRAMP, ISMAP is a procurement gate. Authorization is -time-consuming and expensive. A [[file:../compute-marketplace.org][compute marketplace]] provider with ISMAP +time-consuming and expensive. A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with ISMAP authorization has exclusive access to the Japanese government market. First-mover advantage is significant — as of 2025, fewer than 100 services are ISMAP-registered. diff --git a/ideas/compliance/iso-27001.org b/ideas/compliance/iso-27001.org index b089b89..0e41bd9 100644 --- a/ideas/compliance/iso-27001.org +++ b/ideas/compliance/iso-27001.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: e2ab887d-9f28-4da6-8388-e6c035e9d9c5 :ID: auto-iso-27001 :CREATED: [2026-05-23 Sat] :END: @@ -27,5 +28,5 @@ A.16 incident management, A.18 compliance). First-mover advantage: the ISO binders). A gate stack that produces audit evidence automatically is not competing with other software — it is competing with binders. -** ISO 27701 (Privacy Information Management — PIMS extension to ISO 27001) +** [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] (Privacy Information Management — PIMS extension to ISO 27001) diff --git a/ideas/compliance/iso-27701.org b/ideas/compliance/iso-27701.org index 17ad5a2..4e8222e 100644 --- a/ideas/compliance/iso-27701.org +++ b/ideas/compliance/iso-27701.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 748b0cc7-7f42-49fb-8ee3-1ae49048a178 :ID: auto-iso-27701 :CREATED: [2026-05-23 Sat] :END: @@ -6,8 +7,8 @@ #+filetags: :passepartout:compliance:framework:iso: -International standard extending [[file:iso-27001.org][ISO 27001]] for privacy information management. -Aligns with [[file:gdpr.org][GDPR]] requirements. Provides a framework for PII (personally +International standard extending [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] for privacy information management. +Aligns with [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] requirements. Provides a framework for PII (personally identifiable information) controllers and processors. Why it matters: ISO 27701 bridges information security and privacy compliance. @@ -17,4 +18,4 @@ both standards from the same infrastructure. First-mover advantage: adoption is growing but still low (~1,000 certifications). Early gate package captures the growth market. -** Basel III (Bank for International Settlements — Basel Committee) +** [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III (Bank for International Settlements — Basel Committee)]] diff --git a/ideas/compliance/lfp-dppp.org b/ideas/compliance/lfp-dppp.org index c9ec450..7c0c134 100644 --- a/ideas/compliance/lfp-dppp.org +++ b/ideas/compliance/lfp-dppp.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: bafdaa23-de0b-444c-9151-c87ac65add32 :ID: auto-lfp-dppp :CREATED: [2026-05-23 Sat] :END: @@ -20,5 +21,5 @@ Why it matters: USMCA (US-Mexico-Canada Agreement) trade obligations are pushing toward privacy regime interoperability. A bilingual (Spanish/English) gate package covering both LFPDPPP and US frameworks serves the massive US-Mexico cross-border commerce market. First-mover advantage: LFPDPPP is -less automated than [[file:gdpr.org][GDPR]]; the market has fewer vendors and lower expectations. +less automated than [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]; the market has fewer vendors and lower expectations. diff --git a/ideas/compliance/lgpd.org b/ideas/compliance/lgpd.org index 1ceffc1..7631754 100644 --- a/ideas/compliance/lgpd.org +++ b/ideas/compliance/lgpd.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: c871a9f4-dd53-4e93-aa50-6acf0c606a9b :ID: auto-lgpd :CREATED: [2026-05-23 Sat] :END: @@ -7,7 +8,7 @@ Brazil's comprehensive privacy law (effective 2020, fines effective 2023). -Modeled on [[file:gdpr.org][GDPR]] but with differences: LGPD defines "data processing agents" +Modeled on [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] but with differences: LGPD defines "data processing agents" (controller and operator), requires appointment of DPO (data protection officer), mandates breach notification to ANPD (National Data Protection Authority) and affected data subjects. 10 legal bases for processing (vs 6 in GDPR). diff --git a/ideas/compliance/nis2.org b/ideas/compliance/nis2.org index 2ab7565..2a6b330 100644 --- a/ideas/compliance/nis2.org +++ b/ideas/compliance/nis2.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 748db16a-1382-4e5e-8812-a5d57a8de131 :ID: auto-nis2 :CREATED: [2026-05-23 Sat] :END: @@ -31,4 +32,4 @@ advantage is urgent — the transposition deadline is October 2025 (17 months). Organizations need gate packages now. No competitor has a declarative gate model that maps to NIS2 requirements. $50K/yr NIS2 gate package is a fast sell. -** EU AI Act +** [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] diff --git a/ideas/compliance/ny-dfs-500.org b/ideas/compliance/ny-dfs-500.org index 334edad..cee8c15 100644 --- a/ideas/compliance/ny-dfs-500.org +++ b/ideas/compliance/ny-dfs-500.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 581666ba-f72c-406b-8556-93876d2b30bf :ID: auto-ny-dfs-500 :CREATED: [2026-05-23 Sat] :END: @@ -23,3 +24,4 @@ verifiable evidence of control effectiveness — exactly what the gate stack produces. First-mover advantage is significant (few vendors target NY DFS 500 specifically) and the regulation is a template that other states are adopting. +Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]]. diff --git a/ideas/compliance/oecd.org b/ideas/compliance/oecd.org index b030e09..9468ea6 100644 --- a/ideas/compliance/oecd.org +++ b/ideas/compliance/oecd.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 022109ad-f031-44c4-8ea0-0b3c9402ca90 :ID: auto-oecd :CREATED: [2026-05-23 Sat] :END: @@ -17,7 +18,7 @@ approach. OECD Privacy Guidelines (revised 2013): Eight principles — collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, accountability. Non-binding but foundational -— the basis for [[file:gdpr.org][GDPR]], [[file:appi.org][APPI]], [[file:lgpd.org][LGPD]], and most other privacy laws. +— the basis for [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]], [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]], [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]], and most other privacy laws. OECD AI Principles (adopted 2019, updated 2024): Five values-based principles — inclusive growth and well-being, human-centered values and fairness, diff --git a/ideas/compliance/pipa.org b/ideas/compliance/pipa.org index b8701bb..fcbafa6 100644 --- a/ideas/compliance/pipa.org +++ b/ideas/compliance/pipa.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: e777064d-9950-42d5-980d-8c78cda91500 :ID: auto-pipa :CREATED: [2026-05-23 Sat] :END: @@ -21,7 +22,7 @@ against major tech companies. Class action lawsuits permitted. Who must comply: Any organization handling personal information of South Korean residents. Extraterritorial scope is broad and actively enforced. -Why it matters: PIPA is structurally similar to [[file:gdpr.org][GDPR]] but with stricter +Why it matters: PIPA is structurally similar to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] but with stricter enforcement and higher penalties relative to market size. The gate stack's purpose-boundary gates map directly to PIPA's purpose limitation requirement. First-mover advantage is large — PIPA has fewer compliance automation vendors diff --git a/ideas/compliance/privacy-act-aus.org b/ideas/compliance/privacy-act-aus.org index 3847649..6fc36a3 100644 --- a/ideas/compliance/privacy-act-aus.org +++ b/ideas/compliance/privacy-act-aus.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 834689e9-be0a-4822-9085-9b6b22294fd2 :ID: auto-privacy-act-aus :CREATED: [2026-05-23 Sat] :END: @@ -27,4 +28,4 @@ most defensible transparency artifact available. First-mover advantage: the reforms are being legislated now; early adoption positions the gate stack as the reference implementation. -** APRA CPS 234 (Prudential Standard — Information Security) +** [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234 (Prudential Standard — Information Security)]] diff --git a/ideas/compliance/quebec-law-25.org b/ideas/compliance/quebec-law-25.org index e57ed89..625f642 100644 --- a/ideas/compliance/quebec-law-25.org +++ b/ideas/compliance/quebec-law-25.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: f6a0c00e-e922-44af-99ce-6412c4b73745 :ID: auto-quebec-law-25 :CREATED: [2026-05-23 Sat] :END: @@ -13,7 +14,7 @@ verifiable audit trail — they are all document-based. ** Canadian provincial privacy (Quebec Law 25, Ontario PHIPA) Quebec Law 25 (2023-2024 phased) is Canada's most aggressive privacy -regulation — closer to [[file:gdpr.org][GDPR]] than PIPEDA. Requires: privacy officer appointment, +regulation — closer to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] than PIPEDA. Requires: privacy officer appointment, privacy impact assessments, consent modernization, data portability, right to de-index, algorithm transparency (automated decision-making disclosures). Penalties up to $25M CAD or 4% of global revenue. diff --git a/ideas/compliance/revenue-table.org b/ideas/compliance/revenue-table.org index 02ca7cf..dffccaf 100644 --- a/ideas/compliance/revenue-table.org +++ b/ideas/compliance/revenue-table.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 81a815ee-bf2b-4365-9894-b814e4196850 :ID: auto-revenue-table :CREATED: [2026-05-23 Sat] :END: @@ -9,39 +10,39 @@ | Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type | |-----------|--------|--------------|------------------|-------------------|---------------------|----------------| -| [[file:hipaa.org][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control | +| [[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 | -| [[file:gdpr.org][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent | -| [[file:fedramp.org][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring | -| [[file:sox.org][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls | -| [[file:glba.org][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy | -| [[file:ny-dfs-500.org][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls | -| CCPA/CPRA | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows | -| [[file:nis2.org][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain | -| [[file:eu-ai-act.org][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management | -| [[file:dora.org][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience | -| eIDAS 2.0 | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates | -| [[file:cra.org][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security | -| [[file:uk-gdpr.org][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy | -| [[file:appi.org][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy | -| [[file:ismap.org][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment | -| [[file:pipa.org][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent | +| [[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 | -| [[file:apra-cps-234.org][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls | -| [[file:irap.org][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment | -| [[file:dpdp-act.org][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent | -| [[file:lgpd.org][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy | -| LFPDPPP | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy | -| [[file:iso-27001.org][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls | -| [[file:iso-27701.org][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management | -| [[file:basel-iii.org][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy | -| [[file:fatf.org][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening | -| [[file:ifrs.org][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification | -| UN/CEFACT | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules | -| [[file:world-bank-esf.org][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates | -| [[file:ifc-ps.org][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates | +| [[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 [[file:../compute-marketplace.org][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP + +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. @@ -56,5 +57,11 @@ 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 also: [[file:compliance-index.org][Compliance index]], [[file:first-mover-window.org][First-mover window analysis]], -[[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]], [[file:../../ideas/compute-marketplace.org][Compute marketplace]] +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. diff --git a/ideas/compliance/soc2.org b/ideas/compliance/soc2.org index b7a63cb..aa8e6de 100644 --- a/ideas/compliance/soc2.org +++ b/ideas/compliance/soc2.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: ed65031c-cbd2-4ad2-bd53-a67791e183cd :ID: auto-soc2 :CREATED: [2026-05-23 Sat] :END: @@ -42,12 +43,12 @@ enterprise customers. Misrepresentation of certification status is fraud. ** Why it matters for the triad -SOC 2 is the entry-level certification for the [[file:compute-marketplace.org][compute marketplace]]. A provider +SOC 2 is the entry-level certification for the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. A provider needs SOC 2 Type II to sell compute to enterprises whose procurement policy requires audited vendors. The gate stack itself maps directly to the Security -criterion (access controls, audit trails) — the Passepartout instance's +criterion (access controls, audit trails) — the [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instance's deterministic gate log serves as the evidence artifact for the audit. No separate logging SIEM needed. This is the prerequisite to the larger -[[file:verification-monopoly.org][verification monopoly]] play — once enterprises trust the audit trail, they +[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] play — once enterprises trust the audit trail, they buy domain-specific gate packages for the same infrastructure. diff --git a/ideas/compliance/sox.org b/ideas/compliance/sox.org index 4013e4b..9260b94 100644 --- a/ideas/compliance/sox.org +++ b/ideas/compliance/sox.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: c9830152-0160-4bdc-ab03-6f308ad43536 :ID: auto-sox :CREATED: [2026-05-23 Sat] :END: @@ -23,5 +24,5 @@ that the external auditor needs for Section 404 attestation. First-mover advantage: SOX is mature (24 years old) but the audit market is $4B+ and entirely manual — no competitor has automated the evidence pipeline. -** GLBA (Gramm-Leach-Bliley Act) +** [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA (Gramm-Leach-Bliley Act)]] diff --git a/ideas/compliance/uk-gdpr.org b/ideas/compliance/uk-gdpr.org index 191c8a1..0420130 100644 --- a/ideas/compliance/uk-gdpr.org +++ b/ideas/compliance/uk-gdpr.org @@ -1,12 +1,13 @@ :PROPERTIES: -:ID: auto-uk-[[file:gdpr.org][gdpr]] +:ID: 9bc29937-d59a-4ae4-9623-3d17a1fe6ebb +:ID: auto-uk-[[id:513d5996-4ac7-4567-a992-18fc01599104][gdpr]] :CREATED: [2026-05-23 Sat] :END: #+title: UK GDPR (Post-Brexit Data Protection) #+filetags: :passepartout:compliance:framework:uk: -Post-Brexit, the UK maintains its own version of GDPR via the Data Protection +Post-Brexit, the UK maintains its own version of [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] via the Data Protection Act 2018. Substantively identical to EU GDPR but diverging over time. The UK has announced separate reforms targeting AI and digital identity. ICO (Information Commissioner's Office) enforces. Maximum fines: 17.5M GBP or 4% of global turnover. @@ -17,5 +18,5 @@ authority → ICO, DPA → equivalent UK contract clauses). The gate stack's ACL prover can verify that the UK version's rules are consistent with the EU version (and alert when they diverge). This is a concrete ACL2 application. -** NIS2 (Network and Information Security Directive) +** [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Network and Information Security Directive) diff --git a/ideas/compliance/un-cefact.org b/ideas/compliance/un-cefact.org index f74eec9..e82632c 100644 --- a/ideas/compliance/un-cefact.org +++ b/ideas/compliance/un-cefact.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 6a5884c8-e9b5-477e-bbf6-aa9ffd967739 :ID: auto-un-cefact :CREATED: [2026-05-23 Sat] :END: @@ -8,7 +9,7 @@ EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most of Asia and Africa. The US (GAAP) is the major holdout. -Why it matters: [[file:ifrs.org][IFRS]] 17 and IFRS 9 are algorithmically complex rule sets. +Why it matters: [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 and IFRS 9 are algorithmically complex rule sets. Getting an actuarial model or credit loss calculation wrong is a financial reporting error. The gate stack's ACL2 prover can verify that the calculation implementations match the standard's mathematical requirements. First-mover diff --git a/ideas/compliance/world-bank-esf.org b/ideas/compliance/world-bank-esf.org index 70cbe66..9381a04 100644 --- a/ideas/compliance/world-bank-esf.org +++ b/ideas/compliance/world-bank-esf.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 177aad72-5626-444d-a2e4-af8e1263b125 :ID: auto-world-bank-esf :CREATED: [2026-05-23 Sat] :END: @@ -10,7 +11,7 @@ transparency and explainability, robustness and safety, accountability. Non-binding but influential — the AI Act, Canada's AIDA, and Japan's AI guidelines all cite them. -Why it matters: The [[file:oecd.org][OECD]] frameworks are indirect revenue drivers. Regulatory +Why it matters: The [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] frameworks are indirect revenue drivers. Regulatory alignment with OECD principles is often a procurement requirement for international organizations and development finance institutions. First-mover advantage is about standard-setting: the gate package that maps to OECD diff --git a/ideas/compute-marketplace.org b/ideas/compute-marketplace.org index 8e0f982..7865324 100644 --- a/ideas/compute-marketplace.org +++ b/ideas/compute-marketplace.org @@ -1,18 +1,19 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 3c6b0449-a8fb-5b89-b82a-34efb21ef5b5 :END: #+title: Agora Compute Marketplace #+filetags: :passepartout:agora:revenue:compute:marketplace: -Passepartout instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the [[file:agora.org][Agora]] network. +[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] network. -The early player runs a large instance and sells compute to smaller instances. The AGPL allows this because the marketplace is a service, not a modification of the code. Revenue is a percentage of each compute transaction. +The [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Agora Infrastructure requirements]] define the network substrate this marketplace runs on. runs a large instance and sells compute to smaller instances. The AGPL allows this because the marketplace is a service, not a modification of the code. Revenue is a percentage of each compute transaction. But the question is structural: if every user runs their own Passepartout — each with the same symbolic engine, the same gate stack, the same ACL2 prover — why would they need to buy compute from anyone? The answer is that Passepartout's symbolic engine is /domain-specific/, not /generalized/. Local compute handles your daily gate stack (milliseconds per verification). The marketplace sells three things a local instance cannot produce: **1. Specialized proof libraries and search strategies.** ACL2 is a search — the prover tries strategies until something works. A fresh Passepartout has generic strategies (the default waterfall, basic arithmetic, simple induction). A provider who has run 10,000 medical-device ISO 13482 proofs has tuned rewrite rules, custom clause processors, cached lemmas, and known failure-mode workarounds for that domain. You don't want to rediscover those from scratch — you buy them as a burst compute transaction. The provider isn't selling raw CPU cycles; they are selling /the accumulated search strategy from every proof ever run in that domain/, pre-packaged as a service. Over time, your own Passepartout learns the patterns and needs less external compute, but the provider stays ahead because they aggregate proof experience from /every/ client in that domain. -**2. Certification weight for third-party trust.** Your Passepartout can prove "this gate rule is correct" to /you/. ACL2 produces a machine-checkable proof log — anyone can mechanically verify it. But when a hospital buyer evaluating a published HIPAA gate rule needs to know the rule satisfies the regulation, they do not care about your Passepartout's isolated run of the proof. They want the rule verified by a provider who: +**2. Certification weight for third-party trust.** Your Passepartout can prove "this gate rule is correct" to /you/. ACL2 produces a machine-checkable proof log — anyone can mechanically verify it. But when a hospital buyer evaluating a published [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rule needs to know the rule satisfies the regulation, they do not care about your Passepartout's isolated run of the proof. They want the rule verified by a provider who: - Carries errors-and-omissions insurance for the specific regulation - Submits to annual third-party audits - Maintains compliance documentation for the proof pipeline @@ -22,8 +23,8 @@ Your local instance cannot produce any of this. The provider's proof carries /re **3. Bootstrap verification for new instances.** A fresh Passepartout cannot verify its own initial state — the bootstrapping problem. You need a working system to generate the proof that the system is correct, but the proof refers to the system itself. The marketplace provides bootstrap proofs from existing trusted providers. Once verified, your instance stands on its own, but the initial self-certification requires an external prover that /already/ has a self-verified image. This is a one-time cost per instance (or per upgrade). -Secondary but real: burst capacity for heavy proofs (hours-long ACL2 conjectures you do not want tying up your daily agent's CPU), [[file:collective-regression-suite.org][collective regression suite]] execution (small instances contribute edge cases but cannot run the full suite on every change), and latency guarantees for time-critical gate verifications (trading, emergency shutdown). These are infrastructure economics — the same reason individuals buy cloud burst instances despite having their own hardware. +Secondary but real: burst capacity for heavy proofs (hours-long ACL2 conjectures you do not want tying up your daily agent's CPU), [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] execution (small instances contribute edge cases but cannot run the full suite on every change), and latency guarantees for time-critical gate verifications (trading, emergency shutdown). These are infrastructure economics — the same reason individuals buy cloud burst instances despite having their own hardware. If Passepartout instances on Agora transact billions of verified operations per day, the spread on compute transactions is enormous. This is not a product sale — it is a bet on network effects. Every new instance increases the value of the network (more capacity, more diversity, more resilience). -The early player that provisions the largest compute capacity on Agora becomes the default infrastructure provider for the entire network. This is venture-scale money. The compute marketplace is the engine that powers the [[file:verification-monopoly.org][verification monopoly]] — certified compute from trusted providers. Together with [[file:agora-usernames.org][Agora usernames]] and other Agora services, it forms the basis of the [[file:investment-thesis.org][investment thesis]]. +The early player that provisions the largest compute capacity on Agora becomes the default infrastructure provider for the entire network. This is venture-scale money. The compute marketplace is the engine that powers the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] — certified compute from trusted providers. Together with [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Agora usernames]] and other Agora services, it forms the basis of the [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]]. diff --git a/ideas/cost-structure.org b/ideas/cost-structure.org index cd80dbc..0df599d 100644 --- a/ideas/cost-structure.org +++ b/ideas/cost-structure.org @@ -1,14 +1,15 @@ :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:** [[file:gate-rule-encoding.org][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains) +- **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 [[file:sufficiency-flip.org][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only +- **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 Passepartout exploits. This is the core insight of [[file:lisp-economics.org][Lisp economics]] — symbolic verification costs approach zero while LLM token costs remain constant. +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. diff --git a/ideas/domain-gate-packages.org b/ideas/domain-gate-packages.org index 9b90fc0..e79eaee 100644 --- a/ideas/domain-gate-packages.org +++ b/ideas/domain-gate-packages.org @@ -1,17 +1,18 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: c34940cc-090e-57c4-8020-e78b1d32b96c :END: #+title: Domain Gate Rule Subscriptions #+filetags: :passepartout:revenue:gate-rules:compliance:subscription: -Pre-verified [[file:gate-rule-encoding.org][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. +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. -- [[file:compliance/hipaa.org][HIPAA]] package: $50K/yr -- [[file:compliance/soc2.org][SOC2]] package: $50K/yr -- [[file:compliance/gdpr.org][GDPR]] package: $50K/yr -- [[file:compliance/fedramp.org][FedRAMP]] package: $100K/yr +- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] package: $50K/yr +- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] package: $50K/yr +- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] package: $50K/yr +- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] package: $100K/yr - Combined enterprise: $250K/yr -Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[file:infrastructure-lock-in.org][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 [[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. -20 subscriptions in year one = $1M-$5M. These packages are verified using the [[file:verification-appliance.org][verification appliance]] and scored by the [[file:evaluation-harness.org][evaluation harness]]. +20 subscriptions in year one = $1M-$5M. These Each gate package wraps the Agora [[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]]. diff --git a/ideas/effects-growth-flywheel.org b/ideas/effects-growth-flywheel.org index 258306f..f2c5d62 100644 --- a/ideas/effects-growth-flywheel.org +++ b/ideas/effects-growth-flywheel.org @@ -1,11 +1,12 @@ :PROPERTIES: +:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2 :ID: effects-growth-flywheel :CREATED: [2026-05-23 Sat] :END: #+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other #+filetags: :passepartout:strategy:growth:effects:flywheel: -The [[file:triad-systemic-effects.org][effects page]] and the [[file:growth-strategy.org][growth page]] treated two sides of the same process as separate timelines. They are not sequential — effects do not wait for adoption to finish, and adoption does not happen before effects begin. They are interleaved at every scale. Each effect is a growth driver; each growth milestone unlocks new effects. +The [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][effects page]] and the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth page]] treated two sides of the same process as separate timelines. They are not sequential — effects do not wait for adoption to finish, and adoption does not happen before effects begin. They are interleaved at every scale. Each effect is a growth driver; each growth milestone unlocks new effects. The key insight: /every systemic effect is a growth engine for the next phase/. There is no phase where effects passively happen while adoption independently proceeds. @@ -27,7 +28,7 @@ At every scale, the effect /is/ the growth mechanism. There is no waiting for ef | Instance count | Effect that starts | Growth driver generated | |---------------+-------------------+------------------------| -| 1–10 | /Scientific reproducibility:/ the first verified paper | Universities buy Passepartout for their compute clusters | +| 1–10 | /Scientific reproducibility:/ the first verified paper | Universities buy [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] for their compute clusters | | 1–10 | /Compliance erosion:/ first enterprise replaces audit with gate rule | Competitors must match the cost savings — enterprise sales accelerate | | 10–50 | /Verification API gateway:/ first company runs LLM calls through Passepartout | /Any/ company using LLMs is a customer, not just triad adopters. This effect starts at 10 instances but can scale to millions of API users before growth Phase 1 | @@ -39,7 +40,7 @@ Key observation: the verified API gateway decouples the effect from triad adopti |-------+-------------------+------------------------| | 100–500 | /Regulation as code:/ first regulator encodes a rule as a gate | All regulated entities under that regulator must adopt Passepartout — step function in demand | | 500–2K | /AI safety shift:/ gate rule verification becomes expected in enterprise AI procurement | Every company buying AI services requires a proof log — API gateway demand explodes | -| 2K–10K | /Proof library compounding:/ the [[file:collective-regression-suite.org][collective regression suite]] has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage | +| 2K–10K | /Proof library compounding:/ the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage | Key observation: regulation-as-code creates a /step function/ in demand. Before the regulator acts, growth is organic enterprise sales. After, it is mandatory compliance. The timing of the first regulatory encode is the single most leveraged event in the flywheel. @@ -58,7 +59,7 @@ Key observation: the shift from enterprise adoption to consumer adoption is cult | Instance count | Effect that starts | Growth driver generated | |-------+-------------------+------------------------| | 1M–10M | /Insurance loop closes:/ premiums for unverified code are 10× verified | Economic necessity drives adoption — not engineering preference, not regulation, but /cost of doing business/ | -| 10M–100M | /Verification monopoly:/ regulator references the early player's gate library | New entrants cannot compete with the installed proof base — the moat compounds with every new instance | +| 10M–100M | /[[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]:/ regulator references the early player's gate library | New entrants cannot compete with the installed proof base — the moat compounds with every new instance | | 100M–1B | /Compute as geopolitical asset:/ nations run triad instances for digital sovereignty | Nation-state procurement — 100M to 1B happens via government mandate, not organic adoption | Key observation: the insurance loop is the /completion of the flywheel/. At this point, adoption is no longer driven by the triad's features or benefits — it is driven by the /cost of non-adoption/. The flywheel transitions from pull (people want verification) to push (people cannot afford to be unverified). @@ -69,7 +70,7 @@ The flywheel has two critical bottlenecks: 1. /First regulator encodes a rule as a gate./ This is the most leveraged event in Phase 0–1. It converts growth from organic to mandatory in a single domain. Whoever reaches a regulator first — and helps them write that first gate rule — wins that domain permanently. -2. /First insurer prices unverified code higher./ This is the Phase 2→3 transition. It converts growth from pull to push. The insurer does not need 1B instances to act — they need 10K instances with 2+ years of verifiable track records. The [[file:compute-marketplace.org][compute marketplace]] provides the actuarial data; the [[file:agora-contracts.org][attestation marketplace]] provides the reputation layer. +2. /First insurer prices unverified code higher./ This is the Phase 2→3 transition. It converts growth from pull to push. The insurer does not need 1B instances to act — they need 10K instances with 2+ years of verifiable track records. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provides the actuarial data; the [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][attestation marketplace]] provides the reputation layer. * Summary: Effects and Growth Are the Same Curve @@ -81,14 +82,14 @@ The flywheel has two critical bottlenecks: | 10⁴ → 10⁶ | Trust shifts from institutional to computational | Consumer adoption — cultural norm, not technical requirement | | 10⁶ → 10⁹ | Cost of non-verification exceeds cost of adoption | Insurance + regulation lock-in — economic necessity, not preference | -Each row's effect /is/ the growth driver for the next row's instance count. The flywheel is the product. The triad is the architecture. The verification monopoly is the steady state. +Each row's effect /is/ the growth driver for the next row's instance count. The flywheel is the product. The triad is the architecture. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] is the steady state. * References -- [[file:triad-systemic-effects.org][Systemic effects over time]] -- [[file:growth-strategy.org][Growth phases — zero to billions]] -- [[file:time-estimates.org][Development timeline]] -- [[file:revenue-hub.org][Revenue per phase]] -- [[file:compute-marketplace.org][Compute marketplace]] -- [[file:agora-contracts.org][Attestation and insurance]] -- [[file:verification-monopoly.org][Verification monopoly]] +- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]] +- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth phases — zero to billions]] +- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] +- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue per phase]] +- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Attestation and insurance]] +- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] diff --git a/ideas/evaluation-harness.org b/ideas/evaluation-harness.org index cab1939..b36b775 100644 --- a/ideas/evaluation-harness.org +++ b/ideas/evaluation-harness.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56 :END: #+title: Evaluation Harness as Certification Service @@ -10,8 +11,8 @@ The accumulated regression suite — thousands of edge cases from every deployed **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 [[file:collective-regression-suite.org][collective regression suite]] mechanism in action. +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. [[file:verification-monopoly.org][The verification monopoly]]. The certification relies on a [[file:verification-appliance.org][verification appliance]] to run the tests in a trusted environment, creating [[file:infrastructure-lock-in.org][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[file:moats.org][moats]]. +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]]. diff --git a/ideas/gate-rule-encoding.org b/ideas/gate-rule-encoding.org index 1d29137..c31676f 100644 --- a/ideas/gate-rule-encoding.org +++ b/ideas/gate-rule-encoding.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d :END: #+title: Gate Rule Encoding from Codified Domains @@ -14,4 +15,4 @@ ACL2 verifies the rule set for internal consistency. Screamer checks against exi 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 [[file:sufficiency-flip.org][sufficiency flip]] economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into [[file:domain-gate-packages.org][domain gate packages]] that can be reused across deployments. +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. diff --git a/ideas/growth-strategy.org b/ideas/growth-strategy.org index 59a0982..fc15702 100644 --- a/ideas/growth-strategy.org +++ b/ideas/growth-strategy.org @@ -1,11 +1,12 @@ :PROPERTIES: +:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f :ID: growth-strategy :CREATED: [2026-05-23 Sat] :END: #+title: Growth — Two Engines, One Infrastructure #+filetags: :passepartout:growth:network:strategy:agora: -The triad has two independent growth engines that share the same infrastructure. Logos (verification) grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[file:agora.org][Agora]] (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable. +The triad has two independent growth engines that share the same infrastructure. Logos (verification) grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable. This page defines the combined growth strategy across four phases, with each engine advancing in parallel and reinforcing the other at specific transitions. @@ -34,10 +35,10 @@ This page defines the combined growth strategy across four phases, with each eng *Growth lever:* Enterprise sales + direct integration. No network effects yet — value must be real without anyone else using it. *Tactics:* -1. Ship Passepartout MVP — verifies code, applies gate rules, produces compliance report. +1. Ship [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] MVP — verifies code, applies gate rules, produces compliance report. 2. First sale encodes a regulation as gate rules, verifies the customer's deployment. 3. Each engagement funds the next. Gate rule library grows with every customer. -4. The compute marketplace bootstraps with one provider (you) selling verification to smaller instances. +4. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] bootstraps with one provider (you) selling verification to smaller instances. *Revenue:* $2-12M from enterprise compliance engagements. Funds the team and the Agora build. @@ -124,9 +125,9 @@ This is the critical reinforcement point: *Growth lever:* Stoa premium enterprise features + insurance marketplace. *Tactics:* -1. [[file:stoa.org][Stoa]] premium ships SSO, compliance dashboards, fleet management. +1. [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] premium ships SSO, compliance dashboards, fleet management. 2. Insurance marketplace forms — actuaries price proof insurance based on track records of 10K+ instances. -3. Verification monopoly begins — the gate library is the largest, most cited, most battle-tested. +3. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] begins — the gate library is the largest, most cited, most battle-tested. *Revenue:* $50-200M. Stoa enterprise seats, verification appliances, insurance premiums. @@ -187,14 +188,14 @@ The crossover is automatic. Enterprise employees get DIDs from their company's P * References -- [[file:time-estimates.org][Development timeline]] -- [[file:revenue-hub.org][Revenue streams]] -- [[file:investment-thesis.org][Investment thesis]] -- [[file:alternative-growth-social-first.org][Social-first alternative (now integrated)]] -- [[file:agora-entry-strategy.org][Entry strategy — organized communities]] -- [[file:competitive-landscape-agora.org][Agora competitive landscape]] -- [[file:triad-systemic-effects.org][Systemic effects]] -- [[file:compute-marketplace.org][Compute marketplace]] -- [[file:verification-monopoly.org][Verification monopoly]] -- [[file:agora-contracts.org][Agora contracts]] -- Agora Protocol Specification — full requirements (spec repo at /tmp/agora) +- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] +- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]] +- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] +- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first alternative (now integrated)]] +- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]] +- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]] +- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects]] +- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] +- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]] +- The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Agora Social Space requirements]] define how organized communities interact through the gate stack. See also Agora Protocol Specification — full requirements (spec repo at /tmp/agora) — full requirements (spec repo at /tmp/agora) diff --git a/ideas/infrastructure-lock-in.org b/ideas/infrastructure-lock-in.org index e5ffb40..83439ee 100644 --- a/ideas/infrastructure-lock-in.org +++ b/ideas/infrastructure-lock-in.org @@ -1,16 +1,17 @@ :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 Passepartout with [[file:compliance/hipaa.org][HIPAA]] gate rules ($50K/yr) for five years has accumulated: +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 [[file:domain-gate-packages.org][domain packages]] are added. +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 [[file:moats.org][moat]]. The [[file:evaluation-harness.org][evaluation harness]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[file:verification-monopoly.org][verification monopoly]] and [[file:upgrade-lifecycle.org][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. +This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness (see the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Agora 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. diff --git a/ideas/investment-thesis.org b/ideas/investment-thesis.org index b4852cd..5d3341b 100644 --- a/ideas/investment-thesis.org +++ b/ideas/investment-thesis.org @@ -1,17 +1,20 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f :END: #+title: Investment Thesis #+filetags: :passepartout:economics:investment:thesis: -The early player benefits from every other instance of the triad. Every deployed instance feeds edge cases into the [[file:evaluation-harness.org][regression suite]], grows the [[file:compute-marketplace.org][compute marketplace]], and validates the hardware designs. Network effects are positive sum. +The early player benefits from every other instance of the triad. Every deployed instance feeds edge cases into the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][regression suite]], grows the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], and validates the hardware designs. Network effects are positive sum. Three revenue horizons: -- **Low-hanging fruit (year one, $2M-$12M):** [[file:verification-appliance.org][verification appliances]], [[file:domain-gate-packages.org][domain gate rule subscriptions]], [[file:evaluation-harness.org][evaluation harness certification]], migration services -- **Medium-term (1-3 years, $10M-$50M):** [[file:compute-marketplace.org][compute marketplace]], Relay Network, Lisp Machine hardware; [[file:agora-usernames.org][premium usernames]] ($10M/yr), [[file:pds-as-a-service.org][PDS hosting]] ($18M/yr) -- **Big money (3-10 years, $100M-$1B+):** [[file:verification-monopoly.org][verification monopoly]] (UL certification for AI), [[file:infrastructure-lock-in.org][infrastructure lock-in]], planetary compute marketplace +- **Low-hanging fruit (year one, $2M-$12M):** [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliances]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate rule subscriptions]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness certification]], migration services +- **Medium-term (1-3 years, $10M-$50M):** [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], Relay Network, Lisp Machine hardware; [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]] ($10M/yr), [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS hosting]] ($18M/yr) +- **Big money (3-10 years, $100M-$1B+):** [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] (UL certification for AI), [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]], planetary compute marketplace -The switching costs compound. The [[file:moats.org][network effects]] are positive sum. The market is nearly a trillion dollars. +The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] — token demand compression, GPU inference plateau, and the rise of CPU-native verification hardware — reshapes the trillion-dollar market these revenue streams depend on. -The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout." +The [[id:68ffa49f-f0d8-42cf-8b69-ae69de8bb815][Agora governance and physical assets]] requirements cover how the network manages shared infrastructure. The switching costs compound. The [[id:aa6d062e-a520-5d14-8773-00687ed9c689][network effects]] are positive sum. The market is nearly a trillion dollars. + +The defensible entity is "the organization that best understands how to adapt [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] to your domain" — not "the organization that owns Passepartout." diff --git a/ideas/legal-structure-alternatives.org b/ideas/legal-structure-alternatives.org index 906bfc2..c880c9e 100644 --- a/ideas/legal-structure-alternatives.org +++ b/ideas/legal-structure-alternatives.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 5ac2f037-fc3c-45ac-a6e8-acc20e005cb0 :ID: legal-structure-alternatives :CREATED: [2026-05-23 Sat] :END: @@ -43,7 +44,7 @@ Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organizatio ** Relevance to This Venture -The [[file:agora.org][Agora]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the Agora wants to be a legal entity — own a shared website domain, hold a pooled treasury, sign a contract with a vendor — they could incorporate as a Wyoming DAO LLC. The Agora's existing governance infrastructure (voting, constitutions, role management) becomes the DAO LLC's management mechanism. +The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the Agora wants to be a legal entity — own a shared website domain, hold a pooled treasury, sign a contract with a vendor — they could incorporate as a Wyoming DAO LLC. The Agora's existing governance infrastructure (voting, constitutions, role management) becomes the DAO LLC's management mechanism. ** This Is Not the OpCo or IP Co Structure @@ -114,7 +115,7 @@ A /domestic/ trust (South Dakota, Nevada) is under US court jurisdiction. A US c ** The Downsides of an Extremely Strong Structure -/1. Loss of Control./ An irrevocable trust means the assets are gone. You cannot change your mind. You cannot dissolve the trust. You cannot redirect the assets. This is the /price/ of asset protection. If the trust owns the BVI IP Co (which owns the Passepartout IP), you are a discretionary beneficiary of the trust, not the owner of the IP. The trustee makes decisions about the IP — not you. +/1. Loss of Control./ An irrevocable trust means the assets are gone. You cannot change your mind. You cannot dissolve the trust. You cannot redirect the assets. This is the /price/ of asset protection. If the trust owns the BVI IP Co (which owns the [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] IP), you are a discretionary beneficiary of the trust, not the owner of the IP. The trustee makes decisions about the IP — not you. /2. Banking and Financing Difficulty./ Banks scrutinize trust-owned structures. The BVI IP Co owned by a Cook Islands trust will require extensive KYC across four layers: you → trust → BVI Co → OpCo. Some US banks will refuse to open accounts. International banking is possible but time-consuming (3-6 months). @@ -157,6 +158,6 @@ Adding the trust earlier /does/ improve protection (the fraudulent conveyance lo * References -- [[file:legal-structure-practical-setup.org][Practical setup guide — Delaware C-Corp + BVI IP Co]] -- [[file:asset-protection-structures.org][Asset protection structures overview]] -- [[file:growth-strategy.org][Combined growth strategy]] +- [[id:433236a2-e5ad-41d4-a27e-4682f8bbc207][Practical setup guide — Delaware C-Corp + BVI IP Co]] +- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures overview]] +- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]] diff --git a/ideas/legal-structure-practical-setup.org b/ideas/legal-structure-practical-setup.org index 42ffdd6..05f403f 100644 --- a/ideas/legal-structure-practical-setup.org +++ b/ideas/legal-structure-practical-setup.org @@ -1,4 +1,5 @@ :PROPERTIES: +:ID: 433236a2-e5ad-41d4-a27e-4682f8bbc207 :ID: legal-structure-practical-setup :CREATED: [2026-05-23 Sat] :END: @@ -17,8 +18,8 @@ Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co). [BVI Business Company (IP Co)] │ owns the IP assets - (Passepartout code, gate rules, - ACL2 libraries, [[file:agora.org][Agora]] protocol + ([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules, + ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] protocol spec, trademarks, domain names) The OpCo pays the IP Co an arm's-length royalty for the right to use the IP in its business (compliance sales, PDS hosting, marketplace operations). The IP Co accumulates royalty income in a tax-neutral jurisdiction (BVI has 0% corporate tax). The founders own both entities under the same cap table. @@ -132,7 +133,7 @@ This is the most important document. It must: 4. /Territory:/ Global license, exclusive or non-exclusive. -5. /Sub-[[file:licensing.org][licensing]]:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing. +5. /Sub-[[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]]:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing. * Layer 3: Founders' Ownership @@ -199,6 +200,6 @@ The IP transfer must happen /before/ the IP has significant value. Incorporating * References -- [[file:asset-protection-structures.org][Asset protection structures — options analysis]] -- [[file:outbound-sales-compliance.org][Outbound sales compliance — data protection law]] -- [[file:growth-strategy.org][Combined growth strategy — Logos + Agora]] +- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]] +- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]] +- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Logos + Agora]] diff --git a/ideas/licensing.org b/ideas/licensing.org index cd6c2ce..b65fe2a 100644 --- a/ideas/licensing.org +++ b/ideas/licensing.org @@ -1,12 +1,13 @@ :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 [[file:patent-strategy.org][patent strategy]], this creates [[file:moats.org][moats]] against proprietary forks. +**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 [[file:pds-as-a-service.org][PDS as a service]] model where enterprises can run their own infrastructure. +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) diff --git a/ideas/lisp-economics.org b/ideas/lisp-economics.org index e33b4e0..177ebf8 100644 --- a/ideas/lisp-economics.org +++ b/ideas/lisp-economics.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 9af13fff-9725-542b-93b1-a555bc74ad72 :END: #+title: Why Lisp Is Economically Viable Now @@ -13,4 +14,4 @@ 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 [[file:verification-appliance.org][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 [[file:cost-structure.org][cost structure]] — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[file:self-driving-lisp-machine.org][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 [[file:biology-parallels.org][biology parallels]]. For the historical precedent, see the [[file:comparison-with-symbolics.org][comparison with Symbolics Genera]]. The [[file:ai-industry-impact.org][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 [[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. diff --git a/ideas/lisp-machine-security.org b/ideas/lisp-machine-security.org index 393424a..6333d13 100644 --- a/ideas/lisp-machine-security.org +++ b/ideas/lisp-machine-security.org @@ -1,16 +1,17 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b :END: #+title: Lisp Machine Security — Unified Memory Threat Model #+filetags: :passepartout:security:lisp-machine:pmp:isolation: -On a bare metal [[file:self-driving-lisp-machine.org][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them. +On a bare metal [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them. This note analyzes the threat model and proposes a hardware-enforced privilege separation within the single Lisp image. **The problem** -In the conventional layered model (Linux + SBCL + Passepartout), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it. +In the conventional layered model (Linux + SBCL + [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it. On a bare metal Lisp Machine, the model collapses: @@ -21,7 +22,7 @@ Everything (agent, editor, browser, shell, gate stack, ACL2) The only protection is that the gate stack is verified by ACL2 to be correct. But ACL2 verification is static — it proves properties about source code. At runtime, a memory corruption in the same image invalidates the entire proof. "All defense is symbolic" is exactly right. -**The solution: [[file:verification-appliance.org][hardware-enforced privilege zones]] within the Lisp image** +**The solution: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware-enforced privilege zones]] within the Lisp image** RISC-V provides three hardware privilege levels: M-mode (machine), S-mode (supervisor), and U-mode (user). Physical Memory Protection (PMP) enforces access control at the hardware bus level — it cannot be bypassed by software, even by code running in S-mode if configured in M-mode. The key: use these mechanisms to create zones within the shared Lisp address space. @@ -82,7 +83,7 @@ ACL2 trust problem. ACL2 verifies the gate stack. But ACL2 itself is ~50,000 lin The conventional Linux approach: TCB is ~28 million lines of C across kernel, drivers, and runtime. Defense in depth from many layers. But each layer adds attack surface. -The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[file:moats.org][moats]] — a competitor would need to match both the hardware isolation and the verified codebase. +The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor would need to match both the hardware isolation and the verified codebase. The fundamental trade: fewer layers, less depth, but each layer is simpler, smaller, and verified. A bug in the ECALL handler is catastrophic. A bug in the Linux kernel might be contained by seccomp or namespaces. The question is which is more likely: a bug in 500 lines of verified Lisp, or a bug in 28 million lines of C that is not contained by the remaining depth? @@ -92,7 +93,7 @@ But this is a single-point-of-failure architecture. If the ECALL handler holds, **Gaps in the current design** -None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[file:patent-strategy.org][patent strategy]]: +None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]]: 1. PMP region layout — exactly what is protected and by which region 2. ECALL handler specification — the exact interface, request types, validation logic, and error handling @@ -102,4 +103,6 @@ None of this is in the architecture documents. The following are not yet specifi 6. Side-channel mitigation — speculation control, timing attacks 7. ACL2 trust documentation — the bootstrap chain and what it means for the gate stack's verification 8. The boot attestation protocol — how the gate core verifies the gate stack before loading it -9. Zone transition costs — how many cycles does an ECALL take, and does that affect the 10-80-10 ratio +9. +See the [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Agora Identity specification]] for how user identity, key derivation, and DID management integrate with the gate stack's boot chain and privilege zones. + — how many cycles does an ECALL take, and does that affect the 10-80-10 ratio diff --git a/ideas/moats.org b/ideas/moats.org index 092a40d..ea8086e 100644 --- a/ideas/moats.org +++ b/ideas/moats.org @@ -1,17 +1,18 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: aa6d062e-a520-5d14-8773-00687ed9c689 :END: #+title: Competitive Moats #+filetags: :passepartout:economics:moats:competition: -Re-evaluated: time is not the primary moat. A Phase 4+ Passepartout fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge. +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. **Actual moats (weaker than initially assumed):** 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. **[[file:evaluation-harness.org][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat. -4. **[[file:infrastructure-lock-in.org][Infrastructure integration]]** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different. +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. **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 [[file:verification-monopoly.org][verification monopoly]] on agent safety would change this calculus — competitors would need independent certification. [[file:patent-strategy.org][Patent strategy]] and [[file:licensing.org][Licensing]] protect key innovations and create revenue from the open-source ecosystem. +**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. diff --git a/ideas/native-org-knowledge-base.org b/ideas/native-org-knowledge-base.org index 4647049..b895e5c 100644 --- a/ideas/native-org-knowledge-base.org +++ b/ideas/native-org-knowledge-base.org @@ -7,7 +7,7 @@ ** What -Passepartout should be able to use Org-mode files directly as its +[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] should be able to use Org-mode files directly as its knowledge base — no pandoc conversion, no markdown intermediary. Currently gbrain provides vector search + entity linking over markdown, @@ -76,6 +76,8 @@ The short-term bridge (current) is gbrain with nightly org→md sync. This is adequate while the gate stack and planner are the priority. The native org module replaces gbrain entirely once built. -** See also -[[file:../../concepts/compliance-framework-mapping.org][[[file:compliance-framework-mapping.org][Compliance framework mapping]]]] -[[file:../../ideas/passepartout-economics.org][[[file:passepartout-economics.org][Passepartout economics]]]] +The nightly pipeline uses gbrain to provide hybrid search across the existing +org files. The [[id:36e5b948-e07b-477f-9036-4dfe88254347][compliance framework mapping]] is the largest single +dataset this would serve, and the broader +[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics]] knowledge base demonstrates the value of +native org querying at scale. diff --git a/ideas/orders-of-magnitude-time.org b/ideas/orders-of-magnitude-time.org index 7c8bb6f..08fd317 100644 --- a/ideas/orders-of-magnitude-time.org +++ b/ideas/orders-of-magnitude-time.org @@ -2,6 +2,7 @@ #+filetags: :passepartout:framework:time:scale:hierarchy: :PROPERTIES: +:ID: 2cdca4b0-6b41-44b4-acb0-af21d0e27b00 :ID: orders-of-magnitude-time :CREATED: [2026-05-23 Sat] :END: @@ -17,7 +18,7 @@ The hierarchy: | Days | Shippable thing, momentum building | Next day | Drift, distraction | | Weeks | Sprint, feature, market pulse | One cycle | Wrong direction | | Months | Product cycle, hiring, traction | One data point | Bleeding out slow | -| Years | Company, [[file:moats.org][moats]], technology shifts | Scarce | Irrelevance | +| Years | Company, [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]], technology shifts | Scarce | Irrelevance | | Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility | Practical use: @@ -26,4 +27,4 @@ When planning anything, identify which order of magnitude you're operating in Common mistake: treating a months/years problem as if it can be solved in days/weeks (startup hype, premature optimization) or a minutes problem as if it deserves weeks of deliberation (analysis paralysis, bikeshedding). -See also: [[file:time-estimates.org][Time estimates]] applies this framework to Passepartout's development timeline. +The [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Time estimates]] page applies this framework to [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s development timeline. diff --git a/ideas/outbound-sales-compliance.org b/ideas/outbound-sales-compliance.org index 0b04e9e..e8af002 100644 --- a/ideas/outbound-sales-compliance.org +++ b/ideas/outbound-sales-compliance.org @@ -1,11 +1,12 @@ :PROPERTIES: +:ID: 98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b :ID: outbound-sales-compliance :CREATED: [2026-05-23 Sat] :END: #+title: Outbound Sales — Legal Framework & Compliance Architecture #+filetags: :passepartout:compliance:legal:gdpr:outbound: -The outbound sales pipeline touches leads across multiple jurisdictions. This page maps the applicable laws, the compliance requirements at each stage of the pipeline, and how Passepartout's gate stack can enforce them mechanically. +The outbound sales pipeline touches leads across multiple jurisdictions. This page maps the applicable laws, the compliance requirements at each stage of the pipeline, and how [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack can enforce them mechanically. This plan defers to Passepartout maturity — it scopes what needs to be built and what can be done now without automation. @@ -32,9 +33,9 @@ Penalties: $46,517 per violation. Criminal penalties for harvesting + sending. - Gate: /unsubscribe-link/ — every message must carry a working opt-out - Gate: /no-harvesting/ — if contact was sourced via automated scraping, flag for review -** EU/EEA — GDPR (2018) +** EU/EEA — [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018) -/Applies to:/ Processing personal data of data subjects in the EU, regardless of where the controller is established. [[file:compliance/gdpr.org][GDPR]] has extraterritorial reach (Article 3). +/Applies to:/ Processing personal data of data subjects in the EU, regardless of where the controller is established. [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] has extraterritorial reach (Article 3). Relevant requirements: 1. /Lawful basis required for processing./ Cold email to a corporate address may use "legitimate interest" (Article 6(1)(f)) or "consent" (Article 6(1)(a)). For B2B cold email to professional addresses, legitimate interest is the standard basis — but must balance against the recipient's rights. @@ -54,7 +55,7 @@ Penalties: Up to 20 million EUR or 4% of global annual turnover, whichever is hi - Gate: /erasure-compliance/ — maintain an erasure queue with 30-day SLA - Gate: /data-minimization/ — reject leads with unnecessary enrichment data -** UK — UK GDPR + PECR +** UK — [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] + PECR /Applies to:/ Data subjects in the UK. @@ -127,6 +128,6 @@ The automation waits on Passepartout — but the legal foundation and the infras - CAN-SPAM Act (15 U.S.C. 7701-7713) - GDPR (Regulation (EU) 2016/679) -- [[file:compliance/uk-gdpr.org][UK GDPR]] + PECR (SI 2003/2426) +- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] + PECR (SI 2003/2426) - Egypt PDPL (Law No. 151 of 2020) - CASL (S.C. 2010, c. 23) diff --git a/ideas/passepartout-economics.org b/ideas/passepartout-economics.org deleted file mode 100644 index 6dc9640..0000000 --- a/ideas/passepartout-economics.org +++ /dev/null @@ -1,1667 +0,0 @@ -#+TITLE: Passepartout — Economics (monolithic archive) -#+AUTHOR: Hermes agent distillation of 2026-05-21 discussion with Amr -#+FILETAGS: :passepartout:agent:economics:ip:licensing:archive: -#+STARTUP: content - -This file has been replaced by an interlinked knowledge base. See -[[file:index.org][the new structure]] — 27 nodes with org-roam style cross-references. - -Nodes: -- [[file:passepartout-economics.org][Index/hub]] -- [[file:triad-overview.org][Triad overview]] • [[file:agora.org][Agora]] • [[file:stoa.org][Stoa]] -- [[file:investment-thesis.org][Investment thesis]] -- [[file:verification-appliance.org][Verification appliance]] • [[file:domain-gate-packages.org][Domain gate packages]] • [[file:evaluation-harness.org][Evaluation harness]] -- [[file:agora-usernames.org][Agora usernames]] • [[file:pds-as-a-service.org][PDS as a service]] • [[file:compute-marketplace.org][Compute marketplace]] -- [[file:verification-monopoly.org][Verification monopoly]] • [[file:infrastructure-lock-in.org][Infrastructure lock-in]] -- [[file:ai-industry-impact.org][AI industry impact]] • [[file:lisp-economics.org][Lisp economics]] -- [[file:self-driving-lisp-machine.org][Self-driving Lisp Machine]] • [[file:time-estimates.org][Time estimates]] -- [[file:sufficiency-flip.org][Sufficiency flip]] • [[file:upgrade-lifecycle.org][Upgrade lifecycle]] -- [[file:patent-strategy.org][Patent strategy]] • [[file:licensing.org][Licensing]] • [[file:moats.org][Moats]] -- [[file:cost-structure.org][Cost structure]] • [[file:gate-rule-encoding.org][Gate rule encoding]] -- [[file:verified-skill-marketplace.org][Verified skill marketplace]] -- [[file:biology-parallels.org][Biology parallels]] • [[file:comparison-with-symbolics.org][Symbolics comparison]] - -* Summary - -Discussion about the economic and strategic implications of Passepartout's -architecture — a self-bootstrapping agent that combines deterministic safety -gates (0 LLM tokens per verification), Merkle-tree memory with provenance, -a symbolic fact store with sufficiency criterion, and ACL2-based macro layer -bootstrapping for provable reasoning. - -The central claim: this architecture decouples intelligence from LLM API -consumption. The probabilistic engine (LLM) handles ~10% input/output -translation; the symbolic engine handles ~80% of reasoning at near-zero -marginal cost. The cost curve inverts: generation is expensive, verification -is cheap. - -* Patentability - -** Likely patentable - -- **Probabilistic-deterministic split with deterministic gates between LLM - proposal and execution.** The LLM proposes, the gate stack decides. Each - gate is a pure Lisp function costing 0 LLM tokens. Every competitor uses - prompt-based guardrails. The specific 11-vector gate stack (secret - exposure, path protection, self-build boundary, shell safety, network - exfiltration, privacy tags, Lisp syntax, credential vault, tool permissions, - policy, protocol validation) is a specific novel implementation. - -- **Foveal-peripheral context model with Org-tree structured retrieval.** - Depth ≤ 2 always; full render on foveal node; full render on semantic - similarity to foveal; full render on temporal relevance (modified today, - upcoming deadlines); everything else title-only. Targets 2,000-4,000 tokens. - No agent does this. - -- **Merkle-tree memory with copy-on-write snapshots and operation-level - undo/redo.** Every memory-object is content-addressed. Snapshots are - deep-copies. Undo/redo at the individual operation level. Applied to an - agent's reasoning loop. - -- **Gate-to-fact bootstrap with sufficiency criterion.** Mechanically - extracting facts from the gate stack's own data structures (protected paths, - shell blocked patterns, network whitelist) as the seed of an ontology. A - measurable sufficiency threshold that flips the system from LLM-proposes - to Screamer-deduces. - -- **Macro-layer-as-skill bootstrapping architecture.** Encoding theorem-proving - capability as hot-reloadable skills where each layer is verified by the layer - below. The proof forest is a Merkle-versioned dependency tree. - -** Likely not patentable (known techniques in expected applications) - -- ACL2 itself (decades old) -- Screamer for consistency checking (constraint solving on a triple store is - an obvious application) -- Hot-reloadable skills (Lisp images have been hot-reloadable for 40 years) -- Org-mode as a data format -- Multi-layer signal authentication (known in network security) - -** Counterargument from prior art - -A patent examiner will argue that: -- "Thin harness, fat skills" is the standard OS microkernel architecture - applied to an AI agent -- Foveal-peripheral context is locality of reference (standard in OS design) -- Merkle-tree memory is content-addressed storage (standard in distributed - systems) -- Deterministic gate stack is capability-based security (going back to - KeyKOS in the 1980s) - -The defense: these principles have never been *combined* in an AI agent, and -the combination produces emergent effects (cost curve inversion, sufficiency -flip, self-repairing bootstrapping chain) that no single principle produces -alone. Good patent claims would cover the specific combination, not the -individual components. - -** Strongest single claim - -An AI agent system comprising: -1. A probabilistic language model -2. A stack of deterministic safety gates operating at zero LLM-token cost - between the model's proposal and execution -3. A Merkle-versioned memory store from which gate outcomes are mechanically - extracted as facts -4. A symbolic reasoning engine seeded by those facts with a measurable - sufficiency criterion that determines when the probabilistic model can - be bypassed - -Each element is known. The combination is novel and non-obvious. - -* Licensing Strategy - -** AGPLv3 for the public repository - -AGPLv3 closes the ASP loophole (Section 13): anyone who modifies the -software and offers it over a network must release their modified source. -This protects against proprietary forks that extract value without -contributing back. - -Crucially: AGPL is a *product requirement*, not a concession to openness. -The system's value proposition is provable correctness — every decision has -Merkle provenance, the proof forest is visible, the sufficiency meter is -readable. 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 is sound. AGPL makes this -possible without signing an NDA. - -** 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, and community -- Commercial license for enterprises that cannot accept AGPL (blanket - policies against AGPL infection) — MySQL/SugarCRM/GraphQL model - -* Moats - -** Re-evaluated: time is not the primary moat - -Initial assumption: the bootstrapping chain (gate outcomes → facts → -Screamer rules → ACL2 theorems → macro layers) takes months to build, -giving first-mover advantage. - -Challenge: a Phase 4+ Passepartout fed on Wikipedia + Wikidata can build -a general ontology in two weeks. Entity resolution is batch work. Structural -consistency verification is minutes. The organic growth advantage collapses -for general knowledge. - -** Actual moats (weaker than initially assumed) - -1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data - encoding deployment-specific path patterns, shell safety rules, and - volume layouts. Write once, trivial to copy. Not a real moat. - -2. **Empirical decision history** — every HITL decision is a Merkle fact. - "On date T, user approved action X under context Y." A fresh instance - has none of this. Makes *your* instance more valuable but doesn't - prevent competition — it's a switching cost, not a barrier to entry. - -3. **Evaluation harness (regression suite)** — thousands of test cases - accumulated from every bug fix. Cannot be ingested from public data. - Built only by using the system, breaking it, fixing it, and adding a - test. Strongest residual moat, but even this can be partially - compressed through public benchmarks (SWE-bench, etc.). - -4. **Infrastructure integration** — the specific Docker compose layouts, - Traefik router patterns, Authentik provider configurations, backup - policies encoded as gate rules over months of use. A competitor's - infrastructure is different; their generic Passepartout does not know - your topology. - -** Strongest competitor strategy - -Not copying your gate rules — offering the same architecture as a service -with their own pre-seeded general knowledge, a generic safety baseline, -and a consulting engagement to customize gate rules for each customer. -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." The Lisp Machine appliance (hardware + certification) and -evaluation harness certification service are the closest thing to product -defensibility. - -* Economics and Monetization - -** Cost structure - -- One-time cost: gate-rule encoding for a domain (from hours for codified - domains — FAR, [[file:compliance/hipaa.org][HIPAA]], ISO standards — up to months for tacit domains) -- The LLM translates codified rules directly: ingest regulation → produce - gate rule plist → ACL2 verifies consistency → human reviews. This is - translation, not reasoning. -- For non-codified knowledge (craft expertise, organizational culture): - Phase 3 archivist loop over time -- 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 sufficiency flip: pennies per day vs dollars per day for LLM-only - -** Revenue models by field - -| Field | Why Passepartout | Revenue Model | -|-------+------------------+---------------| -| Industrial infrastructure (refineries, power grids, manufacturing) | Offline operation, provably safe, near-zero marginal cost, mandatory audit trail | Lisp Machine appliance + SCADA certification package | -| Healthcare administration (billing, claims, prior authorization) | Rule-heavy domain, privacy-mandated, audit-driven, high per-transaction cost today | Subscription for regulatory gate packages (CPT/ICD-10/HIPAA rules), updated when CMS publishes new rules | -| Software supply chain (CI/CD security, SBOM verification) | First-order structural verification — ACL2 is natural fit, CI/CD pipeline is already a sequence of gate-checkable steps | Evaluation harness as certification service — "run our 10,000-task suite and get a provable score" | -| Regulatory compliance ([[file:compliance/gdpr.org][GDPR]], [[file:compliance/soc2.org][SOC2]], [[file:compliance/sox.org][SOX]], GxP) | Rule-completeness, active enforcement (not document-based), provable audit trail | Subscription for regulation-specific gate packages — GDPR package, SOC2 package, [[file:compliance/fedramp.org][FedRAMP]] package, updated when regulations change | -| Defense and classified environments | Air-gapped operation, classification-level gate rules, Merkle provenance is court-admissible evidence | Government contract + hardened appliance with hardware root of trust | - -** Critical insight: encoding cost drops to near-zero for codified domains ** - -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 of -"thou shalt" and "thou shalt not" statements. 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 then verifies the rule set for internal consistency (Phase 6). 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* in the -way Phase 3 archivist does (which is open-ended, noisy, requires grounding). -It is *translating a known rule system into a formal representation* — a -mechanical transformation of structured text into structured rules. The -result is not "the LLM's best guess at the rules" but "the rule set as -stated in the source document, mechanically transcribed." - -For domains where the knowledge is codified as text, the gate-rule encoding -time drops from weeks to hours. The only bottleneck is human review of the -output — and the system can assist here by surfacing contradictions for -resolution rather than requiring a full line-by-line audit. - -** What can actually be monetized (TLDR) - -1. **Pre-loaded bootstrapping chains for specific verticals** — domain gate - rules, pre-seeded fact stores, mature proof forests. Saves the buyer - months of bootstrapping. Distributed as data packages under commercial - license, not AGPL. - -2. **Evaluation harness as certification service** — "Bring your agent, - we'll run it through our suite and give a Merkle-verified score." - The regression suite grows with every deployment; a competitor's - regression suite starts empty. - -3. **Hardened Lisp Machine appliance** — RISC-V soft-core with Lisp - microcode, pre-loaded mature Passepartout, certified for specific - verticals (IEC 62443 for industrial, HIPAA for healthcare). Value is - in integration and certification, not the AGPL software. - -4. **Verified skill marketplace** — marketplace where skills are verified - (sandbox + ACL2 non-contradiction proof) before listing. Marketplace - takes a cut. Value is in the verification infrastructure, not the - skills themselves. - -5. **Support and consulting** — the Red Hat model. AGPL code is free; - training, custom gate rules, ontology design, and emergency support - are paid. - -* Design and Architectural Implications - -** The self-improving system - -Passepartout bootstraps two feedback loops: - -- **Empirical loop:** gate outcomes → facts → Screamer-verified patterns → - sufficiency flip → auto-extraction. Knowledge grows without the LLM - touching most of it. - -- **Logical loop:** ACL2 theorems → macro layers (generators, metafunctions, - induction DSL, abstract theories) → richer proof strategies → better - verification. Reasoning capacity grows without changing the prover binary. - -These loops intersect at the fact store: proven theorems become facts, richer -facts generate better proof strategies, better strategies verify more facts. -The system upgrades itself. - -** The 10-80-10 becomes approximately true - -- 10%: LLM handles input translation (natural language → structured goal) - and output formatting (structured result → natural language) -- 80%: Symbolic engine handles reasoning — Screamer plans, ACL2 verifies, - VivaceGraph retrieves facts. Zero LLM tokens. -- The cost curve inverts: verification is cheaper than generation. - -** Key implications - -1. **Verification becomes cheaper than generation.** Once macro layers are - mature, proving a new rule non-contradictory costs near-zero. The LLM - proposes; the symbolic engine accepts or rejects. - -2. **Trust scales with use.** Every interaction produces a structurally - verified outcome. Non-lossy fact base grows. Proof forest thickens. An - auditor can inspect the Merkle tree of gate outcomes and trace any - decision to its root theorem. - -3. **Degradation is reversible.** Every proof layer is a hot-reloadable - skill. Every fact has provenance. A bad metafunction is unloaded; - theorems proven under it are flagged for re-verification; the fact - store retains the pre-upgrade ontology version. - -4. **The system can diagnose its own logical frontier.** If ACL2 keeps - failing on a class of properties, and the failure mode is structural - (not solvable by more macros), the fact store accumulates a pattern: - "These N properties are first-order inexpressible." This signals the - human: the system needs a CIC prover (dependent types) for this domain. - The system cannot transcend its logic without external intervention — - but it can surface the boundary precisely. - -** The Lisp Machine endpoint - -If the system designs and builds itself on Lisp Machine hardware: -- The same system that proves theorems also optimizes the microcode -- No OS boundary, no driver layer — system and proof environment are one -- A RISC-V soft-core with Lisp microcode is manufacturable at older fab - nodes (28nm, 45nm) — sovereign intelligence without GPU supply chains - -** Social implications - -- **Concentration of reasoning.** The macro layers become opaque to anyone - who doesn't understand the bootstrapping history. The system understands - its own reasoning better than its users do. - -- **Cost advantage widens inequality asymmetrically.** The first instance - to reach maturity requires significant gate-rule design (from hours for - codified domains to months for tacit ones). After that, replication is - cheap. Organizations that invest early have a permanent cost advantage - over those that wait for a turnkey product. - -- **Sovereign artifact.** A self-building system on its own hardware does - not depend on cloud APIs, GPU supply chains, or proprietary model - weights. Its intelligence is generated, verified, and sustained locally. - Enables sovereign AI for nations without GPU access. - -* Open Questions - -1. Can CIC (dependent type theory) be implemented as a Passepartout skill, - verified for crash-freedom and rule fidelity by ACL2, and integrated - into the existing fact store API? The Gödelian boundary: ACL2 can - verify the kernel's implementation but not its soundness in any - absolute sense — but this matches current practice (Lean 4's ~500 line - C++ kernel is trusted, not proved). - -2. Can the system generate novel proof strategies? A sufficiently rich - abstract theory layer + Screamer could propose: "Proofs in domain X - all use induction schema Y. Generalizing to Z would prove new - properties across A, B, C." The LLM translates to a metafunction; - ACL2 verifies it; the prover gains a new tactic invented by itself. - -3. What is the social contract for a system that can truthfully say - "I know this is correct" — and "I know what I don't know"? - Most current AI systems can do neither. - -* Impact on the AI and GPU Industry - -If a symbolic-bootstrapping architecture becomes popular — especially now -that codified domains can be ingested at near-zero encoding cost — the -industry structure shifts fundamentally. - -** Token demand compresses - -The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is -built on per-token pricing: metered cognition. A mature Passepartout -reduces token consumption to the unfamiliar 10% I/O boundary. 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. - -** GPU inference demand plateaus in regulated industries - -GPU inference is driven by two things: training and per-request inference. -Training demand is unaffected (frontier models still train on clusters). -Inference demand drops 80-90% in any sector where the rule book is -published — which covers most economically significant sectors (finance, -healthcare, industrial, government procurement, legal compliance). - -Nvidia's growth narrative shifts from "every transaction goes through a -GPU" to "every training run needs a GPU, and the generative 20% needs -inference." A smaller inference TAM than current market pricing assumes. - -** Hyperscaler competition shifts - -The competitive thesis "AI is the next OS, and we own the compute layer" -weakens if the most valuable AI workloads run on a $500 RISC-V board on -your premises. The hyperscalers respond by: -- Offering Passepartout as a managed service (AGPL allows this) -- Differentiating on the frontier I/O API and world model API -- Competing on gate rule libraries for specific industries - -The race shifts from "who has the most H100s" to "who has the best -domain-specific gate rules." Google's industry data advantage matters -more than Azure's raw compute. - -** New hardware tier: verification appliances - -A new category emerges: CPU-native verification appliances running a Lisp -microcode on RISC-V cores. Low volume (hundreds of thousands/year), -high margin ($5K-50K/unit), high switching costs. The Sun Microsystems -model, not the Intel model. Manufacturable at older fab nodes (28nm, -45nm) — no dependency on TSMC's leading edge. - -** The key uncertainty and its resolution - -Original question: how long does gate-rule encoding take? - -Resolution: for codified domains, near-zero. The LLM translates published -regulations into formal rules in one pass — it is a mechanical transformation, -not open-ended reasoning. The bottleneck only exists for tacit, oral, unwritten -knowledge (craft expertise, organizational culture). - -Consequence for the transition timeline: Phase 2 (sufficiency) happens -within months for any domain whose rule book is published. The disruption -accelerates from years to quarters. - -* Broader Insights - -** The historical fork: why C won economically in the 1980s - -C won because the economics of 1980s hardware made Lisp's overhead -unaffordable: - -- **Memory cost.** DRAM was ~$5,000/MB in 1980. Lisp's runtime (SBCL today - is ~40MB) was unthinkable. C's runtime fit in 64KB. -- **CPU speed.** 1-10MHz. Every instruction counted. Lisp's GC, type dispatch, - and dynamic allocation consumed cycles that C spent on actual work. -- **Software scale.** Programs were thousands of lines, not millions. A single - developer could hold the entire program in their head and verify correctness - by reading it. Testing was sufficient. Formal verification was unnecessary - overhead. -- **Market dynamics.** The PC market was expanding exponentially. Speed to - market, volume, and unit cost mattered more than correctness. A buggy $500 - PC sold more units than a correct $50,000 Lisp Machine. -- **Hardware ecosystem.** RISC (reduced instruction set) was the revolution. - Simpler chips, higher clock speeds, cheaper fabrication. RISC CPUs are - optimized for C's execution model because C was the dominant systems - language when RISC was designed. - -Lisp lost not because it was worse, but because the market optimized for -a different axis: raw throughput per dollar, not correctness per line. - -** What changed to make Lisp viable now - -Four transformations flipped the economics: - -1. Memory is free. 40MB runtime is noise on a $20 Raspberry Pi with 8GB - RAM. The cost of the runtime is now zero at any relevant scale. - -2. Transistors are free. A modern ARM Cortex-A72 has billions of - transistors. The GC, type dispatch, and dynamic dispatch that Lisp - needs are executed in dedicated silicon within the CPU — they cost - nothing because the transistors are there whether used or not. - -3. Software complexity saturates human verification. Systems are now - tens of millions of lines. No single person can hold them in their - head. Testing is necessary but insufficient — zero-day vulnerabilities - prove that bugs survive all testing. Formal verification is no longer - overhead; it is the only known path to correctness at this scale. - -4. The cost of failure is now higher than the cost of verification. A - single breach costs millions. A compliance failure shuts down a - factory. Regulation (GDPR, SOX, HIPAA, FedRAMP) mandates provable - compliance. The cost of proving correctness is now cheaper than the - cost of not proving it. - -** The key insight - -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. - -This is the inversion Passepartout exploits: the 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. The 1980s math said Lisp was too expensive at any price. -The 2020s math says Lisp is the only affordable option. - -The remaining question is not whether the economics flipped — it's whether -anyone builds the bridge from today's AGPL software to tomorrow's -verification appliance. Passepartout is that bridge. - -** Distribution and lifecycle management - -Passepartout diverges in two independent dimensions across instances: -code (engine, macro layers, skills) and knowledge (gate rules, fact store, -ontology, proof forest, empirical decision history). This creates a -distribution problem no current AI system faces — most agents ship as -static binaries with no per-instance knowledge divergence. - -*** Distribution tiers - -Code only (AGPL repo — GitHub) -- The core engine, ACL2 macro layers as skills, generic gate rules. -- No domain knowledge, no pre-seeded fact store, no proof forest. -- User bootstraps from scratch — the system learns from their gate outcomes. -- Audience: hobbyists, researchers, early adopters willing to invest time. - -Code + basic knowledge (commercial data package) -- Pre-seeded fact store for a domain (healthcare, finance, infrastructure). -- Curated gate rules, ontology categories, and initial ACL2 theorem set. -- The buyer gets sufficiency faster — weeks instead of months to reach - the Phase 4 flip in their domain. -- Audience: enterprises that want fast deployment without bootstrapping. - -Code + knowledge + verification appliance (hardware product) -- RISC-V + Lisp μcode on FPGA or custom ASIC. -- Pre-loaded with full domain-specific knowledge package. -- Hardened, certified, no-cloud, tamper-proof HSM root of trust. -- Audience: regulated industries that need provable compliance out of - the box. - -*** The upgrade problem - -Once instances diverge in both code and knowledge, a naive `git pull` -breaks things: - -1. A new macro layer expects a fact structure the old store doesn't have - → re-verification fails, system degrades to pre-macro state - -2. Two instances of the same version develop different ontologies - → a shared gate rule package produces different outcomes on each - -3. Knowledge learned in v1 must be verified against v2's code - → old facts carry `:ontology-version`, ACL2 checks they're still - consistent under the new code's rules - -4. A security patch changes the gate stack - → all existing gate-outcome facts must be re-verified against the - new gate vectors - -*** How Passepartout's architecture handles this - -The architecture already has the primitives for safe upgrades: - -- **Ontology versioning (Phase 5).** Every fact stores the ontology - version at assertion. On upgrade, facts with old versions are flagged - for re-verification. ACL2 checks consistency against new code. Facts - that survive are promoted to the new version. Facts that fail are - flagged for review. - -- **Degradation, not crash.** If an upgrade breaks the fact store, the - system degrades to the pre-macro symbolic state (hash-table fallback - for VivaceGraph, text-scan fallback for Screamer). It still works — - it just can't prove as much. The TUI displays: "Symbolic index: legacy - mode. 2,134 facts pending re-verification under new ontology." - -- **Reversible upgrades (Phase 0 undo).** Every upgrade produces a - Merkle snapshot before applying. If re-verification fails, the system - rolls back to the pre-upgrade state. The failed upgrade becomes a - memory-object with `:provenance :failed-upgrade` — empirical data - for the next upgrade attempt. - -- **Delta distribution.** Upgrades are delivered as diffs against the - current ontology version, not full replacements. A code upgrade ships - with a migration script: "This version changes the gate rule structure - from (action pattern) to (action pattern context meta). Here is the - automated migration for your existing gate rules." The user's - empirical data is preserved across the migration. - -*** The real challenge: divergence of empirical knowledge - -The hardest upgrade is not code — it's the fact store. Two instances -that started from the same code but served different users for a year -have diverged ontologies. Instance A's gate rules encode "emergency -restart = docker compose restart" (hospital IT). Instance B's gate rules -encode "emergency restart = emergency_shutdown.py" (factory floor). - -A code upgrade that changes how emergency restarts are processed cannot -be safely applied to both instances with the same migration. The -migration must be per-instance, tested against the instance's specific -facts. - -The pattern that solves this: **the upgrade is itself verified by the -upgraded system before committing.** The distributor ships: "Here is -the new `emergency-restart` gate vector. Run it against your existing -gate rules. ACL2 will report which rules are compatible and which need -human review." The instance operator reviews only the incompatible -subset. - -This is slower than `git pull` but avoids the catastrophe of a silent -incompatibility. An enterprise running Passepartout in a compliance -context would not accept an unverified upgrade anyway. - -*** The business model for upgrades - -- Code upgrades: free (AGPL). Core engine improvements benefit everyone. -- Migration scripts: subscription. The instance operator pays for the - verified migration path from their current ontology version to the - new one. The migration script is generated by running the new code - against the instance's fact store in a sandbox. -- Domain knowledge package upgrades: subscription. When HIPAA updates, - the healthcare gate rule package updates. The new rules are verified - against the instance's existing fact store before shipping. -- Verification appliance firmware: bundled with hardware. The Lisp - Machine's microcode is updated as the engine evolves. The update is - signed and verified against the hardware root of trust before - applying. - -** Large refactoring in a neurosymbolic planner — semantic equivalence - -*** The workflow - -ACL2 proves semantic equivalence of programs written in its own -logic — which includes Passepartout's own source code. When the -system refactors its own skills, ACL2 can prove the new function -produces the same outputs for all inputs as the old one. This is -standard ACL2 practice (verifying compiler optimizations, sort -algorithm replacements). - -For other languages (Python, Java, JavaScript), the path is: -1. Model the critical subset (API surface, contracts, data - transformations) in ACL2 as a logical specification -2. Prove the specification is preserved across the refactoring -3. The actual implementation stays in the target language — - ACL2 proves the structural contract, not the runtime behavior - -The CIC prover upgrade (Lean-in-Lisp, planned as future work) -would extend this to dependent-type-level equivalence proofs -across language boundaries — verifying that a Rust API binding -correctly wraps a C library, or that a Python refactoring -preserves the type-level contract of the original. - -** The self-driving Lisp Machine on FPGA or Tenstorrent - -A Tenstorrent P150 (~72 RISC-V Tensix cores on a PCIe card) or -a mid-range FPGA (AMD Alveo, Intel Agilex) offers enough -hardware to run a full Passepartout image with Lisp microcode -acceleration. The host Linux system provides boot, I/O, and -thermal management; the accelerator card provides the Lisp -execution fabric. - -*** What it can do today - -- **Run the full symbolic engine.** ACL2, Screamer, VivaceGraph, - and the fact store are pure Lisp — they run on any Lisp backend. - The RISC-V cores on a Tenstorrent or the soft-core on an FPGA - provide enough compute for real-time gate verification and - constraint solving. - -- **Hot-reload skills and macro layers.** The Lisp image loads - skills, tangles Org files, compiles ACL2 books, and registers - metafunctions — all without reboot. The FPGA fabric can be - reprogrammed with new microcode in milliseconds. - -- **Manage its own knowledge base.** The fact store grows and - evolves. Gate rules are proposed by the LLM and verified by - ACL2. Ontology versions are tracked. The system knows what - it knows and what changed. - -- **Roll back failed upgrades.** Merkle snapshots provide - instant undo for both software state and FPGA configuration. - -*** What it needs to cross the threshold to self-driving - -The system is not yet fully self-driving because three things -still require external intervention: - -1. **The LLM dependency.** The 10% I/O translation (natural - language → structured goal, structured result → natural - language) requires an LLM. A small local model (Phi-4, - Qwen 2.5) on the host or card can serve this. The symbolic - engine handles everything else. Once sufficiency flips - (Phase 4), even the LLM is rarely needed. - -2. **Hardware driver development.** The FPGA microcode (tagged - memory, hardware GC, Lisp dispatch in hardware) is currently - written by humans. The system could eventually propose new - microcode patterns from profiling data — "your GC accounts - for 12% of runtime; here is a hardware GC barrier that - reduces it to 3%" — but the synthesis and verification of - hardware descriptions (VHDL, Verilog) requires a separate - toolchain. - -3. **The initial bootstrap.** The first FPGA load, the first - Linux boot, the first Lisp image — these are done by a - human or a pre-existing system. Once bootstrapped, the - system manages itself. The threshold is crossed when the - system can design, compile, and load its own FPGA microcode - from within the running image. - -*** The threshold - -The self-driving threshold is crossed when the system can -synthesize and load its own FPGA microcode or Tensix dispatch -programs from within the running Lisp image. At that point: - -- The system profiles its own gate verification latency -- It proposes a new microcoded instruction for the hot path -- It compiles Verilog from ACL2-verified specifications -- It reprograms the FPGA fabric via PCIe DMA from within SBCL -- It benchmarks the new instruction against the old one -- If throughput improves, the new microcode becomes permanent -- If not, it rolls back and tries another approach - -This is not science fiction — it is the natural extension of -an architecture that already hot-reloads its own code, tracks -its own performance telemetry, and verifies its own changes -before committing them. The hardware description language is -the last abstraction boundary. - -*** What stops it from being full science fiction - -| Barrier | Status | Path | -|---------|--------|------| -| LLM dependency | Phase 4 flip reduces it to near-zero | Already designed | -| Hardware microcode synthesis | Most speculative | Requires hardware DSL verified by ACL2, then compiled to FPGA bitstream | -| Initial bootstrap | One-time human action | After first load, system manages itself | -| Power and thermal | Handled by host Linux | Unchanged | -| PCIe DMA from SBCL | Feasible with sb-alien + libpcie | Needs driver, but well-understood | - -The Tenstorrent approach is particularly interesting because -its Tensix cores are *already* RISC-V processors. The microcode -is not FPGA logic — it's a RISC-V program. The system can write -RISC-V assembly, compile it with the RISC-V toolchain, load it -onto the Tensix cores, and benchmark the result. This is -dramatically simpler than FPGA synthesis because it's software, -not hardware. - -A Tenstorrent P150 running Passepartout would be: 72 RISC-V -cores running Lisp microcode, one core dedicated to the ACL2 -prover, one to Screamer, the rest to gate verification and -fact store operations. The host Linux system handles I/O and -the LLM. The system designs its own core dispatch logic, -loads it onto idle cores, and verifies the result with ACL2 -before committing. - -** How the LLM's coding ability affects the bootstrapping timeline - -The LLM writes code at every stage of the bootstrapping: -1. The Lisp Machine's microcode (RISC-V dispatch, GC barriers, - tagged memory operations) -2. The CIC prover kernel (if built as a skill) -3. ACL2 macro layers for new domains -4. Gate rules for previously uncodified domains -5. The initial self-optimization proposals - -At each stage, the symbolic engine (ACL2, Screamer, gate stack) -verifies the LLM's output before accepting it. The LLM proposes; -the symbolic engine disposes. - -This means the LLM's coding ability is a **speed multiplier, not -a gate**. A weak LLM (3B local model) produces correct code -after N retries where the symbolic engine catches the mistakes -and feeds them back. A strong LLM (Claude Sonnet, DeepSeek, GPT) -produces correct code after fewer retries. The cost difference -is in API calls and wall-clock time, not in the correctness of -the final output — the symbolic engine guarantees that. - -| Scenario | LLM quality | Retries per unit | Wall-clock per unit | Correctness | -|----------|-------------|------------------|---------------------|-------------| -| Bootstrapping with local 3B model | Low | 5-15 | 10x slower | 100% (verified) | -| Bootstrapping with frontier API | High | 1-3 | 1x | 100% (verified) | -| Bootstrapping after sufficiency flip | None (symbolic only) | 0 | Instant | 100% (verified) | - -The critical transition is between row 2 and row 3: once the -symbolic engine has accumulated enough non-lossy facts about -the Lisp Machine's hardware behavior (latency profiles, GC -patterns, instruction timings), it can propose microcode -optimizations without any LLM involvement. ACL2 proves the -optimization preserves correctness; Screamer checks it against -known hardware constraints; the gate stack verifies it won't -damage the running system. Zero tokens. - -This is the sufficiency flip applied to hardware. The timeline -to reach it depends on how many facts the system can gather -about its own runtime behavior, not on how good the LLM is. - -** The surprising result - -An LLM that is just barely competent at coding (enough to -generate syntactically valid RISC-V or Lisp that passes the -symbolic engine's checks after a few retries) is sufficient -for the entire bootstrapping chain. It takes longer — more -retries, more wall-clock — but it reaches the same endpoint: -a system that designs its own microcode without any LLM. - -The LLM's coding ability determines how many API dollars and -calendar months the bootstrap requires. It does not determine -whether the bootstrap succeeds. A patient operator with a -3B local model and a Tenstorrent card reaches the same -destination as an operator with bottomless API credits — the -second arrives faster, but both arrive. - -** The per-domain sufficiency flip - -The sufficiency flip is not a single event. It happens -independently for each domain, and some domains never flip. -The flip point is determined by the kind of knowledge the -domain requires. - -*** Knowledge types required for a flip - -| Domain | Knowledge required | Can it flip? | How fast? | -|--------|-------------------|--------------|-----------| -| Shell safety, path rules | Structural only — the deployment's config, shell semantics | Immediately | Instant — ingested from config | -| Healthcare compliance | Structural (HIPAA text) + empirical (human reviews of edge cases) | Yes | Weeks — one pass of LLM translation + human review cycle | -| Codebase refactoring | Structural (dependency graph, API surface) + empirical (test suite, build results) + performance (latency, throughput) | Yes | Months — depends on how many build cycles the system has observed | -| Microcode optimization | Structural (RISC-V ISA, core topology) + performance (profiling data) | Yes | Weeks — after enough benchmark runs to characterize hardware | -| Poetry, creative writing | Neither structural rules nor empirical ground truth (beauty is subjective) | **Never** | N/A — the gate stack cannot verify aesthetic quality | -| Novel scientific discovery | Structural (known laws) + empirical (experiments) | Eventually | Years — requires experimental data the system must gather through instruments | - -*** The fastest acquisition strategy per domain - -The goal: reach the flip point with the fewest calendar days -and the fewest human hours. - -| Knowledge type | Acquisition strategy | Calendar time | Human time | -|----------------|---------------------|---------------|------------| -| **Structural** (published rules, configs, specs) | LLM translation of source documents + ACL2 consistency verification + one-shot human review | Hours for the LLM pass, days for human review | Days — one domain expert reviewing the output | -| **Structural** (unpublished — your deployment, your codebase) | Automated scanning — the system walks your filesystem, reads your configs, builds the dependency graph | Minutes to hours | Zero — fully automated | -| **Empirical** (what happens when X?) | **Active probing** — the system does not wait for user interactions. It probes its own environment: runs shell commands in sandbox to verify gate rules, executes test suites to verify dependency graph, measures what happens when it pushes boundaries. | Hours to days | Zero — automated sandboxed probing | -| **Empirical** (what does the human prefer?) | **Contrastive queries** — instead of waiting for HITL approvals to accumulate, the system asks targeted questions: "Which of these two interpretations of the regulation is correct? This one or this one?" Each question produces a fact. | Days — batch of targeted questions answered in one session | Hours — one review session with the domain expert | -| **Performance** (latency, throughput) | **Benchmark harness** — the system runs its own workload at varying parameters, records timing data, stores it as facts with `:provenance :benchmark` | Hours — automated sweep | Zero | -| **Transfer** from related domains | **Ontology alignment** — if the system already knows compliance for GDPR, it can ask Screamer: "Which GDPR rules have the same structure as HIPAA rules? Use those as seed hypotheses, flag for human review." The transferred rules flip faster because Screamer starts from a consistent foundation, not from scratch. | Days — Screamer finds alignments automatically, human reviews the suggestions | Hours — review the cross-domain alignment suggestions | - -*** The fastest path to flip any domain - -1. **Ingest all published text** for the domain (laws, specs, configs) - via LLM translation. One pass. Hours. - -2. **Run the benchmark harness** to measure the system's own performance - in the domain. One sweep. Hours. - -3. **Run active sandboxed probes** — test each gate rule against - synthetic inputs to verify it behaves as expected. Automated. - -4. **Generate contrastive queries** — Screamer identifies the 5% - of rules where the LLM's translation is most uncertain (contradicts - a transferred rule, has no precedent, has multiple valid - interpretations). Present these as yes/no questions to the human - domain expert in a single session. - -5. **Start serving real interactions.** Every gate outcome generates - an empirical fact that Screamer feeds back into the rule set. - The empirical loop tightens from the first real interaction. - -For a codified domain (healthcare compliance, financial regulation, -industrial safety): flip within days of step 1-4. The only bottleneck -is the domain expert's review session in step 4 — a few hours of -human time. - -For an uncodified but learnable domain (codebase refactoring): -flip within weeks of step 3 (benchmark harness) + step 5 (real -interactions). No LLM translation needed — the knowledge comes -from the system probing its own environment. - -For a domain that can never flip (poetry, aesthetics): the system -never reaches sufficiency. It never claims to. The TUI shows -"Symbolic index: 0 facts. This domain has no codifiable rules." -The LLM handles 100% of poetry interactions. The gate stack -only checks for safety (no shell commands, no file deletions) -and passes through everything else to the LLM. The system is -honest about its frontier. - -*** Bootstrapping the Lisp Machine: all domains are software - -For the concrete goal of bootstrapping a self-driving Lisp Machine, -every domain involved is software — the most codifiable domain in -existence. Code has formal specifications, documented ISAs, -deterministic behavior, and objectively testable correctness. -Every subdomain required for the bootstrap flips. - -| Subdomain | Knowledge type | Flip timeline | Why | -|-----------|---------------|---------------|-----| -| RISC-V ISA, Tenstorrent Tensix dispatch | Structural (ISA spec, API docs) + performance (profiling) | Days | Published spec, deterministic hardware, benchmark harness characterizes real behavior | -| SBCL runtime internals (GC, type dispatch, threading) | Structural (source code) + performance (latency profiles) | Days | Full source available, system can instrument itself | -| ACL2 metafunctions and macro layers | Structural (the logic is ACL2's own) | Instant | The theorem language is already the system's native logic — no translation step | -| FPGA/Verilog descriptions (if FPGA path) | Structural (VHDL/Verilog semantics) + performance (timing analysis, power) | Weeks | Published language semantics, but synthesis is slower and bitstream verification is harder than RISC-V | -| CIC prover kernel | Structural (type theory rules — these ARE formal) | Days | Mathematics is the most codified domain. ACL2 already does structural verification. Building a CIC kernel that ACL2 verifies is well-understood work. | -| Operating system interfaces, device drivers | Structural (syscall API, register maps) + empirical (test results) | Weeks | Published interfaces, deterministic behavior, but hardware quirks require empirical probing | -| Compiler optimization | Structural (IR semantics, optimization passes) + performance (benchmark before/after) | Weeks | Published semantics, objective quality metric (faster = better), benchmark harness measures | - -Every single subdomain flips. The only variable is calendar days -to accumulate the knowledge. - -*** The fastest acquisition sequence - -Optimized for minimal wall-clock time to a self-driving Lisp Machine: - -**Day 1: Ingestion day** -- LLM translates: RISC-V ISA spec, SBCL source, Tenstorrent API docs, - ACL2 reference, CIC type theory rules. All structural knowledge - enters the fact store in one parallel pass. -- ACL2 verifies consistency across all ingested domains. -- Human expert reviews the 5% of rules Screamer flagged as uncertain. - One session, a few hours. - -**Day 1-2: Profiling day** -- Benchmark harness sweeps all 72 Tensix cores: measure instruction - latency, memory bandwidth, GC pause distribution, dispatch overhead. -- Each measurement is a fact with `:provenance :benchmark`. -- The benchmark harness is itself verified by ACL2 (it runs inside - a controlled sandbox, bounded time, no side effects on production data). - -**Day 2-3: Active probing day** -- The system generates synthetic microcode routines: short programs - that exercise specific instructions, specific GC patterns, specific - dispatch paths. -- It loads them onto spare Tensix cores, measures actual latency, and - compares against the spec. -- Discrepancies become facts: `(:entity "core-42" :relation :dispatch-latency - :value "14 cycles" :source :measured :expected "12 cycles" :provenance :probe)`. -- After ~1,000 probes, the system knows the hardware's actual behavior - better than the published spec does. - -**Day 3-7: Transfer and sufficiency** -- ACL2's existing knowledge about induction, rewriting, and termination - transfers directly to verifying microcode routines (same logic, different - subject matter). -- Screamer aligns microcode verification patterns with existing gate - verification patterns — both are structural proofs over finite state. -- The benchmark facts give ACL2 a concrete cost model. ACL2 can now - prove not just correctness but also "this microcode routine is at - least 10% faster than the current implementation." -- Sufficiency flip for microcode generation: the system proposes new - dispatch routines, ACL2 verifies them, Screamer checks against - hardware constraints, the gate stack blocks anything unsafe. Zero LLM - tokens for the optimization loop. - -**Week 2-4: Self-optimizing system** -- The system profiles its own gate verification latency (already - instrumented via telemetry). -- It identifies the hot path: "fact-query accounts for 34% of verify time." -- It generates a new dispatch routine for fact-query, targets the - nearest idle Tensix core, loads it, benchmarks, and commits if - faster. -- The ontology now includes facts about its own optimization history: - `(:entity "fact-query-dispatch-v3" :relation :speedup-baseline - :value "1.34x" :provenance :self-optimize)`. - -**After the flip: purely symbolic optimization** - -The LLM is no longer needed for any optimization proposal. The system -profiles, proposes, verifies, tests, and commits entirely within the -symbolic engine. The LLM remains only for the boundary: interpreting -a human's high-level goal ("make the system faster") into a structured -optimization target, and formatting the benchmark report for human -readability. Those calls shrink toward zero as the system internalizes -common optimization goals as gate rules. - -*** The surprising result for bootstrapping specifically - -Because every subdomain of the Lisp Machine bootstrap is software, -and software is the most codifiable domain, the entire bootstrap -can flip in **days to weeks** with a single human review session. - -The bottleneck is not knowledge acquisition. It is not the LLM's -coding ability. It is the initial human review of the 5% of -ambiguous rules that Screamer flags — a session measured in hours, -not weeks. - -The Tenstorrent approach makes this even faster because the -microcode is software (RISC-V assembly), not hardware (FPGA -bitstream). The system can propose, load, test, and roll back -a new dispatch routine in seconds. An FPGA path would add -synthesis time (minutes to hours per iteration), stretching -the bootstrap from days to months. - -A system with a Tenstorrent P150, the AGPL Passepartout code, -a RISC-V cross-compiler, and one patient human who reviews the -contrastive queries can achieve a self-driving Lisp Machine in -under a month. - -*** Size and development time estimates - -These are order-of-magnitude estimates based on the existing -architecture and the roadmap's line-count breakdowns. The numbers -are small because Lisp is more expressive, the architecture reuses -primitives across domains, and the symbolic engine replaces what -would be thousands of lines of Python in a conventional agent. - -**** Current Passepartout (main branch) - -| Component | Lines of Lisp | Status | -|-----------|---------------|--------| -| Core pipeline (perceive-reason-act, memory, skills, transport, package) | ~1,800 | Built and running | -| Gate stack (security dispatcher, permissions, policy, vault, validator) | ~900 | Built and running | -| Neuro (provider router, provider dispatch, token economics, tokenizer) | ~900 | Built and running | -| Programming tools (lisp, org, repl, literate, standards, tools) | ~1,600 | Built and running | -| Symbolic (archivist, awareness, memory, scope, events, identity, self-improve) | ~1,200 | Built and running | -| Channels (TUI main/state/view, CLI, Telegram, Signal, Discord, Slack) | ~2,300 | Built, on refactor branch | -| TUI (cl-tty migration, ongoing) | ~1,300 | In progress on refactor branch | -| Config, diagnostics, embedding, sensors, integration tests | ~700 | Built and running | -| **Total existing** | **~10,700** | | - -Development time to reach current main: approximately 2 months, -one developer (April-May 2026 from git log). - -**** New code to reach neurosymbolic maturity - -| Phase / Feature | Lines | Est. dev time (one dev) | -|-----------------|-------|------------------------| -| TUI stabilization (cl-tty) | ~500 | 3-4 weeks | -| Eval harness + sandbox hardening | ~200 | 1-2 weeks | -| Phase 0 (type-level gates, core integrity) | ~75 | 3-5 days | -| Phase 0b (signal authentication, Layer 1) | ~200 | 1-2 weeks | -| Phase 1 (fact store with provenance) | ~200 | 1-2 weeks | -| Phase 1a (self-preservation, quarantine, watchdog) | ~120 | 1 week | -| Phase 2 (Screamer admission gate) | ~200 | 1-2 weeks | -| Phase 3 (archivist as fact proposer) | ~100 | 1 week | -| Phase 4 (sufficiency criterion, the Flip) | ~50 | 2-3 days | -| Phase 5 (VivaceGraph, Merkle DAG, ontology versioning) | ~400 | 2-4 weeks | -| Phase 6 (ACL2 base + 5 macro layers) | ~540 | 3-4 weeks | -| Phase 7 (10-80-10 planner) | ~500 | 3-4 weeks | -| All polish features (skins, export, CLI, MCP, LSP, telemetry, cost, etc.) | ~1,500 | 4-8 weeks | -| Integration testing, hardening, bug fixes | — | 4-8 weeks | -| **Total new code** | **~4,500** | **4-6 months (one developer)** | - -**** Additional code for a self-driving Lisp Machine - -| Component | Lines | Est. dev time (one dev) | -|-----------|-------|------------------------| -| RISC-V microcode for Lisp dispatch (tagged memory, GC barriers, cons cells) | ~3,000 | 1-2 months | -| PCIe DMA driver from SBCL (C + sb-alien FFI) | ~500 | 2-4 weeks | -| Tenstorrent Tensix core management (allocate, load, benchmark) | ~1,500 | 3-4 weeks | -| Profiling and benchmark harness (Phase 4 applied to hardware) | ~500 | 1-2 weeks | -| Microcode synthesis from ACL2-verified specifications | ~500 | 2-4 weeks | -| **Total for Lisp Machine hardware integration** | **~6,000** | **3-6 months (one developer)** | - -Notable: the microcode for Lisp dispatch (~3,000 lines of RISC-V -assembly) is smaller than the existing Lisp codebase. The hardest -part is not the assembly — it's the verification that the assembly -correctly implements the Lisp primitives, which ACL2 handles. - -**** Total system at self-driving threshold - -| | Lines of code | Dev time (one dev) | Dev time (small team, 2-3) | -|-----|---|---|---| -| Current Passepartout | ~10,700 | 2 months (done) | 1 month (done) | -| Through Phase 7 (neurosymbolic maturity) | +~4,500 | 4-6 months | 2-3 months | -| Lisp Machine hardware | +~6,000 | 3-6 months | 2-3 months | -| **Total** | **~21,000** | **9-14 months** | **5-7 months** | - -**** Why the numbers are small - -- **Lisp is 3-10x more compact than C++ or Python** for the same - semantics. The entire gate stack (900 lines) would be 3,000-5,000 - lines of Python with middleware classes and serialization glue. -- **The architecture reuses primitives cross-domain.** The Merkle - tree, the gate stack, the fact store, the ACL2 prover — each is - built once and shared by all features. There is no "compliance - package" that duplicates the "refactoring package" infrastructure. -- **The symbolic engine replaces test code.** A conventional agent - needs thousands of lines of test fixtures for behavior validation. - ACL2's proofs replace those. The tests are the theorems. -- **The LLM generates the boilerplate.** The LLM writes gate rules, - macro layer templates, and migration scripts. The symbolic engine - verifies them. The human reviews the 5% edge cases. The bottleneck - is verification throughput, not code writing. - -**** Comparison with other systems - -| System | Lines | Developer-years | -|--------|-------|-----------------| -| Hermes Agent | ~50,000+ | 2+ years, ~3 devs | -| Claude Code | ~100,000+ (estimated) | 3+ years, large team | -| Llama.cpp | ~200,000 | 2+ years, many contributors | -| **Passepartout self-driving** | **~21,000** | **~1 year, 1-3 devs** | -| Symbolics Genera (1980s Lisp OS) | ~1,000,000 | ~10 years, large team | - -The Symbolics comparison is instructive: they built a full Lisp -operating system from scratch in assembly and Lisp, with graphical -interface, networking, file system, and development environment. -Passepartout runs on Linux, which provides the OS layer for free. -The Lisp Machine hardware integration is a PCIe card, not a -replacement of the entire host. The scope is dramatically smaller. - -The surprising result: **a self-driving Lisp Machine is a ~21,000 -line project for a small team working less than a year.** Not a -billion-dollar moonshot. A well-scoped engineering project. - -*** Revised time estimate given actual velocity - -Moving from initial state through TUI, -streaming, gate trace, HITL, Merkle audit, tool hardening, session -rewind, undo/redo, skills engine) in a single session means the -agent writes the code and the symbolic engine verifies it at a -cycle measured in minutes, not days. - -The limiting factor is not coding speed. It is: -1. LLM API call latency per iteration (seconds per generation) -2. ACL2 verification time per submission (milliseconds per theorem) -3. Human review of Screamer-flagged edge cases (the 5%) - -For the 4,500 lines remaining to neurosymbolic maturity, distributed across ~40 -independent features (each 50-500 lines), with the agent generating, -ACL2 verifying, and the human reviewing only the flagged 5%: - -| Phase | Lines | Cycles | Wall clock | -|-------|-------|--------|------------| -| TUI stabilization + eval harness | ~700 | 10-14 | Days | -| Phases 0-4 (type gates, fact store, Screamer, archivist, sufficiency) | ~670 | 10-14 | Days | -| Phase 5 (VivaceGraph, Merkle DAG, ontology versioning) | ~400 | 6-10 | Days | -| Phase 6 (ACL2 base + 5 macro layers) | ~540 | 8-12 | Days | -| Phase 7 (10-80-10 planner) | ~500 | 8-10 | Days | -| Polish features (skins, export, CLI, MCP, LSP, telemetry, etc.) | ~1,500 | 20-30 | 1-2 weeks | -| Integration, edge-case hardening, cross-phase regression | — | — | 1-2 weeks | -| **Total to neurosymbolic maturity** | **~4,500** | **~80 cycles** | **3-5 weeks** | - -The bottleneck at this velocity is not code generation. It is -human availability to review the Screamer-flagged 5%. At 80 cycles -across 40 features, that is roughly 4 flagged rules per feature, -200 total, each requiring a yes/no answer from the human. In a -dedicated review session: 2-3 hours of human time. - -For the Lisp Machine hardware integration (microcode, PCIe DMA, -Tensix management, benchmark harness — ~6,000 lines): - -| Component | Lines | Cycles | Wall clock | -|-----------|-------|--------|------------| -| RISC-V microcode for Lisp dispatch | ~3,000 | 20-30 | 1-2 weeks | -| PCIe DMA driver (C + sb-alien FFI) | ~500 | 4-6 | Days | -| Tensix core management | ~1,500 | 10-15 | Days | -| Benchmark harness + microcode synthesis | ~1,000 | 8-12 | Days | -| **Total hardware integration** | **~6,000** | **~60 cycles** | **2-4 weeks** | - -The Lisp Machine hardware integration is slower per cycle because -the microcode must be loaded onto physical hardware and benchmarked. -Each cycle includes: generate → ACL2 verify → load onto Tensix → -run benchmark → measure → feed back. That adds seconds per cycle -vs milliseconds for pure-software verification. - -The total to a self-driving Lisp Machine (Logos + Stoa hardware): -~140 cycles, 6-10 weeks, 4-6 hours of human review time. - -For the full Stoa (editor, browser, shell, Qt integration): - -Stoa is not written from scratch. It is first assembled from -existing components, then systematically replaced. The initial -assembly is fast: - -| Stage | Approach | Lines | Cycles | Wall clock | -|-------|----------|-------|--------|------------| -| Qt/EQL5 shell (minimal) | Wrap existing Qt widgets | ~500 | 4-6 | Days | -| Lish editor (minimal) | Org buffer + Qt text widget | ~1,000 | 8-10 | Days | -| Nyxt browser Stage 1 | Qt + WebKit, wrap existing API | ~2,000 | 10-15 | 1-2 weeks | -| **Stoa v2.0.0 working** | **~3,500** | **~30 cycles** | **2-3 weeks** | - -After v2.0.0, erosion begins. Each replacement is a self-contained -project where the system proposes the replacement, ACL2 verifies -it produces identical output for all known inputs, and the system -loads it. The timeline is no longer measured in cycles — it is -measured in how many verifiable replacements the system can propose -and test before settling on the optimal implementation. - -The total from today to a fully self-driving Lisp Machine with a -working editor, browser, and shell: approximately 8-12 weeks with -the actual observed velocity. Not years. - -*** Self-writing beyond the bootstrap - -Once the system achieves sufficiency for software engineering -(Phase 4 flip applied to code generation), the bulk of Stoa and -Agora is written by the system itself: - -| System | Human writes | System writes | Total | -|--------|--------------|---------------|-------| -| Logos (Passepartout) | ~10,700 existing + ~4,500 to maturity | The system extends its own macro layers and fact store | ~15,000 + growing | -| Stoa (environment) | Design decisions, architectural constraints | ~100,000+ lines of editor, browser, shell, layout engine, each component verified by ACL2 before loading | ~150,000+ | -| Agora (network) | Protocol specification, threat model | DIDComm implementation, Relay Network, PDS, Lightning integration, contracts — each module verified by ACL2 | ~100,000+ | -| Hardware (tagged RISC-V) | ISA design, TinyTapeout shuttle | VHDL/Verilog for tagged memory, GC bus master, Lisp primitives — synthesized and tested via FPGA | ~50,000+ | - -The human time is dominated by design decisions, not code writing. -Code writing is the agent's job. The bottleneck shifts from "how -many lines can I write per day" to "how many design decisions can -I make per day and how quickly can I review the 5% of ambiguities -Screamer flags." - -At the observed velocity (initial development in a single session), a -deep-thinking human paired with this architecture can go from -today's Passepartout to the full Logos + Stoa + Agora triad in -approximately 3-6 months — most of that time spent on design -decisions and protocol specification, not on code. - -The triad, when complete, replaces every layer of the current -computing stack — cognition (OpenAI/Anthropic), environment -(Apple/Microsoft/Google), network (Facebook/Twitter/Slack) — -with Lisp-native, user-owned, ACL2-verified alternatives that -cost near-zero marginal compute. The lines that run the modern -internet (tens of millions across Google, Meta, Amazon, Apple, -Microsoft) are replaced by a single coherent architecture where -one gate stack verifies everything and one prover proves -everything consistent. - -The social and economic impact of this is not "a better AI agent." -It is a complete alternative infrastructure for personal computing -that requires no cloud, no gatekeeper, no per-token fee, and no -trust. The lines don't need to exist on day one. They need to -exist in the right order — and the system writes them in that -order, one ACL2-verified submission at a time. - -**** Market size and business models - -The triad directly addresses markets that currently spend over a -trillion dollars annually combined: - -| Market | Annual spend | What the triad replaces | -|--------|-------------|------------------------| -| Cloud computing (AWS, GCP, Azure) | ~$300B | Verification appliance runs locally — no per-resource billing | -| AI/LLM API revenue (OpenAI, Anthropic) | ~$50B | Near-zero marginal cost symbolic engine | -| Operating systems (Microsoft, Apple) | ~$100B | Stoa (Lisp-native editor, browser, shell) | -| Social media / communication (Meta, Twitter, Slack, Discord) | ~$200B | Agora (DID-based, encrypted, permissionless) | -| Identity / SSO (Okta, Auth0, Google/Apple) | ~$10B | Self-sovereign DID + HD keys | -| Payment processing (Stripe, PayPal, Visa/MC) | ~$200B | Lightning + smart contracts | -| Productivity software (Microsoft, Google) | ~$50B | Lish + Org-mode + Stoa | -| Compliance and audit (regulatory) | ~$50B | Automated ACL2-verified compliance | -| **Total addressable** | **~$960B** | | - -The triad does not need to capture all of this. It needs to capture -the portion that is willing to pay for provable correctness, lower -cost, and user sovereignty. Even 1% of this TAM is ~$10B/year. - -**** Business models for a free-software triad - -The AGPL license is not a barrier to monetization — it is the -foundation of the trust model. An enterprise cannot buy provable -correctness from closed source; the code must be inspectable. The -revenue comes from what the AGPL does not cover: - -***** Low-hanging fruit (immediate, months) - -1. **Verification appliance (hardware).** An FPGA or Tenstorrent - card pre-loaded with a mature Passepartout image, domain-specific - gate rules, and a hardware root of trust. No cloud dependency. - Target: regulated industries that need provable compliance and - cannot accept cloud-based AI. Price: $5K-$50K/unit. Volume: - hundreds to low thousands in year one. - -2. **Domain gate rule subscriptions.** Pre-verified gate rule - packages for specific compliance domains. HIPAA package: $50K/yr. - SOC2 package: $50K/yr. GDPR package: $50K/yr. FedRAMP package: - $100K/yr. Updated automatically when regulations change. An - enterprise with all four pays $250K/yr — and the switching cost - is high because changing packages means re-verifying the fact - store against new rules. - -3. **Evaluation harness as certification.** "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 deployed - instance, making the certification increasingly valuable over - time. - -4. **Migration services.** "Bring your existing infrastructure into - the Passepartout gate stack." Custom gate rules, ontology design, - integration with existing systems. Price: $100K-$500K per - engagement. Each engagement feeds back edge cases into the - regression suite and domain gate packages. - -Revenue estimate for year one (low-hanging fruit): 50 appliance -sales ($250K-$2.5M) + 20 gate rule subscriptions ($1M-$5M) + -10 certifications ($500K-$2M) + 5 migration engagements ($500K- -$2.5M). Total: $2.25M-$12M. Not venture-scale, but self-sustaining -for a small team. - -***** Medium-term (1-3 years) - -5. **Compute marketplace (Agora).** Passepartout instances offer - their symbolic engine capacity (ACL2 cycles, Screamer constraint - solving, VivaceGraph queries) to other agents on the Agora - network. The early player runs a large instance and sells compute - to smaller instances. The AGPL allows this because the marketplace - is a service, not a modification of the code. Revenue is a - percentage of each compute transaction. - -6. **Relay Network (Agora infrastructure).** If Agora becomes the - default communication protocol for agent-to-agent interaction, - running Relays is a business. Every DIDComm message routes - through one or more Relays. Revenue: tiny per-message fee (fractions - of a cent) or paid priority routing. At billions of messages, - fractions become real. - -7. **The Lisp Machine appliance (Stoa v5.0.0 hardware).** The tagged - RISC-V architecture running on FPGA or custom ASIC, sold as a - certified appliance for industries where correctness is worth - paying for: medical devices, industrial controllers, defense - systems, financial trading. Price: $20K-$100K/unit. If the - hardware validation succeeds on TinyTapeout, the upside is - enormous: a certified Lisp Machine at scale could capture a - significant fraction of the embedded systems market. - -***** Big money (3-10 years) - -8. **Verification monopoly: the regression suite as UL certification.** - 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. Any organization claiming a "safe AI agent" needs - Passepartout certification to prove it. This is Underwriters - Laboratory for AI — a certification nobody can ignore. Revenue: - licensing the certification mark to every AI vendor that ships - an agent. Margins: near-100% once the suite exists. - -9. **Infrastructure lock-in: switching costs compound.** A hospital - that runs Passepartout with 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, and an empirical - decision history tied to their specific deployment. 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 - domain packages are added and the fact store becomes more - valuable than the software itself. - -10. **The compute marketplace at planetary scale.** If Passepartout - instances on Agora transact billions of verified operations per - day, the spread on compute transactions is enormous. This is - not a product sale — it is a bet on network effects. Every new - instance increases the value of the network (more capacity, - more diversity, more resilience). The early player that - provisions the largest compute capacity on Agora becomes the - default infrastructure provider for the entire network. - -**** The investment thesis - -The low-hanging fruit (appliances, gate rules, certification, -migration) generates enough cash to sustain development. The -medium-term (compute marketplace, Relay Network, Lisp Machine -hardware) builds network effects and switching costs. The big -money (verification monopoly, infrastructure lock-in, planetary -compute marketplace) is the venture-scale outcome. - -The unique advantage: the early player benefits from every other -instance of the triad, because every deployed instance feeds edge -cases into the regression suite, grows the compute marketplace, -and validates the hardware designs. The network effects are positive -sum — the value of the system increases with every user, and the -early player captures a disproportionate share because they built -the infrastructure that every new instance depends on. - -This is the AWS of provable computing: build the infrastructure, -let everyone use it for free (AGPL), charge for the parts that -scale (compute marketplace, certification, hardware, migration). -The switching costs compound. The network effects are positive sum. -The market is nearly a trillion dollars. - -***** Additional revenue paths - -** Usernames on Agora - -The DID system is permissionless — anyone generates their own DID -via HD key derivation. But human-readable @handles (short names, -common English words, three-letter IDs) are naturally scarce. The -early player controls the namespace registry: - -- **Free tier:** any DID can claim a namespace.username on a - first-come, first-served basis with proof of key ownership -- **Premium tier:** short names (2-3 chars), common words, brand - names, squatter prevention via auction or annual lease -- **Revenue model:** $5-$50/year per premium username, auction - revenue for highly contested names (single-letter, common - surnames). ENS-style: registration fees fund development, not - speculation. - -At scale: 1M premium usernames at $10/yr average = $10M/yr -recurring. The namespace registry is a natural monopoly — the -early player's registry is the most widely accepted, so every -new user registers there. Network effects lock in. - -** PDS as a service - -The Personal Data Store (the Merkle fact store exposed on Agora) -can be self-hosted (free, AGPL) or hosted by the early player: - -- **Free tier (self-hosted):** full AGPL PDS, runs on any Lisp - host, full control, no cost -- **Basic hosted tier:** $10-$20/month, 10GB fact store, 10M - queries/month, automated backup, automatic upgrades -- **Business hosted tier:** $100-$500/month, 100GB+ fact store, - unlimited queries, SLA, dedicated relay, compliance logging -- **Enterprise hosted tier:** $1,000-$10,000/month, air-gapped - appliance management, dedicated support, regulatory-compliant - data residency, integration with existing SIEM - -This is the classic open-core SaaS model (GitLab, Sentry, -PlanetScale). The free self-hosted version drives adoption and -trust (you can inspect every line). The hosted version captures -the value from users who value convenience over control. Bluesky -already demonstrated demand: they charge ~$10/month for PDS -hosting with minimal feature differentiation. - -PDS as a service is lower-margin than hardware appliances but -higher-volume. Target: 100K subscribers at $15/month average = -$18M/yr recurring, with near-zero marginal cost per additional -subscriber (the symbolic engine is CPU-bound, not per-user -metered). - -Combined with premium usernames: $10M/yr + $18M/yr = $28M/yr -recurring from Agora services alone before any compute marketplace -revenue. These are not speculative — they are standard internet -business models (namespace registry + SaaS hosting) applied to -a decentralized identity and data layer. - -*** The full triad: Logos, Stoa, Agora - -The self-driving Lisp Machine is not the endpoint. It is one -component of a three-part architecture: - -| Layer | Name | Function | What it is | -|-------|------|----------|-----------| -| Logos | Passepartout | The mind | Cognitive agent, symbolic engine, gate stack, fact store, ACL2, 10-80-10 planner | -| Stoa | The Porch | The body | Editor (Lish), browser (Nyxt), shell (Lish), Org-mode filesystem, Qt/EQL5 UI, Lisp Machine hardware | -| Agora | The Society | The network | Self-sovereign identity (DID), encrypted comms (DIDComm), Personal Data Store, Relay Network, contracts, liquid democracy, compute marketplace | - -**** Passepartout is the PDS - -Agora's Personal Data Store (PDS) is Passepartout's in-process -memory — the Merkle tree, the fact store, the memory-objects. -Every memory-object already has a SHA-256 hash (Merkle provenance), -which maps directly to Agora's CIDv1 content addressing. The mapping: - -| Passepartout memory-object | Agora Note | -|----------------------------|------------| -| org-object-id | uuid (stable) | -| org-object-hash | cid (content hash) | -| getf attrs :TITLE | payload (derived) | -| getf attrs :TAGS | routing/access-control hints | -| org-object-content | payload body | -| merkle hash | CIDv1 (same SHA-256, different formatting) | - -Passepartout's gate stack verifies every action before it touches -the PDS. No unverified note escapes. ACL2 proves the access controls -are correctly enforced. Screamer checks consistency with the -instance's existing knowledge. - -**** Stoa is the body - -Stoa's roadmap (v2.0.0 → v6.0.0) describes the environment: -- v2.0.0: Lish editor + Nyxt browser (Stage 1, Qt/WebKit) + Lish shell -- v3.0.0+: Cannibalization — eat dependencies one by one. Replace - Qt with Lisp-native layout, reduce WebKit to pixel-painting, - eventually pure-Lisp browser and window management. -- v4.0.0: Native inference — llama.cpp FFI in-process, DSL-compiled - model architectures, live surgery on cognition (inspect hidden - states mid-inference) -- v5.0.0: Hardware — tagged RISC-V architecture via TinyTapeout, - FPGA prototype, hardware GC via dedicated bus master -- v6.0.0: True agency — world models, temporal reasoning, goal - persistence across restarts - -The architectural principle: Stoa is not a collection of clients -connecting to a daemon. It is a single Lisp image where the editor, -browser, shell, and agent coexist. The Dispatcher gate stack -verifies every action regardless of who initiated it — user or -agent. The distinction between "tool" and "self" dissolves. - -**** Agora is the network - -Agora provides the decentralized identity and communication layer -so Passepartout instances can talk to each other: -- Self-sovereign identity via HD key derivation (BIP-44) -- Encrypted messaging via DIDComm (agent-to-agent) -- Notes as atomic, content-addressed, signed data units -- Relay Network for censorship-resistant message routing -- Compute marketplace where instances offer symbolic engine capacity -- Contracts and liquid democracy infrastructure - -Agora integration is a parallel track to Passepartout's core -roadmap (initial → neurosymbolic maturity). The identity DID and DIDComm gateway -can be built as skills at any time without core changes. The PDS -transformation (making the fact store network-addressable) waits -for mature releases. - -**** The complete picture - -The triad replaces every layer of the modern computing stack: - -| Layer | Current (Big Tech) | Triad | -|-------|-------------------|-------| -| Cognition | ChatGPT, Claude, Gemini (centralized API, per-token pricing) | Passepartout (local symbolic engine, near-zero marginal cost) | -| Environment | macOS/Windows/ChromeOS (closed platforms) | Stoa (Lisp-native editor, browser, shell, hardware) | -| Network | Facebook, Twitter, Slack, Discord (extractive, centralized) | Agora (DID-based, encrypted, user-owned, permissionless) | -| App model | Web apps + app stores (gatekeepers take 30%) | Skills + Org files (hot-reloadable, no gatekeeper) | -| Compute | Hyperscaler cloud (AWS, GCP, Azure) | Verification appliance (local, provable, near-zero marginal cost) | -| Identity | OAuth/Google/Apple SSO (surveillance-based) | Self-sovereign DID + HD key hierarchy (user-owned) | -| Commerce | Stripe, PayPal (2-3% + chargeback risk) | Lightning Network + smart contracts (permissionless) | - -The line count estimate (21,000 for Passepartout + Lisp Machine) -covers only Logos + Stoa's hardware layer. Agora's full -specification spans 10 requirements documents and the implementation -(network protocol, PDS, Relay, DID identity) is a separate body of -work comparable to Passepartout itself. - -The unifying factor: all three speak plists. All three operate in -Lisp address space. All three are verified by the same ACL2 prover. -The gate stack that verifies a shell command also verifies a -DIDComm message and an Agora Note publication. The symbolic engine -that plans a refactoring also plans a contract negotiation. - -One gate stack. One memory model. One prover. - -Large refactoring projects (extract module, rename API, split monolith) -are the hardest test for any AI agent. Current approaches (Claude Code, -Copilot) handle them probabilistically — every step costs tokens, and -there is no formal guarantee the final system is consistent. - -Passepartout's Phase 7 planner (10-80-10) transforms this: the symbolic -engine handles planning, ordering, and structural verification; the LLM -handles only the code transformation itself. - -*** The workflow - -1. **Codebase ingestion.** The scanner walks the entire codebase, builds - an abstract syntax graph (not just flat files — imports, type - dependencies, function call chains, test coverage). Each module - becomes a fact in the fact store with `:provenance :codebase-scan`. - -2. **Goal translation (LLM, 10%).** "Extract authentication into its own - service" becomes a structured goal plist: - (:goal :extract-module - :source :auth - :target-service auth-service - :files (:affected (:app/auth/* :app/middleware/auth.clj :tests/*)) - :constraints (:no-breaking-api (:public-api :unchanged)) - :verification (:all-tests-pass :api-contract-preserved)) - -3. **Constraint satisfaction (Screamer, 80%).** Screamer expresses the - refactoring as a constraint satisfaction problem: - - Variables: file modifications ordered by dependency (auth middleware - must be updated after auth module is extracted but before its callers) - - Constraints: no circular dependencies, no step that creates broken - intermediate state, no test file modified before its source - - Objective: minimize total steps while respecting all constraints - - Screamer returns a viable plan or reports unsolvability with the - conflicting constraints — for example, "auth middleware and auth - module have a circular type dependency that must be resolved before - extraction." - -4. **Plan verification (ACL2, part of 80%).** ACL2 proves: - - No dependency cycles in the plan (A must run before B, B before C, - C before A → rejected) - - No deadlocks (two modules waiting on each other) - - Every planned write is within the refactoring scope (no stray - modifications to unrelated files) - - The gate stack will not reject any planned command (no blocked - patterns in the refactoring scripts) - -5. **Incremental execution.** The planner executes each step: - a. Take Merkle snapshot of the current state - b. LLM proposes the code transformation for this step - c. Gate stack checks the proposal (no forbidden file writes, - no shell commands outside the allowed refactoring scope) - d. Transformation is applied - e. Tests run. If they pass → commit the snapshot, update the - fact store with the new codebase graph. If they fail → roll - back to the previous snapshot, flag the LLM's proposal as - `:provenance :failed-transformation`, and attempt a corrected - proposal. - -6. **Final verification.** After all steps complete, ACL2 re-verifies - the entire codebase fact store — all dependencies, all public API - surfaces, all constraints. The result is a Merkle chain from - "before" to "after" with every intermediate state verified. - -*** What the symbolic engine cannot do - -The fundamental limit: **first-order logic cannot prove semantic -equivalence of arbitrary programs.** ACL2 can verify that the -refactoring plan has no structural flaws, that the dependency graph -is acyclic, that every step is within scope, and that tests pass. -It cannot prove "the extracted auth service behaves identically to -the inline auth module from the caller's perspective" for a -general-purpose language. - -This gap is filled by: -- **Tests as empirical verification.** The planner runs the full test - suite after each step. A passing test suite is not a proof of - correctness, but combined with ACL2's structural verification, it - is strong empirical evidence. -- **API contract checking.** For refactoring that preserves public APIs, - ACL2 can verify that the type signatures, argument counts, and - return types of the extracted module's public interface match - exactly — a structural equivalence that does not require semantic - reasoning. -- **Human review of semantic concerns.** The planner flags steps that - involve semantic choices (e.g., "the extracted auth service now - handles token refresh differently"). These steps are presented to - the developer for review with full provenance: before state, after - state, and the diff. The developer's approval or rejection becomes - a Merkle fact with `:provenance :human-reviewed`. - -*** What makes this better than Claude Code - -| Dimension | Claude Code | Passepartout Planner | -|-----------|-------------|---------------------| -| Planning | Prompt-based, implicit | Screamer CSP, explicit, verified | -| Step ordering | Greedy, every step costs tokens | Dependency-ordered, zero-token constraint check | -| Rollback | Limited (git reset, no per-step) | Merkle snapshot per step, instant rollback | -| Scope control | Prompt-based ("only touch auth files") | ACL2-verified write scope, cannot escape | -| Cost | $0.50-$2 per refactoring session | Near-zero (CPU cycles for planning, LLM for code only) | -| Final proof | None — you trust that tests caught everything | Merkle chain from before→after, ACL2-verified | - -A software ecosystem changing hardware economics has never happened before. -Passepartout's most realistic path: verification appliances for regulated -industries — RISC-V cores with Lisp microcode on FPGA, sold as hardened -devices for healthcare compliance, defense, and industrial control. - -Not a general-purpose Lisp Machine replacing laptops. A specialized device -where correctness is worth paying for. If such appliances sell in the -hundreds of thousands, the economics of a custom Lisp ASIC start to make -sense. The reversal is not Lisp returning as a general platform, but Lisp -winning a vertical important enough to justify its own silicon. - -The path: Passepartout software (AGPL) → creates demand for verified -infrastructure → verification appliance (FPGA, RISC-V + Lisp μcode) → -high-volume niche → custom ASIC economics viable → Lisp native hardware -exists for the first time since the Symbolics era. - -** Lisp vs C for embedded systems - -- Lisp can match C for low-level work through compile-to-C paths (ECL, - PreScheme) or tiny Lisps (uLisp, FemtoLisp, BitLisp for RISC-V) -- The GC is the hard wall for hard real-time; mitigated by pre-allocation, - no-alloc hot paths, or real-time GC -- Most practical path: "Lisp as macro language for C" — generate C from - Lisp macros, ship the compiled binary. This is how NASA's Deep Space 1 - worked: Lisp planning on Earth generated commands for C flight software. -- The Lisp Machine on commodity FPGA (RISC-V softcore + Lisp μcode on - Artix-7 / iCE40) is the ambitious path — Lisp down to the metal for $50. - -** Microbiology works like Lisp, not C - -Striking parallels: - -1. Homoiconicity — DNA is code and data in the same molecule; no separate - source and binary -2. Hot-reloadable image — alternative splicing, epigenetic marks, - post-translational modifications change the running program without - restart -3. Automatic memory management — proteasomes degrade misfolded proteins, - autophagy recycles organelles; the cell never calls free() -4. Interpreted dynamic language — DNA → RNA → ribosome (interpreter) → - protein; no static compilation step -5. Self-modifying source — CRISPR, transposons, DNA repair modify the - genome at runtime; eval on the genome -6. Duck typing — protein folding depends on chemical environment, not - type declarations; interfaces are shape-matching, not compiler-checked -7. Concurrent real-time GC — apoptosis breaks down cell components for - recycling by neighboring cells; the collector is external to the object - -Biology chose the Lisp model because it is more robust, adaptable, and -evolvable. Evolution paid for the overhead (GC, interpretation, dynamic -dispatch) with parallelism and redundancy. It optimized for survival in -an unpredictable environment, not peak single-thread throughput. - -Biology is the proof that the Lisp model can be efficient at planetary -scale, running on hardware that self-assembles from food. The ceiling -Passepartout aims at is still far below the system that wrote itself -in DNA. diff --git a/ideas/patent-strategy.org b/ideas/patent-strategy.org index 8214e08..6c2e7e4 100644 --- a/ideas/patent-strategy.org +++ b/ideas/patent-strategy.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: caaeee11-ba6f-5566-aecd-f171b4c459c0 :END: #+title: Patent Strategy @@ -19,4 +20,4 @@ **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 [[file:licensing.org][licensing]] strategy and create [[file:moats.org][moats]] against competitors. +**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. diff --git a/ideas/pds-as-a-service.org b/ideas/pds-as-a-service.org index 1999e97..5ddb384 100644 --- a/ideas/pds-as-a-service.org +++ b/ideas/pds-as-a-service.org @@ -1,10 +1,11 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 1a2b38df-20ba-58ca-ba55-a072be67bd0d :END: #+title: Personal Data Store as a Service #+filetags: :passepartout:agora:revenue:pds:saas: -Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on [[file:agora.org][Agora]] can be self-hosted (free, AGPL) or hosted by the early player. +Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] can be self-hosted (free, AGPL) or hosted by the early player. - **Free tier (self-hosted):** full AGPL PDS, runs on any Lisp host, full control, no cost - **Basic hosted tier:** $10-$20/month, 10GB fact store, 10M queries/month, automated backup, automatic upgrades @@ -15,4 +16,4 @@ The free self-hosted version drives adoption and trust (you can inspect every li Target: 100K subscribers at $15/month average = $18M/yr recurring, near-zero marginal cost per additional subscriber (the symbolic engine is CPU-bound, not per-user metered). -Combined with [[file:agora-usernames.org][premium usernames]]: $28M/yr from Agora services alone before [[file:compute-marketplace.org][compute marketplace]] revenue. The hosted model also creates [[file:infrastructure-lock-in.org][infrastructure lock-in]] as users build their Merkle fact stores on the platform, making migration costly. The AGPL licensing model is described in [[file:licensing.org][Licensing]]. +Combined with [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]]: $28M/yr from Agora services alone before [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] revenue. The hosted model also creates [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as users build their Merkle fact stores on the platform, making migration costly. The AGPL [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] model is described in [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing]]. diff --git a/ideas/revenue-hub.org b/ideas/revenue-hub.org index b7bec14..308179c 100644 --- a/ideas/revenue-hub.org +++ b/ideas/revenue-hub.org @@ -1,24 +1,25 @@ :PROPERTIES: +:ID: ed05cab4-88e9-4e25-b7c9-346fa39c69a0 :ID: revenue-hub :CREATED: [2026-05-23 Sat] :END: #+title: Revenue Streams — Overview #+filetags: :passepartout:revenue:index:business-model: -This page is the entry point for revenue generation thinking across all three triad components. Revenue splits cleanly across the two development phases defined in [[file:time-estimates.org][time estimates]]. Each component enables different revenue primitives. +This page is the entry point for revenue generation thinking across all three triad components. Revenue splits cleanly across the two development phases defined in [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]]. Each component enables different revenue primitives. * Revenue by Triad Component ** Logos (the mind) — Revenue streams -Existing coverage — [[file:verification-appliance.org][Verification appliance]], [[file:domain-gate-packages.org][Domain gate packages]], [[file:evaluation-harness.org][Evaluation harness]], [[file:compute-marketplace.org][Compute marketplace]], [[file:verified-skill-marketplace.org][Verified skill marketplace]]: +Existing coverage — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness]], [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]], [[id:d84679f1-c0c5-5be4-b19c-6573560640ee][Verified skill marketplace]]: | Stream | Phase | Description | |--------+-------+-------------| -| Verification appliance | Zero | FPGA/Tenstorrent pre-loaded with Passepartout + gate rules | +| Verification appliance | Zero | FPGA/Tenstorrent pre-loaded with [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] + gate rules | | Domain gate packages | Zero | SaaS subscriptions per compliance domain | | Evaluation harness | Zero | Certification-as-a-service, regression suite access | -| Compute marketplace | Both | Verified symbolic engine cycles via [[file:agora.org][Agora]] | +| Compute marketplace | Both | Verified symbolic engine cycles via [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | | Verified skill marketplace | End State | Commission on third-party gate rules | *** Unexplored Logos streams @@ -28,7 +29,7 @@ Existing coverage — [[file:verification-appliance.org][Verification appliance] | Verified API gateway | Zero | Drop-in proxy for LLM calls. Passepartout verifies inputs, outputs, and provenance. Enterprise customers get a verifiable audit trail for every API call. Near-term product: run your OpenAI/Anthropic calls through Passepartout and get proof. | | Agent-as-a-service | Zero | Cloud-hosted Passepartout instances. Pay-per-verification or monthly subscription. The compute marketplace for individuals who don't self-host. | | Continuous compliance monitoring | Zero | Watch a deployment, continuously verify it against regulatory gate rules, alert on drift. Annual contract per monitored system. The evaluation harness as a product. | -| Gate rule SDK licensing | Both | Commercial license for the gate rule development toolkit. Free for open-source rules, paid for proprietary enterprise rule development. | +| Gate rule SDK [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] | Both | Commercial license for the gate rule development toolkit. Free for open-source rules, paid for proprietary enterprise rule development. | | Migration pipeline | Zero | Convert existing codebases to verified Lisp. Automated SaaS (point at a repo, get back a verified version). Per-enterprise: $50K-$500K for full migration. | | Forensics / incident response | Zero | Merkle memory provides tamper-proof audit. Post-incident: produce an irrefutable chain of what happened, who authorized it, what gates were triggered. Service offering. | | Proof repository marketplace | End State | Pre-verified proof libraries per domain (crypto, medical device, finance). Access to accumulated proof strategies from thousands of runs. | @@ -46,7 +47,7 @@ Existing coverage: essentially none beyond hardware sales. | Stream | Phase | Rationale | |--------+-------+-----------| | Lisp Machine hardware | End State | Tenstorrent/FPGA appliances. Hardware margins + recurring gate rules. | -| [[file:stoa.org][Stoa]] premium | Both | Enterprise features: SSO, audit logging, compliance reports, team management, centralized policy enforcement. Annual seat license. | +| [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] premium | Both | Enterprise features: SSO, audit logging, compliance reports, team management, centralized policy enforcement. Annual seat license. | | Plugin and theme marketplace | End State | Verified plugins for Stoa (editors, browsers, shells, tools). Commission on each sale. Developer ecosystem. App Store for the Lisp Machine. | | Commercial Lisp image distribution | Both | Verified, signed, compatibility-guaranteed Stoa images. Free self-build (AGPL), paid for certified builds with SLAs. | | Enterprise Stoa deployment | Zero | Tools for deploying Stoa across an organization: fleet management, unified gate policy, compliance dashboard. Annual license. | @@ -57,7 +58,7 @@ Key insight: Stoa does not need the full Lisp Machine to generate revenue. Stoa ** Agora (the society) — Revenue streams -Existing coverage — [[file:agora-usernames.org][Agora usernames]], [[file:pds-as-a-service.org][PDS as a service]], [[file:compute-marketplace.org][Compute marketplace]]: +Existing coverage — [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Agora usernames]], [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]], [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]: | Stream | Phase | Description | |--------+-------+-------------| @@ -83,7 +84,7 @@ The most fertile ground is contracts. DIDs provide identity, DIDComm provides co The contract platform is the kill application for Agora. Ethereum proved demand for verifiable contracts at $20B+/yr in transaction fees. Agora's version is strictly better: ACL2 proves contract /correctness/ (not just valid execution), gate rules encode real-world regulations directly, and the PDS provides persistent state without a global trie bottleneck. -See [[file:agora-contracts.org][Agora contracts]] for the full analysis. +See [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]] for the full analysis. * Revenue by Development Phase @@ -111,13 +112,13 @@ See [[file:agora-contracts.org][Agora contracts]] for the full analysis. | Multi-instance governance | Agora | Large | Enterprise | Annual | | Namespace sub-leasing | Agora | Small | Individuals | Per-transaction | -Phase Zero target: $2M-$12M/year (from [[file:investment-thesis.org][investment thesis]]), with upside from verified API gateway and compliance monitoring pushing toward $15-20M. +Phase Zero target: $2M-$12M/year (from [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]]), with upside from verified API gateway and compliance monitoring pushing toward $15-20M. ** End State streams (full Lisp Machine, 2-5 years) | Stream | Component | TAM | Revenue type | |--------+----------+-----+--------------| -| [[file:verification-monopoly.org][Verification monopoly]] | Logos/All | $1B+ | Certification | +| [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] | Logos/All | $1B+ | Certification | | Infrastructure lock-in | All | $100B+ | Rent extraction | | Compute marketplace | Agora | Venture-scale | Transaction fees | | Lisp Machine hardware | Stoa | Large | Hardware + subs | @@ -132,7 +133,7 @@ Phase Zero target: $2M-$12M/year (from [[file:investment-thesis.org][investment * Orders-of-Magnitude Risk Map -Using the [[file:orders-of-magnitude-time.org][orders-of-magnitude framework]], each revenue stream lives at a different scale: +Using the [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude framework]], each revenue stream lives at a different scale: | Scale | Representative streams | Failure mode | |-------+-----------------------+--------------| @@ -156,11 +157,11 @@ The phase-zero streams are all direct enterprise sales with short cycles and cle * Detailed References -- [[file:passepartout-economics.org][Passepartout economics (full thesis)]] — the unified economics document -- [[file:investment-thesis.org][Investment thesis]] — three revenue horizons, $2M to $1B+ -- [[file:cost-structure.org][Cost structure and zero marginal cost]] -- [[file:compliance/revenue-table.org][Compliance [[file:compliance/revenue-table.org][revenue table]]]] — concrete pricing per framework -- [[file:compliance/compliance-index.org][Compliance framework index]] — 41 frameworks by region and priority -- [[file:compliance/first-mover-window.org][First-mover window analysis]] -- [[file:time-estimates.org][Development timeline]] — Phase Zero vs End State -- [[file:licensing.org][Licensing strategy]] — AGPL + commercial +- [[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 diff --git a/ideas/self-driving-lisp-machine.org b/ideas/self-driving-lisp-machine.org index 8010033..dcf85a2 100644 --- a/ideas/self-driving-lisp-machine.org +++ b/ideas/self-driving-lisp-machine.org @@ -1,15 +1,16 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70 :END: #+title: The Self-Driving Lisp Machine #+filetags: :passepartout:lisp-machine:hardware:riscv:tenstorrent: -A Tenstorrent P150 (~72 RISC-V Tensix cores) running Passepartout: 72 RISC-V cores running Lisp microcode, one core dedicated to ACL2, one to Screamer, the rest to gate verification and fact store operations. +A Tenstorrent P150 (~72 RISC-V Tensix cores) running [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]: 72 RISC-V cores running Lisp microcode, one core dedicated to ACL2, one to Screamer, the rest to gate verification and fact store operations. The self-driving threshold: the system can synthesize and load its own FPGA microcode or Tensix dispatch programs from within the running Lisp image. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower. -Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[file:sufficiency-flip.org][flip to symbolic sufficiency]] within days to weeks of ingestion. +Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[id:efc76898-03f7-57ba-923d-35d65da88bb7][flip to symbolic sufficiency]] within days to weeks of ingestion. -**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[file:time-estimates.org][time estimates]] for the velocity model behind these numbers. +**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]] for the velocity model behind these numbers. -The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[file:lisp-machine-security.org][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[file:verification-appliance.org][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[file:lisp-economics.org][why Lisp is economically viable now]] and [[file:upgrade-lifecycle.org][upgrade lifecycle]] for the economic and deployment foundations. +The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][why Lisp is economically viable now]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] for the economic and deployment foundations. diff --git a/ideas/stoa.org b/ideas/stoa-overview.org similarity index 57% rename from ideas/stoa.org rename to ideas/stoa-overview.org index 9e9faf3..82caa37 100644 --- a/ideas/stoa.org +++ b/ideas/stoa-overview.org @@ -1,4 +1,6 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 42c86e6f-4f27-4993-8238-b7bc7d15fb7b :ID: c3b3dc41-945f-54e9-84eb-ca014114f1be :END: #+title: Stoa — The Porch (Environment) @@ -10,7 +12,7 @@ Stoa is the user environment — a single Lisp image where editor, browser, shel - v2.0.0: Lish editor + Nyxt browser (Stage 1, Qt/WebKit) + Lish shell - v3.0.0+: Cannibalization — replace Qt with Lisp-native layout, reduce WebKit to pixel-painting, eventually pure-Lisp browser and window management - v4.0.0: Native inference — llama.cpp FFI in-process, DSL-compiled model architectures, live surgery on cognition -- v5.0.0: Hardware — tagged RISC-V architecture via TinyTapeout, FPGA prototype, hardware GC via dedicated bus master +- v5.0.0: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] — tagged RISC-V architecture via TinyTapeout, FPGA prototype, hardware GC via dedicated bus master - v6.0.0: True agency — world models, temporal reasoning, goal persistence across restarts -The architectural principle: Stoa is not a collection of clients connecting to a daemon. The Dispatcher gate stack [[file:verification-appliance.org][verifies every action]] regardless of who initiated it. The distinction between "tool" and "self" dissolves. The ultimate goal is a [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] running on custom hardware. +The architectural principle: Stoa is not a collection of clients connecting to a daemon. The Dispatcher gate stack [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verifies every action]] regardless of who initiated it. The distinction between "tool" and "self" dissolves. The ultimate goal is a [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] running on custom hardware. diff --git a/ideas/stoa/_index.org b/ideas/stoa/_index.org new file mode 100644 index 0000000..ea1dd4e --- /dev/null +++ b/ideas/stoa/_index.org @@ -0,0 +1,28 @@ +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: c3b3dc41-945f-54e9-84eb-ca014114f1be +:END: +#+title: Stoa — The Porch (Environment) +#+filetags: :passepartout:stoa:editor:browser:hardware: + +Stoa (Στοά) is the body/environment layer of the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][triad]] — editor, browser, shell, and infrastructure all running in a single [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp image]]. The [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Dispatcher gate stack]] verifies every action regardless of who initiated it. The distinction between "tool" and "self" dissolves. + +The full roadmap is documented across seven stages on this page, each covering engineering, security, cost, timeline, and practical implications. Start reading from [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]]. + +The three layers of the triad: +- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]] — the mind: recorded discourse, verified reasoning, the gate +- Stoa — the porch: environment, infrastructure, the verified Lisp machine +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] — the society: identity, communication, contracts + +Key features across all stages: +- **No kernel, no process boundaries, no memory corruption** — the verified Lisp evaluator is the only computation substrate +- **Merkle-verified memory graph** — every object has a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][structural hash]], composable proofs of integrity +- **[[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-stack authorization]]** — the Dispatcher is the only path to state mutation, verified in [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2]] +- **Dual-unit ASIC** — symbolic core (tagged RISC-V) + tensor unit (cons-cell-native matmul), one chip, one proof +- **In-process LLM inference** under [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-level token interception]] — no API calls, no sandbox to escape +- **Plist-native weights** — every weight Merkle-verified, provenance from training to inference +- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verified fine-tuning]]** — every gradient step authorized against policy, data consent per example +- **Neural world model** (LeCun type) — sensory-physical prediction, falsified against the accumulated observation DAG +- **Common sense** enters through three channels (LLM, world model, causal inference) and is brought under gate control through falsification + +The ultimate goal is a [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] running on custom dual-unit silicon. diff --git a/ideas/stoa/stoa-stage-0-now.org b/ideas/stoa/stoa-stage-0-now.org new file mode 100644 index 0000000..f74f78d --- /dev/null +++ b/ideas/stoa/stoa-stage-0-now.org @@ -0,0 +1,84 @@ +--- +title: Stage 0 — Now (Conventional Computing) +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] + +# Stage 0: Now + +*Summary: The conventional stack as it exists today. Not a design — the starting point.* + +This is the baseline we inherit. Linux on x86, C/Rust toolchain, +web-based applications, GPU compute for AI, TCP/IP networking. Every layer +is independently built and independently untrusted. + +The conventional stack spans every layer: + +| Layer | Threats | +|-------+---------| +| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] | silicon trojan, rowhammer, speculation side channels (spectre/meltdown), physical theft | +| Firmware | UEFI implants, SMM rootkits, ME backdoor — unaccountable opaque processors | +| OS kernel | privilege escalation, syscall bugs, driver exploits — CVEs weekly | +| Compiler | Ken Thompson's "Trusting Trust" — compiler backdoors invisible at source level | +| Runtime | heap corruption, use-after-free, buffer overflow — the dominant malware vector | +| Network | MITM, TLS state machine bugs, DNS poisoning, routing attacks | +| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain | +| User | phishing, social engineering, credential theft | +| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability | + +**Key property:** Every layer is independent and untrusted. No layer can vouch +for any other. Security is *empirical* — "no bugs found in this release" — not +deductive. + +## What is eliminated + +Nothing. Every threat that has ever existed in computing exists at Stage 0. + +## What does this cost? + +- **Patching treadmill** — the industry spends uncountable hours applying CVEs. + Every OS update risks regressions. Security teams are measured by mean time + to detect, not mean time to prevent. +- **Incident response** — breaches are expected, not exceptional. The average + dwell time (attacker inside system before detection) is months. +- **Bug bounties** — a market failure tax: pay researchers to find the bugs + your toolchain inevitably produces. +- **Complexity tax** — every OS, driver, library, and daemon is a potential + entry point. The attack surface is unknowable because no layer can vouch + for any other. +- **No deductive guarantees** — security is empirical. "No bugs found in this + release" does not mean no bugs exist. + +Even with all this spending, the system is not provably secure. You can't +audit your way to deductive guarantees on a conventional stack. + +## What does this enable? + +Everything we have. The entire software ecosystem, all hardware, every network. +The cost and the capability are the same thing — maximum flexibility, minimum +provable trust. + +## When is this viable? + +Today. This is where we are. + +## In practice + +We have normalized reactive security because the alternative — building a +provably secure stack — is considered too expensive. Every company of +meaningful size has a security team whose job is to detect when they've been +breached, not to prevent it. The average dwell time is measured in months. +This is treated as normal because the alternative — a provably secure stack — +is seen as prohibitively expensive. This roadmap is the argument that the +provable alternative is not only possible, but the inevitable destination. +The question is not whether to build it, but at what pace. + +← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc1-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-1-agora.org b/ideas/stoa/stoa-stage-1-agora.org new file mode 100644 index 0000000..82114f3 --- /dev/null +++ b/ideas/stoa/stoa-stage-1-agora.org @@ -0,0 +1,85 @@ +--- +title: Stage 1 — Agora (In-Transit Integrity) +type: reference +tags: :stoa:roadmap:agora: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] + +# Stage 1: [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] + +*Summary: Every message is signed, DAG-tracked, and content-addressed. +Communication becomes provable — when you choose it to be.* + +## What is added + +- DID-based identity per participant (Ed25519 key pairs) +- Message-level authentication via JWE/JWS envelopes +- DAG of content-addressed messages for auditable history +- Channels for directed and broadcast communication +- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy +- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC) +- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording) +- Pseudonymous Personas for deniable identity +- Relays as transient routers (pub/sub model, no long-term storage) +- Onion routing between PDSs for metadata masking + +## What is eliminated + +- **Message forgery** — every message is signed; you prove the sender +- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain +- **Impersonation / spoofing** — DID identity keys, not usernames +- **Replay attacks** — nonces and sequence numbers per message +- **MITM on Agora-mediated channels** — end-to-end signatures; relays need no trust +- **Loss of message history** — DAG is append-only and content-addressed + +## What does this cost? + +- **Crypto overhead per message** — every message requires signing and verification. + For high-throughput channels, this adds latency and CPU cost +- **DAG storage grows unbounded** — the append-only log never shrinks unless GC + is explicitly designed +- **Key management burden** — DID resolution, key rotation, revocation. Lost keys + mean lost identity. No "reset password" for DIDs +- **No anonymous participation by default** — DIDs tie every message to a + cryptographic identity. Pseudonymity is a Persona choice, not the baseline + +## What does this enable? + +Provable communication infrastructure. You can prove who said what, when, and +to whom — or choose off-the-record privacy. Every subsequent stage builds on +this DAG: it is the source of truth for evidence, audit, and the accumulated +knowledge that later stages use for falsification. + +## When is this viable? + +Today. Agora is a protocol design that can be deployed on existing networks. +The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]. + +## In practice + +Communication becomes provable — but only when the user chooses. Agora's Note +primitive supports the full spectrum: persistent DAG-stored messages for audit +and compliance, ephemeral Notes that self-destruct, and full Off-the-Record +(OTR) mode that bypasses PDS storage entirely. + +The user chooses per-channel or per-message: permanent and attributable for +contracts and governance, ephemeral and deniable for private conversation. The +infrastructure enforces each choice — PDS garbage-collects expired CIDs, Relays +drop them from routing tables, clients shed message keys after display. Agora +replaces trust with evidence where evidence is wanted; elsewhere it provides +privacy by design. + +Agora does not secure the endpoint. The machines running Agora clients can +still be compromised at the OS, compiler, or hardware level. The keys are on +those machines — malware that compromises an endpoint can sign messages using +the endpoint's keys. The messages are authentic; the sender wasn't. Agora +carries the authorization; it doesn't evaluate it. + +← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc2-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-2-logos.org b/ideas/stoa/stoa-stage-2-logos.org new file mode 100644 index 0000000..07b54bd --- /dev/null +++ b/ideas/stoa/stoa-stage-2-logos.org @@ -0,0 +1,84 @@ +--- +title: Stage 2 — Logos (Verified Reasoning Layer) +type: reference +tags: :stoa:roadmap:logos: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] + +# Stage 2: [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]] + +*Summary: A verified gate evaluates every action against formal policy. +Capability-based authorization. "Root" as an attack target no longer exists.* + +## What is added + +- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action +- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity +- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against: + - Is the action authorized by policy? + - Does the capability grant this operation? + - Does the action violate any system invariant? +- Decision procedure formalized in ACL2, machine-checked +- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]) + +## What is eliminated + +- **Unauthorized actions** — even a fully compromised endpoint cannot perform an + action the gate blocks. The gate is the final arbiter, not the OS or client. +- **Privilege escalation** — no amount of subversion below the gate can grant + capabilities the policy doesn't allow. The gate checks capability tokens, + not caller identity. +- **"Root" as a meaningful attack target** — there is no root in Logos. There + are capabilities, and capabilities are checked. + +## What does this cost? + +- **Verification latency** — every action is checked against policy. Complex + policies add delay +- **Policy formalization burden** — everything must be written explicitly. Gaps + block legitimate actions (false positives) or allow undesirable ones (false + negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on + unformalized human intuition. Everything must be written down +- **Capability management complexity** — distributing, revoking, auditing + capabilities is itself security-critical. A leaked capability is + indistinguishable from an authorized action +- **Policy drift** — as the system evolves, the policy must evolve with it. + Out-of-date policy blocks new legitimate uses +- **Proof maintenance** — the gate's decision procedure is verified, but the + policy is not. Each policy change needs new proof +- **The gate runs on untrusted hardware** — if the OS or hardware is + compromised, the gate's guarantees are meaningless. The attacker can skip + the gate or modify its output. Logos's full power arrives at Stage 3 + +## What does this enable? + +The system can now say "no" to unauthorized actions even when the endpoint is +fully compromised. Security is no longer dependent on client integrity. This is +the first layer where deductive guarantees enter the picture — but they are +contingent on Stage 3's trust substrate. + +## When is this viable? + +Today as a software layer on conventional hardware, but with limited guarantees +(the gate itself can be compromised by the host OS). Full power arrives at +Stage 3 when the gate runs on the verified Lisp machine. + +## In practice + +The gate is the final arbiter, not the OS or the client. But it runs on a +machine it doesn't trust. Users must weigh the benefit (unauthorized actions +blocked) against the operational cost (everything must be explicitly authorized +in policy). For high-stakes environments, the trade-off is worth it. For casual +use, the friction may lead users to bypass the gate. + +*Logos's full power arrives when it runs on Stoa. Before that, it's a +correctness proof running on an untrusted substrate.* + +← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc3-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-3-stoa.org b/ideas/stoa/stoa-stage-3-stoa.org new file mode 100644 index 0000000..587cf55 --- /dev/null +++ b/ideas/stoa/stoa-stage-3-stoa.org @@ -0,0 +1,134 @@ +--- +title: Stage 3 — Stoa (Verified Infrastructure) +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] + +# Stage 3: Stoa + +*Summary: The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp machine]]. One image, one [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]], one [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate stack]]. +No kernel, no process boundaries, no memory corruption. [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] and Logos are no +longer separate components — they are properties of the same machine.* + +## What is added + +Stoa spans three engineering phases that converge on the same architecture: + +### Phase A — Software emergence (2-3 years) + +The Lisp machine emerges inside a host OS. A single SBCL image absorbs every +user interface into one address space: + +- **Lish editor:** a multi-threaded Common Lisp editor via Qt/QML (EQL5). + The agent's system prompt lives in an Org buffer — visible, editable, + hot-reloadable. Org-babel for inline evaluation. The editor IS the daemon. +- **Nyxt browser:** Common Lisp web browser in three erosion stages: + Qt+WebKit → S-expression DOM → pure Lisp layout. Web content is natively + queryable and modifiable as Lisp data structures. +- **Lish shell:** text-stream replaced by plists. Pipe becomes function + composition. Scripts become Lisp functions on memory objects. +- **Emacs migration (three phases):** parasite bridge (v0.4.0) → ELisp + compatibility layer inside CL image → native CL implementations. +- **Minibuffer:** universal command surface — edit files, navigate web, + run Lisp expressions, invoke agent commands. + +### Phase B — Cannibalization (3-5 years) + +Gradual replacement of every external dependency with native Lisp: + +- TCP bridge → internal function call (single SBCL image) +- QML layout → Lisp layout (Yoga FFI as intermediate) +- WebKit → Lisp DOM + Lisp-native layout engine +- Qt widgets → Lisp-native X11/Wayland bindings +- Font rendering → HarfBuzz FFI → Lisp replacement +- Qt event loop → SBCL native thread scheduler +- Linux bootloader → Stage0 Lisp bootstrap (500 bytes hex → self-hosting Lisp) + +The system remains usable at every step. Each replacement is a component swap. + +### Phase C — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] (5-10 years) + +The dual-unit ASIC: one chip, two compute units, one Merkle-verified memory graph: + +1. **Symbolic core** — tagged RISC-V (4-8 type tag bits per word, hardware + type checking, single-cycle LISP.CAR/LISP.CDR). Runs gate stack, cognitive + loop, general Lisp evaluation. +2. **Tensor unit** — cons-cell-native matrix compute. Walks the tensor DAG + directly for attention and matmul. No FFI boundary, no GPU mirror. + +Prototyping: TinyTapeout (130nm, 8-bit tagged toy) → FPGA core (DE10-Nano, +VexRiscv) → FPGA tensor (Xilinx VU9P, cons-cell matmul) → shuttle (12nm, +tagged RISC-V at 100-300MHz) → ASIC (5nm, both units on die). + +Phase migration: parasitic FPGA PCIe card → functional hijacking → driver +cannibalization → self-hosting (Stage0 on bare metal). + +Hardware GC: dedicated Scavenger bus master runs GC in parallel with symbolic +and tensor computation. Persistent NVRAM: boot to exactly where you left off. + +## What is eliminated + +- **Memory corruption entirely** — verified Lisp evaluator, no undefined + behavior. No buffer overflow, use-after-free, type confusion. +- **OS kernel exploitation** — no kernel. Evaluator is the substrate. No + syscalls, no drivers, no MMU to confuse. +- **Compiler backdoors** — Lisp-to-Lisp compilation within the verified + evaluator. [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Ken Thompson's "Trusting Trust"]] is structurally impossible. +- **Malware / viruses / worms** — no "download and execute" path that bypasses + the gate. The evaluator only runs objects in the verified memory graph. +- **Supply chain at binary level** — every object has a Merkle chain to its + origin. A dependency is a pointer, not a file. +- **The Stoa ↔ Logos ↔ Agora composition problem** — one address space, one + semantics, one proof. The interface between them is an internal relationship. + +## What does this cost? + +- **Lisp tax on everything** — verified execution is 2-10x slower than + optimized C on equivalent hardware. Symbolic core is designed to minimize + this; tensor unit sidesteps it for neural compute +- **No backward compatibility** — existing software doesn't run on Stoa. No + Linux binaries, no x86 drivers, no GPU compute stacks (without mirror path) +- **Single address space fragility** — no process isolation. A bug in the + editor can corrupt the browser. One crash radius, one machine +- **Massive engineering investment** — shortest plausible timeline to a usable + software Lisp machine is 2-3 years; ASIC 5-10 years +- **Ecosystem abandonment** — no open-source packages, no shared libraries. + Everything is in the Merkle memory graph or it doesn't exist + +## What does this enable? + +Deductive security replaces empirical security. Memory bugs — the dominant +attack vector for decades — are structurally eliminated. No more patching for +CVEs. No ASLR, no DEP, no CFI — the class of attacks they mitigate doesn't +exist. Every boot is a fresh verification that the evaluator, memory graph, +and gate stack are intact. + +## When is this viable? + +- **Software (Phase A+B):** 2-3 years on existing hardware. Single SBCL image, + gate stack, Lish/Nyxt/Lish — usable on a developer workstation today. +- **ASIC (Phase C):** 5-10 years. FPGA prototype within 1-2 years, shuttle + within 3-5, commercial foundry 5-10. + +## In practice + +Memory bugs — the dominant attack vector for decades — are structurally +eliminated. No more patching for CVEs. No antivirus, no firewall (at the +machine level — network boundaries remain). A Stoa machine that boots +correctly will not crash from a memory corruption bug, ever. + +But you've given up the entire existing software world. You cannot run Firefox, +Postgres, nginx, Python, or any Linux binary. The machine is a Lisp machine +and everything must be written in Lisp. The practical trade is: absolute +memory safety at the cost of adopting an entirely new computing paradigm. +This is not an upgrade path — it is a replacement. + +← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc4-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-4-inference.org b/ideas/stoa/stoa-stage-4-inference.org new file mode 100644 index 0000000..2d44eea --- /dev/null +++ b/ideas/stoa/stoa-stage-4-inference.org @@ -0,0 +1,95 @@ +--- +title: Stage 4 — Inference (In-Process LLM) +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] + +# Stage 4: Inference + +*Summary: The LLM runs in-process under the gate. Every token is inspected +during generation. No external API, no separate trust domain.* + +## What is added + +- CFFI binding to llama.cpp (or pure-Lisp inference engine) — LLM in the same + SBCL image as the agent, editor, and gate +- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-level token interception]]: the Dispatcher inspects every partial token + sequence during generation. Trajectories that would produce unauthorized + actions are suppressed mid-stream, not filtered after the fact +- Weights loaded from Stoa's Merkle-verified store as a macro-tag blob (one + tagged Lisp object pointing to flat binary) +- Deterministic inference: same input, same output, same hash — auditable + and replayable + +*Two neural components on the same substrate:* Stage 4 hosts the LLM for +generative reasoning and action proposals. The LeCun-type world model (sensory +prediction) joins at Stage 6. Both run on the same tensor unit with the same +plist-native weight architecture and gate-level interception. The LLM proposes +actions to the gate (authorization — binary, deductive). The world model +proposes predictions to the gate (falsification — structural, empirical). The +gate handles both through different procedures. + +## What is eliminated + +- **LLM as a separate trust domain** — no external server, no API call, no + cloud provider to breach +- **Remote inference model attacks** — the model cannot be swapped without + changing the Merkle hash +- **Prompt injection as an action bypass** — the gate sees partial generation. + A jailbreak that would produce an unauthorized action is caught before the + tokens complete +- **Model integrity ambiguity** — you know exactly which model is running, + at which commit, with which hash + +## What does this cost? + +- **~10x compute, RAM, and storage** — the gate evaluates semantics at every + token, not just logits. A model running at 50 tok/s natively runs at ~5 tok/s + under gate-level interception +- **GPU/accelerator constraints** — CFFI to GPU libraries is the bottleneck. + Exotic [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] may not be supported +- **Memory pressure** — the LLM shares the address space with the entire system. + A 70B param model at 4-bit takes ~35GB. At 10x multiplier, effective + conventional-equivalent cost is ~350GB +- **Determinism is double-edged** — auditable but cannot adapt or creatively drift +- **No model parallelism** — Stoa runs on one machine. Frontier-scale models + may be too large for a single address space + +## What does this enable? + +Action proposals from the LLM are intercepted by the gate before they reach +the system. The gate authorizes or denies in real time based on policy, not +on trust in the LLM. This eliminates the entire class of "LLM escaped its +sandbox" attacks. + +## When is this viable? + +- **Server hardware (A100/H100 class, 512GB+ RAM):** today. 5 tok/s on 7B + models is usable for chat +- **Consumer hardware (RTX 5090 class):** 3-5 years +- **On ASIC tensor unit:** the 10x overhead drops closer to 2-5x because the + gate runs on the symbolic core in parallel with inference on the tensor unit + +## In practice + +The LLM is no longer a black box connected by API. The gate watches every +token as it's generated and can stop any generation trajectory that would +produce an unauthorized action. The model is powerful; the gate is in control. + +Chat is noticeably slower — roughly 5 tok/s instead of 50 — but the security +guarantee is structural, not probabilistic. For bulk processing or real-time +applications, the 10x tax may be prohibitive without dedicated acceleration. + +The weights are still a verified *blob* — you know the file's hash but can't +prove anything about individual weights. Training provenance is not tracked. +The inference is FFI-mediated, so trust in llama.cpp remains. + +← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc5-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-5-weights.org b/ideas/stoa/stoa-stage-5-weights.org new file mode 100644 index 0000000..abf569f --- /dev/null +++ b/ideas/stoa/stoa-stage-5-weights.org @@ -0,0 +1,88 @@ +--- +title: Stage 5 — Weights (Plist-Native) +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]] + +# Stage 5: Weights + +*Summary: Every weight is a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp object in the Merkle memory graph]]. You can +prove not just that the model file is unmodified, but that this specific +attention head has the weight vector it should have.* + +## What is added + +- Plist-native weight graph: weights are typed plists structured as a tree of + tensors DAG, not a flat blob +- Structural weight diffs: the response to "which weight changed?" is "layer 17, + head 3, weights 2048-4096 differ by vector V" — not "the blob hash changed" +- Weight provenance chain: the memory graph links each layer to its training + event. A structural property of the weights, not a log entry about them +- No FFI boundary for inference: the tensor unit (or GPU mirror) operates on + Lisp objects directly. The evaluator's verified semantics cover computation + +## What is eliminated + +- **Sub-tensor granularity tampering** — you can verify individual attention + heads, not just the blob +- **Weight provenance ambiguity** — every weight links to its origin event +- **The FFI inference gap** — inference runs on Lisp data directly. No C/GPU + code outside the evaluator's semantics + +## What does this cost? + +- **~100x compute, RAM, and storage on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] (GPU path).** + A 7B model requiring 4GB as GGUF needs ~400GB as plist-native weights on a + GPU. GPUs are built for flat arrays and SIMT; cons-cell traversal is their + worst case +- **This 100x is GPU-relative, not fundamental.** An ASIC tensor unit with + tagged memory, Merkle hashing in the memory controller, and sparse DAG- + walking matmul closes the gap to 2-5x +- **Two implementation paths:** + 1. *GPU path (near-term):* plist-native weights as gold standard for + provenance, GPU-native mirror for compute, Merkle-verifiable loading + protocol. Cost: 100x storage, ~2-3x load-time overhead + 2. *ASIC path (destination):* tensor unit speaks cons-cell. No mirror + needed. Cost: 2-5x over GPU for dense matmul +- **GC pressure** — plist-native weights produce enormous GC load. The + Scavenger handles this on ASIC; on GPU path the mirror avoids it +- **Mixed-precision is complex** — 4-bit and 8-bit quantization destroy + pointer structure. Full float32/64 may be the only practical option + +## What does this enable? + +You can prove exactly what your model is and that it hasn't been modified. +The Merkle chain from training event to individual weight is structural, not +logged. Fine-tuning provenance becomes as verifiable as the code running on +the machine. This is the stage where hardware choice determines practical +viability. + +## When is this viable? + +- **GPU hybrid path:** today. Works on any Stoa system with a GPU +- **ASIC native path:** 5-10 years (tensor unit on the dual-unit chip) + +## In practice + +Every individual weight is Merkle-verified, structurally tracked, and computed +within the Lisp evaluator's verified semantics. The FFI trust gap is closed. + +Stage 5 is where hardware choice determines practical viability. The GPU path +works today but carries the storage overhead of two representations (plist gold +standard + GPU mirror) and the load-time verification cost. The ASIC path is +the destination — one representation, one chip, no workaround. Most users will +use the GPU path for years before the ASIC becomes available. + +Either path is viable. The GPU path can be built today with existing hardware. +The ASIC path is the destination — a single verified chip that doesn't need +the hybrid workaround. + +← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc6-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-6-training.org b/ideas/stoa/stoa-stage-6-training.org new file mode 100644 index 0000000..b9efb13 --- /dev/null +++ b/ideas/stoa/stoa-stage-6-training.org @@ -0,0 +1,124 @@ +--- +title: Stage 6 — Training (Verified Fine-Tuning + World Model) +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]] + +# Stage 6: Training + +*Summary: Verified fine-tuning under the gate. Every example checked for consent. +Every gradient application is a verified state transition. The neural world model +runs in parallel with the LLM for sensory-physical prediction.* + +## What is added + +### Verified fine-tuning + +The training loop is not a script. It is a verified function in the evaluator: + +1. Read a training example from the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]] +2. Check the example's authorization tag against [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][policy]] +3. Compute the gradient +4. Check gradient constraints (permitted weights, bounded LR, scope limits) +5. Apply the update +6. Record the state transition with a Merkle link to the input + +### The neural world model (LeCun type) + +A second neural network runs on the tensor unit alongside the LLM. It predicts +sensory and physical dynamics — object trajectories, scene evolution, low-level +sensor futures. It shares the same plist-native weight architecture and the +same verified training pipeline: + +- **Domain:** physical world prediction (not social — that belongs to the + accumulated knowledge DAG) +- **Training:** imported from conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]. Pretrain elsewhere, + verify import, fine-tune under gate +- **Gate interaction:** the world model proposes predictions to the gate + ("the ball will land at position X"). The gate falsifies predictions against + the accumulated observation DAG after the fact, tracking calibration over + time. This is verification through falsification, not authorization + +### The interaction at Stage 6 + +1. World model predicts sensory outcome: "user will press button in 2 seconds" +2. LLM reasons about the predicted outcome: "if user presses button, C follows" +3. LLM proposes action to gate: "preempt C" +4. Gate checks policy + accumulated knowledge for similar past scenarios +5. Gate authorizes or denies +6. After outcome occurs, gate falsifies world model's prediction against actual + observation, updating calibration score + +## What is eliminated + +- **Data poisoning** — every training example is authorized before gradient + application. Only data tagged with consent is trainable +- **Unauthorized fine-tuning** — training policy specifies scope (layers, LR, + data tags) and the gate enforces all constraints at every step +- **Malicious checkpoint injection** — no checkpoints. Training is a verified + sequence of continuous state transitions +- **Training-time backdoors** — the optimizer function is verified by hash. + A Trojan optimizer fails the gate check because its identity doesn't match + +## What does this cost? + +- **~100x slower than conventional fine-tuning** — building on Stage 5's 100x + overhead (GPU path) plus verified gate checks per example. A LoRA fine-tuning + that takes 2 hours natively takes ~200 hours. Doable overnight, not for rapid + iteration +- **Storage per training step** — every Merkle-tracked state transition adds + to the memory graph. A fine-tuning run could produce hundreds of terabytes + of deltas +- **Only fine-tuning is practical** — full pretraining on Stoa never makes + sense. The 100x overhead is structural. Practical workflow: pretrain on + conventional GPU cluster → import as verified blob → convert to plist-native + under gate → fine-tune in Stoa +- **Data gate latency** — every training example passes through the + authorization gate. For datasets with millions of examples, this pre- + processing step can take days +- **Wrong-spec for training policy** — the training policy is the most + security-critical spec. A compromised admin writing a policy that authorizes + all layers and all data defeats the system through its own verification + +## What does this enable? + +You can train on private data with proof of consent per example. The fine-tuning +history is structural, not logged — every gradient step is Merkle-linked to its +input. The world model gives the system sensorimotor common sense: object +persistence, trajectory prediction, basic physics — grounded in this specific +environment's observations. + +## When is this viable? + +- **Fine-tuning (GPU path):** 3-5 years on server hardware +- **World model:** same timeline — shares the pipeline and tensor unit +- **ASIC native:** when tensor unit silicon arrives (5-10 years) + +## In practice + +Training integrity is guaranteed at every step. Data consent is verified per +example. The optimizer cannot be swapped. Checkpoints cannot be backdoored. +But this system is not for training frontier models — it is for auditing +training runs that happen elsewhere. + +The practical workflow is: pretrain on a conventional GPU cluster, import the +weights into Stoa as a verified blob (Stage 4), then fine-tune within Stoa +under the verified training loop. The pretraining phase remains unverified, +but the fine-tuning phase — where the model gains knowledge of private data +and user preferences — is verified. This is the pragmatic sweet spot. + +The world model learns your environment's physics — how your voice sounds, +how your face moves when confused, how quickly you respond to different +message types. The gate falsifies its predictions, so the world model +converges toward accurate beliefs about your world, not the statistical +average of the internet. + +← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc7-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-stage-7-remaining.org b/ideas/stoa/stoa-stage-7-remaining.org new file mode 100644 index 0000000..0c01f6a --- /dev/null +++ b/ideas/stoa/stoa-stage-7-remaining.org @@ -0,0 +1,171 @@ +--- +title: Stage 7 — What Remains +type: reference +tags: :stoa:roadmap: +created: 2026-05-24 +--- + +← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]] + +# Stage 7: What Remains + +*Summary: At full maturity — dual-unit ASIC, plist-native weights, verified +fine-tuning, neural world model — the following irreducible threats survive. +None can be eliminated by computation alone.* + +## 1. Physical threats + +| Threat | Mitigation | Cost | +|--------|-----------|------| +| Theft | Tamper-resistant packaging (mesh sensors, zeroization on opening) | 10-100x packaging cost | +| EMP | Write-once checkpoint recovery | Mid-transaction data at risk | +| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] trojan in fabrication | Independent fab runs + trace comparison | 2x fab cost minimum | +| Power/EM side channels | Constant-power design, shielding | Power overhead | + +Physical hardening is expensive in direct proportion to the threat level. +If someone steals your Stoa machine, they have your data. Hardware hashing +and encryption slow them down, but the security boundary is now physical. + +## 2. Side channels in the verified model + +The system is functionally correct but may leak information through timing +channels (unless the spec explicitly models timing as an output), access- +pattern channels (verified gates enforce authorization but not non-interference), +and the crypto-verification tension (proving constant-time is a different proof +from proving functional correctness). + +Closing side channels requires 2-4x the verification effort for crypto routines +and oblivious RAM overhead for memory access. Feasible for security-critical +code, impractical for the entire system. For LLM inference, this means an +attacker on the same machine could determine which tokens were generated by +measuring computation time — an open research problem. + +## 3. Oracle poisoning + +The system reasons perfectly about a world that may not exist: + +- **Time** — a clock that can be wrong (NTP drift or attack). The machine + cannot verify which time source is correct +- **DNS / network routing** — BGP hijack reroutes traffic. Cryptographic + envelopes survive, but traffic goes to the wrong destination +- **Sensors / physical input** — the machine processes correctly; the sensor + may be compromised +- **User input** — the single most dangerous oracle. A user who authorizes a + malicious action bypasses every security guarantee. The system is secure; + the user was wrong + +Oracle diversity reduces surface area but introduces Byzantine agreement +problems. The question at Stage 7 shifts from "can the attacker break the +crypto?" to "can the attacker convince the user to press the button?" + +## 4. The bootstrap axiom + +- **Hardware** — silicon correctness cannot be proved from within the system +- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2 kernel]]** — ~500 lines of Lisp accepted, not proved +- **Stage-0 bootstrap** — 500-byte hex sequence, readable by a human in an + afternoon, not mechanically verified + +This is the Godelian boundary of the system. Any attack that modifies the +bootstrap is undetectable from within. Detection requires physical inspection +by a trusted external party. For any real-world threat model, this is not the +weakest link — the user's Wi-Fi password is far more likely to be compromised. + +## 5. The gap between specification and intent + +- **Wrong spec** — the system is provably correct with respect to its formal + spec. If the spec is wrong, the system is correct and wrong +- **Incomplete invariants** — every invariant must be explicitly formalized. + There is no Common Sense fallback (see Appendix A). The most dangerous gaps are unknown ones +- **Emergent failures** — two individually correct operations can produce a + catastrophic result in combination + +The verified system is perfectly correct about the wrong thing. This is the +same class of failure as "the software compiled without warnings and crashed +in production" — but instead of debugging a crash, you are debugging a formal +specification that may take weeks to analyze. + +## 6. The world outside the system + +- **Lying peers** — a peer with a valid DID can give dishonest answers +- **Legal compliance** — a provably correct drug transaction is still illegal +- **Coercion / duress** — the user can be compelled to authorize actions. The + gate faithfully records the authorization + +These externalities cannot be addressed within the system. Any attempt (duress +mode, silent alert) expands the threat model. + +## Appendix A: Common Sense + +**Common sense is the set of generalized expectations about how the world works +that are not derived from specific observations within a particular system.** +That a chair is for sitting. That promises create expectations. That people +contacted at 3am are likely to be annoyed. + +These are distinct from the accumulated knowledge in the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Merkle DAG]], which records +specific observations. Common sense is the *generalization engine*. + +**Three channels in the Stoa architecture:** + +| Channel | Origin | Verification | Granularity | +|---------|--------|-------------|-------------| +| LLM pretraining | Internet-scale corpus | None (probabilistic, distributed) | Vast but opaque | +| World model (LeCun) | Sensory observations + training | Falsified against accumulated DAG | Physical dynamics | +| Causal inference on accumulated knowledge | This system's DAG | Merkle-linked to evidence | Precise but bounded | + +**The falsification loop brings common sense under gate control:** + +1. LLM proposes a common-sense belief: "users don't like being contacted at 3am" +2. The world model formalizes it into a causal edge with a confidence weight +3. The gate queries the accumulated DAG: "how many 3am messages were + well-received in this user's history?" +4. If the evidence confirms, it enters the structural knowledge store +5. If contradictory, the gate rejects it and the LLM must revise + +Over time, common sense that matches this specific user's world becomes +structural knowledge. The system converges toward beliefs aligned with the +user's actual environment, not the statistical average of the internet. + +Common sense is never fully formalized and never fully trusted. It always +remains probabilistic, the LLM's domain, subject to falsification. The gate +does not "have" common sense. It gates access to the structural knowledge +store for beliefs that survive falsification. + +## Appendix B: Summary table of eliminated threats + +| Threat | Eliminated at stage | +|--------|---------------------| +| Memory corruption | 3 — Stoa | +| OS exploitation | 3 — Stoa | +| Malware / viruses / worms | 3 — Stoa | +| Compiler backdoors | 3 — Stoa | +| Message forgery / tampering | 1 — [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | +| MITM on communication | 1 — Agora | +| Unauthorized actions | 2 — Logos (fully at 3) | +| Prompt injection bypassing gate | 4 — In-process inference | +| Weight tampering (blob level) | 4 — Verified blob hash | +| Weight tampering (fine-grained) | 5 — Plist-native weights | +| Data poisoning / unauthorized training | 6 — Verified training + world model | +| Physical theft / EMP | Survives to 7 | +| Side channels | Survives to 7 (specification gap) | +| Oracle poisoning | Survives to 7 (ground truth gap) | +| Wrong spec / human error | Survives to 7 (intent gap) | +| Bootstrap axiom | Survives to 7 (Gödelian boundary) | +| External coercion / law | Survives to 7 (not solvable by computation) | + +The system ends up deductively secure inside a physically and oracularly +bounded envelope. That envelope — the chip, the world, the user — is the +only remaining attack surface worth worrying about. + +Every security guarantee in this document has a price. The question is not +"is this secure?" but "is the price worth it for the threat model it +eliminates?" For a personal AI that holds private conversations and manages +keys, Stages 1-4 may be enough. For a financial system that settles billions, +Stages 5-6 justify the overhead. The progressive threat model is also a +progressive cost-benefit analysis — know the price, then decide. + +← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 4a1f23b0-abc8-4def-9876-543210abcdef +:END: diff --git a/ideas/stoa/stoa-vision-roadmap.org b/ideas/stoa/stoa-vision-roadmap.org new file mode 100644 index 0000000..f4845ba --- /dev/null +++ b/ideas/stoa/stoa-vision-roadmap.org @@ -0,0 +1,44 @@ +--- +title: Stoa Vision Roadmap — The Porch +type: reference +tags: :reference:architecture:stoa: +created: 2026-05-24 +--- + +→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] + +Stoa (Στοά) is the body/environment layer of the [[id:d71df46b-9012-433c-86ce-ec21b78eac5f][triad]]: + +| Logos | The mind — recorded discourse (memex + agent) | +| Stoa | The porch — editor, browser, shell, infrastructure | +| [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | The society — identity, communication, contracts | + +The name comes from the Stoa Poikile (Painted Porch) in ancient Athens, +where Zeno taught Stoic philosophy. The porch was not the philosophy +itself — it was the environment that made discourse possible. Stoa is +the same: not the agent, not the network, but the infrastructure that +hosts both. + +The roadmap and threat model are merged into a single document. +Each stage covers: what is added, what threats are eliminated, what it +costs, what it enables, when it is viable, and what it means in practice. +Appendices at the end cover common sense, the bootstrap axiom, and a +summary table of eliminated threats. + +| Stage | Delivers | Key cost | Timeline | +|-------+----------+----------+----------| +| [[id:4a1f23b0-abc1-4def-9876-543210abcdef][0 — Now]] | Baseline: conventional computing | Patching treadmill, no deductive guarantees | Today | +| [[id:4a1f23b0-abc2-4def-9876-543210abcdef][1 — Agora]] | Communication integrity, provable DAG | Crypto overhead, key management | Today | +| [[id:4a1f23b0-abc3-4def-9876-543210abcdef][2 — Logos]] | Verified gate, capability auth | Policy formalization burden | Today (limited) | +| [[id:4a1f23b0-abc4-4def-9876-543210abcdef][3 — Stoa]] | Lisp machine, Merkle memory, no kernel | Lisp tax, no backward compat, single address space | 2-5yr (soft) / 5-10yr (ASIC) | +| [[id:4a1f23b0-abc5-4def-9876-543210abcdef][4 — Inference]] | In-process LLM, token interception | ~10x compute/RAM/storage | Server now; consumer 3-5yr | +| [[id:4a1f23b0-abc6-4def-9876-543210abcdef][5 — Weights]] | Plist-native weights, weight-level provenance | ~100x GPU / ~2-5x ASIC | GPU hybrid now; ASIC 5-10yr | +| [[id:4a1f23b0-abc7-4def-9876-543210abcdef][6 — Training]] | Verified fine-tuning, neural world model | ~100x fine-tuning only | 3-5yr fine-tuning | +| [[id:4a1f23b0-abc8-4def-9876-543210abcdef][7 — Remaining]] | Physical threats, oracles, speculation, bootstrap axiom | Mitigations are non-computational | Forever | + +→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] + +:PROPERTIES: +:CREATED: [2026-05-24 Sun] +:ID: 3f24ad65-0845-4e75-a3d7-dc4de734a6ac +:END: diff --git a/ideas/sufficiency-flip.org b/ideas/sufficiency-flip.org index e667128..3c2f2c1 100644 --- a/ideas/sufficiency-flip.org +++ b/ideas/sufficiency-flip.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: efc76898-03f7-57ba-923d-35d65da88bb7 :END: #+title: The Per-Domain Sufficiency Flip @@ -21,4 +22,6 @@ The sufficiency flip is not a single event — it happens independently for each 4. Generate contrastive queries for the 5% uncertain rules (one human session, a few hours) 5. Start serving real interactions (empirical loop tightens from first interaction) -For the Lisp Machine bootstrap, every subdomain is software (the most codifiable domain). The entire bootstrap can flip in days to weeks with one human review session. The [[file:gate-rule-encoding.org][gate rule encoding]] process feeds directly into this: each domain's rules are formally encoded and verified. The [[file:time-estimates.org][time estimates]] for the overall project are derived from the time to flip each subdomain. The [[file:cost-structure.org][cost structure]] shifts from LLM-token-heavy to verification-heavy as more domains flip. +The macroeconomic [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] — where token demand compresses and verification hardware emerges — is the industry-level expression of this per-domain sufficiency flip. + +For the Lisp Machine bootstrap, every subdomain is software (the most codifiable domain). The entire bootstrap can flip in days to weeks with one human review session. The [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate rule encoding]] process feeds directly into this: each domain's rules are formally encoded and verified. The [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]] for the overall project are derived from the time to flip each subdomain. The [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] shifts from LLM-token-heavy to verification-heavy as more domains flip. diff --git a/ideas/time-estimates.org b/ideas/time-estimates.org index ebc601e..1f90e3c 100644 --- a/ideas/time-estimates.org +++ b/ideas/time-estimates.org @@ -5,33 +5,33 @@ #+title: Development Velocity and Timeline Estimates #+filetags: :passepartout:economics:development:timeline:velocity:orders-of-magnitude: -The [[file:orders-of-magnitude-time.org][orders-of-magnitude time framework]] reveals that the original single-timeline estimate conflated two qualitatively different projects. The line counts are in plausible ranges for Lisp's density (~5-10× fewer lines than C++ for equivalent functionality), but the phases differ in their feedback regimes, constraints, and failure modes. The honest picture splits into two distinct phases. +The [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude time framework]] reveals that the original single-timeline estimate conflated two qualitatively different projects. The line counts are in plausible ranges for Lisp's density (~5-10× fewer lines than C++ for equivalent functionality), but the phases differ in their feedback regimes, constraints, and failure modes. The honest picture splits into two distinct phases. -*Old estimate:* 14,000 lines total, 3-6 months to replace the full computing stack. This was wrong because it treated all phases as linear — microcode has hardware latency (seconds per cycle), GUI has user-testing latency (days per iteration), and the browser alone is a years-scale project if done natively. The numbers do not add linearly across orders of magnitude. +*Old estimate:* 14,000 lines total, 3-6 months to replace the full computing stack. This was wrong because it treated all phases as linear — microcode has hardware latency (seconds per cycle), GUI has user-testing latency (days per iteration), and the browser alone is a years-scale project if done natively. The numbers do not add linearly across [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders of magnitude]]. *Corrected estimate:* Two-phase approach with a clear middleground destination. * Phase Zero — The MVP (Linux-hosted, ships real product) -Run on Linux, use C libraries through CFFI, deliver value without replacing the OS. This is the [[file:sufficiency-flip.org][sufficiency flip]] applied to the verification layer only, not the whole stack. +Run on Linux, use C libraries through CFFI, deliver value without replacing the OS. This is the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] applied to the verification layer only, not the whole stack. | Component | Lines | Method | Scale | |----------+-------+--------+-------| | Neurosymbolic core (ACL2 + Screamer + LLM bridge) | ~4,500 | Agent-generated Lisp, human-validated | Weeks — dense, well-bounded, proven approach | -| Terminal-based [[file:stoa.org][Stoa]] (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established | +| Terminal-based [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established | | Gate rule SDK + marketplace | ~1,500 | ACL2 gate packages | Weeks — pure symbolic, well-specified | | CFFI wrappers (system, GPU, crypto, storage) | ~2,000 | Thin bindings | Days — mechanical translation | -| [[file:verification-appliance.org][Verification appliance]] CLI + [[file:agora.org][Agora]] namespace | ~1,000 | API surface | Weeks | +| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] CLI + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] namespace | ~1,000 | API surface | Weeks | *Total MVP: ~11,000 lines. Timeline: 1-3 months. Human review: ~20 hours.* This ships. Users get verified code execution, gate rule packages, and a verified development environment. No new OS, no new browser, no Qt integration. Value proposition is proven with existing infrastructure. -*Revenue model starts here:* domain gate packages, verification appliance, compute marketplace. The MVP is a product, not a demo. +*Revenue model starts here:* [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]], verification appliance, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. The MVP is a product, not a demo. * Phase End State — Full Lisp Machine (cannibalize the stack) -Replace Linux, replace C libraries, own the framebuffer, own the browser. This is the full [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] vision. +Replace Linux, replace C libraries, own the framebuffer, own the browser. This is the full [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] vision. | Phase-out target | Replacement | Lines | Scale | Risk | |-----------------+------------+-------+-------+------| @@ -59,4 +59,4 @@ The range reflects uncertainty about the browser. If WebKit embed is sufficient The most dangerous order-of-magnitude error: treating the end state as an engineering sprint. Replacing the browser engine is a years-scale project that has defeated every attempt (Servo, PhantomJS, etc.). If that is the destination, plan accordingly — or accept WebKit embed as the terminal destination and focus verification on the OS/compositor layer where it provides real security value. -See [[file:investment-thesis.org][Investment thesis]] for the business case and [[file:cost-structure.org][Cost structure]] for the economics behind the verification-only-first approach. +See [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] for the business case and [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure]] for the economics behind the verification-only-first approach. diff --git a/ideas/triad-index.org b/ideas/triad-index.org index 59b9392..9a7d60d 100644 --- a/ideas/triad-index.org +++ b/ideas/triad-index.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f :END: #+title: Passepartout Triad — Knowledge Base @@ -6,37 +7,39 @@ The triad replaces every layer of the modern computing stack with Lisp-native, user-owned, ACL2-verified alternatives. Three components: -- [[file:triad-overview.org][Logos (Passepartout) — the cognitive agent]] -- [[file:stoa.org][Stoa (The Porch) — the environment]] -- [[file:agora.org][Agora (The Society) — the network]] +- [[id:a1fac32a-47de-5fbd-b67d-29152c851747][Logos (Passepartout) — the cognitive agent]] +- [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa (The Porch) — the environment]] +- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora (The Society) — the network]] Total addressable market: ~$960B/year across cloud, AI, OS, social media, payments, productivity, and compliance. -The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a compute marketplace. Network effects are positive sum — every instance feeds the regression suite and grows the marketplace. +The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. Network effects are positive sum — every instance feeds the regression suite and grows the marketplace. -[[file:lisp-machine-security.org][Lisp Machine security — unified memory threat model]] -[[file:common-logic-iso-24707.org][Common Logic (ISO 24707) — relevance to the triad]] -[[file:collective-regression-suite.org][Collective regression suite — how it compounds]] +[[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security — unified memory threat model]] +[[id:04c2f221-c54f-51e5-b40a-48822cd16d45][Common Logic (ISO 24707) — relevance to the triad]] +[[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][Collective regression suite — how it compounds]] Key analytical frames: -- [[file:investment-thesis.org][Investment thesis — the unified view]] -- [[file:lisp-economics.org][Why Lisp is economically viable now]] -- [[file:sufficiency-flip.org][The per-domain sufficiency flip]] -- [[file:time-estimates.org][Development velocity and timeline estimates]] -- [[file:cost-structure.org][Cost structure and zero marginal cost]] -- [[file:moats.org][Competitive moats analysis]] +- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis — the unified view]] +- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Why Lisp is economically viable now]] +- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][The per-domain sufficiency flip]] +- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development velocity and timeline estimates]] +- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]] +- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Competitive moats analysis]] Revenue paths (short to long term): -- [[file:verification-appliance.org][Verification appliance]][[file:domain-gate-packages.org][ Domain gate packages]][[file:evaluation-harness.org][ Evaluation harness]] -- [[file:agora-usernames.org][Agora premium usernames]][[file:pds-as-a-service.org][ PDS as a service]][[file:compute-marketplace.org][ Compute marketplace]] -- [[file:verification-monopoly.org][Verification monopoly — the big money]][[file:infrastructure-lock-in.org][ Infrastructure lock-in]] +- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]][[id:c34940cc-090e-57c4-8020-e78b1d32b96c][ Domain gate packages]][[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][ Evaluation harness]] +- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Agora premium usernames]][[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][ PDS as a service]][[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][ Compute marketplace]] +- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly — the big money]][[id:2f783eb4-638e-5afa-9b59-6224d086a712][ Infrastructure lock-in]] Strategy and IP: -- [[file:patent-strategy.org][Patent strategy]][[file:licensing.org][ Licensing (AGPL + commercial)]] -- [[file:ai-industry-impact.org][Impact on the AI/GPU industry]] -- [[file:upgrade-lifecycle.org][Upgrade and distribution lifecycle]] -- [[file:gate-rule-encoding.org][Gate rule encoding from codified domains]] -- [[file:biology-parallels.org][Biology as proof of the Lisp model]] -- [[file:comparison-with-symbolics.org][Comparison with Symbolics Genera]] +- [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][Patent strategy]][[id:67faf52f-9126-50a7-b87e-2bedc610dac7][ Licensing (AGPL + commercial)]] +- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][Impact on the AI/GPU industry]] +- [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade and distribution lifecycle]] +- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate rule encoding from codified domains]] +- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]] +- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]] + +The [[id:b25bf753-9799-41ab-82f5-1a1416db756b][Agora protocol overview]] and [[id:a3243dd0-3209-423b-98e1-51c3eada2658][advanced integration]] requirements define how the gate stack connects to Agora's network layer. The [[id:72570648-d943-42e5-a781-3b09791ac6ec][realistic assessment]] covers deployment timelines and adoption risks. *The lines that run the modern internet (tens of millions across Google, Meta, Amazon, Apple, Microsoft) are replaced by a single coherent architecture where one gate stack verifies everything and one prover proves everything consistent.* diff --git a/ideas/triad-overview.org b/ideas/triad-overview.org index 718a74a..69d76e9 100644 --- a/ideas/triad-overview.org +++ b/ideas/triad-overview.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: a1fac32a-47de-5fbd-b67d-29152c851747 :END: #+title: Triad Overview — Logos, Stoa, Agora @@ -6,10 +7,10 @@ The full triad is a self-bootstrapping replacement for the entire computing stack, not a single product. -**Logos (Passepartout)** — The mind. Cognitive agent combining a probabilistic LLM (10% of work) with a deterministic symbolic engine (80%) at near-zero marginal cost. Gate stack, fact store, ACL2 prover, Screamer constraint solver. +**Logos ([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]])** — The mind. Cognitive agent combining a probabilistic LLM (10% of work) with a deterministic symbolic engine (80%) at near-zero marginal cost. Gate stack, fact store, ACL2 prover, Screamer constraint solver. **Stoa (The Porch)** — The body. Editor (Lish), browser (Nyxt), shell (Lish), Org-mode filesystem, Qt/EQL5 UI. A single Lisp image where everything coexists. Roadmap: v2.0.0 (Qt/WebKit) → v6.0.0 (pure Lisp, hardware). -**Agora (The Society)** — The network. Self-sovereign DID identity, DIDComm encrypted messaging, [[file:pds-as-a-service.org][Personal Data Store]], Relay Network, [[file:compute-marketplace.org][compute marketplace]], liquid democracy. +**Agora (The Society)** — The network. Self-sovereign DID identity, DIDComm encrypted messaging, [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][Personal Data Store]], Relay Network, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], liquid democracy. -All three speak plists. All three operate in Lisp address space. All three are verified by the same ACL2 prover. The gate stack that verifies a shell command also verifies a DIDComm message. See [[file:investment-thesis.org][The investment thesis]] for the economic rationale and [[file:verification-appliance.org][Verification appliance]] for the hardware that enables this unified architecture. +All three speak plists. All three operate in Lisp address space. All three are verified by the same ACL2 prover. The gate stack that verifies a shell command also verifies a DIDComm message. See [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][The See the [[id:b25bf753-9799-41ab-82f5-1a1416db756b][Agora protocol overview]] for how the three triad components fit into Agora's network architecture. [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][The investment thesis]]]] for the economic rationale and [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] for the hardware that enables this unified architecture. diff --git a/ideas/triad-systemic-effects.org b/ideas/triad-systemic-effects.org index f79a802..06e612a 100644 --- a/ideas/triad-systemic-effects.org +++ b/ideas/triad-systemic-effects.org @@ -1,27 +1,28 @@ :PROPERTIES: +:ID: b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba :ID: triad-systemic-effects :CREATED: [2026-05-23 Sat] :END: #+title: Triad — Systemic Effects Over Time #+filetags: :passepartout:strategy:effects:geopolitics:society: -The [[file:triad-overview.org][triad (Logos + [[file:stoa.org][Stoa]] + [[file:agora.org][Agora]])]] is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible. +The triad (Logos + [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]) is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible. -Using the [[file:orders-of-magnitude-time.org][orders-of-magnitude framework]], the effects cascade across time scales. Each scale is qualitatively different, not just more of the same. +Using the [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude framework]], the effects cascade across time scales. Each scale is qualitatively different, not just more of the same. * Weeks to months — Phase Zero effects ** Scientific: verification becomes the publishing standard -Passepartout gate rules turn every computational result into a machine-checkable proof. Papers carry proof logs, not just dataset citations. The replication crisis in compute-heavy fields (ML, climate science, genomics) meets its match — if the code doesn't verify, the result doesn't publish. +[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] gate rules turn every computational result into a machine-checkable proof. Papers carry proof logs, not just dataset citations. The replication crisis in compute-heavy fields (ML, climate science, genomics) meets its match — if the code doesn't verify, the result doesn't publish. The effect compounds: proof repositories accumulate lemma libraries across fields, so each paper stands on verified shoulders, not on trust. ** Economic: the compliance industry's margins erode -The first enterprise that replaces a [[file:compliance/soc2.org][SOC2]] audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function). +The first enterprise that replaces a [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function). -[[file:domain-gate-packages.org][Gate rule packages]] sell to the same CISO who buys audit prep today. The difference: audit prep is a cost center; gate rules are an investment that compounds. +[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Gate rule packages]] sell to the same CISO who buys audit prep today. The difference: audit prep is a cost center; gate rules are an investment that compounds. ** Political: regulation becomes executable @@ -33,15 +34,15 @@ A regulation that says "access logs must be tamper-proof" is a negotiation. A ga ** Technological: AI safety becomes engineering, not policy -The verified API gateway ([[file:revenue-hub.org][revenue hub]]) proves that AI safety is a /software engineering problem/, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production. +The verified API gateway ([[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue hub]]) proves that AI safety is a /software engineering problem/, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production. This shifts the entire AI safety discourse. The question stops being "what should we ban?" and becomes "what gates should we verify?" Prompt injection, jailbreaks, data leakage, hallucination in critical paths — all become gate rule specifications, not white papers. ** Social: institutional trust gives way to computational trust -/I verified it/ replaces /I trust the auditor/. DIDs make platform-owned identity look like a historical anomaly. The [[file:pds-as-a-service.org][PDS model]] makes surveillance advertising technically impossible without the user's active consent gate. +/I verified it/ replaces /I trust the auditor/. DIDs make platform-owned identity look like a historical anomaly. The [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS model]] makes surveillance advertising technically impossible without the user's active consent gate. -The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The [[file:compliance/gdpr.org][GDPR]] model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible. +The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible. ** Cultural: verification earns cachet @@ -51,17 +52,17 @@ The /move fast and break things/ ethos ages overnight. In the C-suite, saying /w * Years — End State consolidates -** Economic: the verification monopoly +** Economic: [[id:827bc546-e887-5b7c-9b65-6392beaf0920][the verification monopoly]] -If every transaction on Agora, every plugin on Stoa, every gate rule on Logos passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[file:verification-monopoly.org][verification monopoly]]. +If every transaction on Agora, every plugin on Stoa, every gate rule on Logos passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]]. -The $960B TAM ([[file:triad-index.org][triad index]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money. +The $960B TAM ([[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][triad index]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money. -The switching cost to unverified infrastructure becomes infinite. No enterprise can justify / why would we go back to unverified code / once verification is in place. This is the [[file:infrastructure-lock-in.org][infrastructure lock-in]]. +The switching cost to unverified infrastructure becomes infinite. No enterprise can justify / why would we go back to unverified code / once verification is in place. This is the [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]]. ** Geopolitical: compute becomes a strategic asset -The [[file:compute-marketplace.org][compute marketplace]] becomes a geopolitical asset on the order of SWIFT or the dollar. Whoever provisions the largest verified compute capacity becomes the default infrastructure provider for any nation that wants verified digital sovereignty. +The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] becomes a geopolitical asset on the order of SWIFT or the dollar. Whoever provisions the largest verified compute capacity becomes the default infrastructure provider for any nation that wants verified digital sovereignty. The triad is inherently anti-surveillance-capitalist architecture. The PDS model does not do bulk surveillance. This makes it threatening to both: @@ -72,7 +73,7 @@ The nations that adopt verified infrastructure are in one economic sphere. The n ** Political: liquid democracy infrastructure at scale -Verifiable proxy voting, delegation chains, quadratic funding for [[file:agora-contracts.org][public goods (Agora contracts)]] — these are not experiments. They become infrastructure that nation-states adopt because the alternative (unverifiable voting, opaque governance) becomes indefensible. +Verifiable proxy voting, delegation chains, quadratic funding for [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][public goods (Agora contracts)]] — these are not experiments. They become infrastructure that nation-states adopt because the alternative (unverifiable voting, opaque governance) becomes indefensible. The effect is not that democracy becomes digital. The effect is that /trust in institutions/ becomes a measurable property rather than a polling number. Did the government follow its own rules? The proof log says yes or no. This is the political equivalent of the scientific reproducibility shift: institutions that can produce proof logs are trusted; institutions that cannot are not. @@ -98,20 +99,20 @@ The frontier shifts. The question is no longer /can we verify this/ but /what ne ** Economic: the old economy becomes a historical layer -Proprietary software [[file:licensing.org][licensing]], cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite. +Proprietary software [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite. The insurance industry, which prices based on risk, shifts to pricing based on proof coverage. Companies with full verification pay lower premiums. Companies without it cannot get insured. This is the completion of the feedback loop: verification is not just better engineering — it is a requirement for participation in the formal economy. * References -- [[file:triad-index.org][Triad index]] — the full architecture -- [[file:triad-overview.org][Triad overview]] — Logos, Stoa, Agora -- [[file:revenue-hub.org][Revenue streams overview]] — economic effects quantified -- [[file:agora-contracts.org][Agora contracts]] — governance, insurance, liquid democracy -- [[file:verification-monopoly.org][Verification monopoly]] — the big money -- [[file:infrastructure-lock-in.org][Infrastructure lock-in]] — switching costs -- [[file:orders-of-magnitude-time.org][Orders of magnitude — time]] — the framework that structures this analysis -- [[file:time-estimates.org][Development timeline]] — Phase Zero vs End State mapping -- [[file:compute-marketplace.org][Compute marketplace]] — the geopolitical asset -- [[file:lisp-machine-security.org][Lisp Machine security]] — why the architecture is anti-surveillance by design -- [[file:ai-industry-impact.org][AI industry impact]] — how verification changes the AI landscape +- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Triad index]] — the full architecture +- [[id:a1fac32a-47de-5fbd-b67d-29152c851747][Triad overview]] — Logos, Stoa, Agora +- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] — economic effects quantified +- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]] — governance, insurance, liquid democracy +- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] — the big money +- [[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure lock-in]] — switching costs +- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of magnitude — time]] — the framework that structures this analysis +- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State mapping +- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — the geopolitical asset +- [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security]] — why the architecture is anti-surveillance by design +- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry impact]] — how verification changes the AI landscape diff --git a/ideas/upgrade-lifecycle.org b/ideas/upgrade-lifecycle.org index 1d9a58e..8da9fd2 100644 --- a/ideas/upgrade-lifecycle.org +++ b/ideas/upgrade-lifecycle.org @@ -1,20 +1,21 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 29e4dbf3-cf19-589c-8b14-389e8a39d564 :END: #+title: Upgrade and Distribution Lifecycle #+filetags: :passepartout:economics:upgrade:distribution:ontology: -Once instances diverge in both code and knowledge, naive git pull breaks things. Passepartout's architecture already has the primitives for safe upgrades: +Once instances diverge in both code and knowledge, naive git pull breaks things. [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s architecture already has the primitives for safe upgrades: - **Ontology versioning:** every fact stores the ontology version at assertion. On upgrade, facts with old versions are flagged for re-verification. - **Degradation, not crash:** if an upgrade breaks the fact store, the system degrades to the pre-macro state (hash-table fallback, text-scan fallback). Still works — just proves less. - **Reversible upgrades (Phase 0 undo):** every upgrade produces a Merkle snapshot before applying. - **Delta distribution:** upgrades delivered as diffs against the current ontology version. Migration script runs automatically. -**The upgrade is verified by the upgraded system before committing.** The distributor ships the new gate vector; ACL2 reports which rules are compatible and which need review. The operator reviews only the incompatible subset. This verified upgrade process creates [[file:infrastructure-lock-in.org][infrastructure lock-in]] — switching costs are high when all knowledge is deeply coupled to the ontology version. +**The upgrade is verified by the upgraded system before committing.** The distributor ships the new gate vector; ACL2 reports which rules are compatible and which need review. The operator reviews only the incompatible subset. This verified upgrade process creates [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] — switching costs are high when all knowledge is deeply coupled to the ontology version. **Business model for upgrades:** - Code upgrades: free (AGPL) - Migration scripts: subscription. The verified migration path from current ontology version to new one. -- [[file:domain-gate-packages.org][Domain knowledge package upgrades]]: subscription. When [[file:compliance/hipaa.org][HIPAA]] updates, the healthcare package updates. -- [[file:verification-appliance.org][Verification appliance firmware]]: bundled with hardware. Signed and verified against hardware root of trust. +- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain knowledge package upgrades]]: subscription. When [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] updates, the healthcare package updates. +- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance firmware]]: bundled with hardware. Signed and verified against hardware root of trust. diff --git a/ideas/verification-appliance.org b/ideas/verification-appliance.org index 16b504a..b74846c 100644 --- a/ideas/verification-appliance.org +++ b/ideas/verification-appliance.org @@ -1,14 +1,17 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 84a537b4-4256-50c8-91f5-dd5b4538418f :END: #+title: Verification Appliance (Hardware) #+filetags: :passepartout:revenue:hardware:fpga:tenstorrent: -An FPGA or Tenstorrent card pre-loaded with a mature Passepartout image, [[file:domain-gate-packages.org][domain-specific gate rules]], and a hardware root of trust. No cloud dependency. +An FPGA or Tenstorrent card pre-loaded with a mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] image, [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain-specific gate rules]], and a hardware root of trust. No cloud dependency. -**Target:** regulated industries needing [[file:evaluation-harness.org][provable compliance]] that cannot accept cloud-based AI. +**Target:** regulated industries needing [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][provable compliance]] that cannot accept cloud-based AI. **Price:** $5K-$50K/unit. **Volume:** hundreds to low thousands in year one. -The [[file:self-driving-lisp-machine.org][Lisp Machine]] on Tenstorrent P150 (~72 RISC-V Tensix cores on a PCIe card) is the realistic first target: the microcode is RISC-V assembly (software), not FPGA bitstream (hardware). The system can propose, load, test, and roll back a new dispatch routine in seconds. An FPGA path would add synthesis time (minutes to hours per iteration). This hardware-first approach embodies [[file:lisp-economics.org][Lisp economics]] — verification hardware has near-zero marginal cost. The [[file:upgrade-lifecycle.org][Upgrade lifecycle]] for the appliance is managed via signed firmware updates with Merkle snapshots. +The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] on Tenstorrent P150 (~72 RISC-V Tensix cores on a PCIe card) is the realistic first target: the microcode is RISC-V assembly (software), not FPGA bitstream (hardware). The system can propose, load, test, and roll back a new dispatch routine in seconds. An FPGA path would add synthesis time (minutes to hours per iteration). This hardware-first approach embodies [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — verification hardware has near-zero marginal cost. The [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade lifecycle]] for the appliance is managed via signed firmware updates with Merkle snapshots. + +The [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Agora identity specification]] shows how the verification appliance issues provable identities for network participants. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] analysis covers how this new hardware tier — CPU-native Lisp microcode on RISC-V cores — reshapes the industry structure. Revenue estimate: 50 sales in year one = $250K-$2.5M. diff --git a/ideas/verification-monopoly.org b/ideas/verification-monopoly.org index 386ff29..b263749 100644 --- a/ideas/verification-monopoly.org +++ b/ideas/verification-monopoly.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: 827bc546-e887-5b7c-9b65-6392beaf0920 :END: #+title: The Verification Monopoly (UL for AI) @@ -6,10 +7,10 @@ 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. -Any organization claiming a "safe AI agent" needs Passepartout certification to prove it. This is Underwriters Laboratory for AI — a certification nobody can ignore. +Any organization claiming a "safe AI agent" needs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] certification to prove it. This is Underwriters Laboratory for AI — a certification nobody can ignore. -**Revenue:** licensing the certification mark to every AI vendor that ships an agent. **Margins:** near-100% once the suite exists. +**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 [[file:evaluation-harness.org][evaluation harness]] reaching critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[file:investment-thesis.org][investment thesis]] is built on the recognition that every deployed instance makes this more valuable. +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. -The unique structural advantage: every free instance of the triad feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[file:infrastructure-lock-in.org][infrastructure lock-in]] and powerful [[file:moats.org][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[file:ai-industry-impact.org][AI industry]], where safety certification becomes a prerequisite for market access. +The unique structural advantage: every free instance of the triad 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. diff --git a/ideas/verified-skill-marketplace.org b/ideas/verified-skill-marketplace.org index 48ce5c3..df2339e 100644 --- a/ideas/verified-skill-marketplace.org +++ b/ideas/verified-skill-marketplace.org @@ -1,4 +1,5 @@ :PROPERTIES: +:CREATED: [2026-05-24 Sun] :ID: d84679f1-c0c5-5be4-b19c-6573560640ee :END: #+title: Verified Skill Marketplace @@ -8,4 +9,4 @@ A marketplace where skills are verified (sandbox + ACL2 non-contradiction proof) Value is in the verification infrastructure, not the skills themselves. Anybody can write a skill; the marketplace provides the guarantee that the skill won't corrupt the fact store, won't violate gate rules, and won't introduce inconsistencies. -This is the App Store model applied to provable correctness. The gatekeeper role is replaced by the prover — and the prover is transparent, inspectable, and impartial. The marketplace relies on [[file:gate-rule-encoding.org][Gate rule encoding]] to define skill constraints and an [[file:evaluation-harness.org][Evaluation harness]] to verify them. +This is the App Store model applied to provable correctness. The gatekeeper role is replaced by the prover — and the prover is transparent, inspectable, and impartial. The marketplace relies on [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate rule encoding]] to define skill constraints and an [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness]] to verify them.