ideas: editorial sweep — atomization, interlinking, restructuring
- 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.
This commit is contained in:
Hermes
119
.org-ids.json
Normal file
119
.org-ids.json
Normal file
@@ -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"
|
||||||
|
}
|
||||||
25
_index.org
Normal file
25
_index.org
Normal file
@@ -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
|
||||||
@@ -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
|
|
||||||
9
ideas/_index.org
Normal file
9
ideas/_index.org
Normal file
@@ -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.
|
||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 64708e1f-00e9-4cb7-b44b-ea0b98e5296d
|
||||||
:ID: agora-contracts
|
:ID: agora-contracts
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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)
|
- 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)
|
- 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
|
* What Contracts Enable
|
||||||
|
|
||||||
@@ -28,7 +29,7 @@ How it works:
|
|||||||
- Every transaction runs through the symbolic engine and produces a proof log
|
- 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
|
- 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.
|
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.
|
Organizations running multiple triad instances need contracts that span instances: cross-instance policy, unified compliance, federated identity.
|
||||||
|
|
||||||
Use cases:
|
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
|
- Consortium: each member instance votes on protocol upgrades
|
||||||
- Supply chain: Instance A verifies shipment, Instance B verifies payment, both must agree
|
- 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
|
** 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.
|
- 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).
|
- 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.
|
- 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.
|
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
|
** 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.
|
Revenue: Commission per lease transaction, auction fees for contested names, premium for verified ownership.
|
||||||
|
|
||||||
** 8. Dispute Resolution
|
** 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).
|
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 |
|
| Smart contracts (general) | $20B/yr (Ethereum) | Transaction fees | End State | Installed base |
|
||||||
| Contract templates | New market | Per-template sale | Zero | Gate rule SDK |
|
| 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 |
|
| Liquid democracy | New market | Per-vote fee | End State | Installed base |
|
||||||
| Attestation | New market | Per-attestation | Zero | DID registry |
|
| Attestation | New market | Per-attestation | Zero | DID registry |
|
||||||
| Insurance marketplace | $1T+ (global insurance) | Premiums | End State | Installed base + capital |
|
| 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
|
- Attestation bridges them: a compute provider's track record is a verifiable contract history
|
||||||
- Insurance prices compute risk based on attestation
|
- 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
|
* References
|
||||||
|
|
||||||
- [[file:agora.org][Agora overview]]
|
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]]
|
||||||
- [[file:agora-usernames.org][Premium username registry]]
|
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]]
|
||||||
- [[file:pds-as-a-service.org][PDS as a service]]
|
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]]
|
||||||
- [[file:compute-marketplace.org][Compute marketplace]]
|
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||||
- [[file:revenue-hub.org][Revenue streams overview]]
|
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]]
|
||||||
- [[file:verification-monopoly.org][Verification monopoly]]
|
- [[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]]]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 8c7b9812-f8d6-4347-8915-ce8e520b7914
|
||||||
:ID: agora-entry-strategy
|
:ID: agora-entry-strategy
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -175,9 +176,9 @@ Organized communities are the entry point because they force the Agora to be the
|
|||||||
|
|
||||||
* References
|
* References
|
||||||
|
|
||||||
- [[file:agora.org][Agora overview]]
|
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]]
|
||||||
- Agora Protocol Overview — Platform Replacement Strategy
|
- Agora Protocol Overview — Platform Replacement Strategy
|
||||||
- Social Space — Collective Personas and Governance
|
- Social Space — Collective Personas and Governance
|
||||||
- Exchange and Contracts — SCAL, Escrow, Arbitration
|
- Exchange and Contracts — SCAL, Escrow, Arbitration
|
||||||
- [[file:alternative-growth-social-first.org][Social-first growth scenario]]
|
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
||||||
- [[file:competitive-landscape-agora.org][Full competitive landscape]]
|
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Full competitive landscape]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 2e390c1d-65f3-5fb3-b898-ac3fc4291ee7
|
:ID: 2e390c1d-65f3-5fb3-b898-ac3fc4291ee7
|
||||||
:END:
|
:END:
|
||||||
#+title: Premium Username Registry on Agora
|
#+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
|
- **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.
|
- **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.
|
||||||
|
|||||||
@@ -1,25 +1,26 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 1d074690-a279-59cb-b91d-e9a22ae104ad
|
:ID: 1d074690-a279-59cb-b91d-e9a22ae104ad
|
||||||
:END:
|
:END:
|
||||||
#+title: Agora — The Society (Decentralized Network)
|
#+title: Agora — The Society (Decentralized Network)
|
||||||
#+filetags: :passepartout:agora:network:dids:
|
#+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)
|
- **Self-sovereign identity** via HD key derivation (BIP-44)
|
||||||
- **Encrypted messaging** via DIDComm (agent-to-agent and agent-to-human)
|
- **Encrypted messaging** via DIDComm (agent-to-agent and agent-to-human)
|
||||||
- **Notes** as atomic, content-addressed, signed data units (mapped from Passepartout memory-objects)
|
- **Notes** as atomic, content-addressed, signed data units (mapped from Passepartout memory-objects)
|
||||||
- **Relay Network** for censorship-resistant message routing
|
- **Relay Network** for censorship-resistant message routing
|
||||||
- **Personal Data Store (PDS)** — the Merkle fact store exposed as a network-addressable service
|
- **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
|
- **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.
|
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:
|
Revenue paths from Agora:
|
||||||
- [[file:agora-usernames.org][Premium username registry]] — $10M/yr at scale
|
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]] — $10M/yr at scale
|
||||||
- [[file:pds-as-a-service.org][PDS as a service]] — $18M/yr at scale
|
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] — $18M/yr at scale
|
||||||
- [[file:compute-marketplace.org][Compute marketplace]] — venture-scale
|
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — venture-scale
|
||||||
- [[file:agora-contracts.org][Smart contracts + contract marketplace]] — the kill app
|
- [[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.
|
||||||
|
|||||||
41
ideas/agora/agora-requirements-00-readme.org
Normal file
41
ideas/agora/agora-requirements-00-readme.org
Normal file
@@ -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
|
||||||
@@ -5,7 +5,11 @@
|
|||||||
#+ID: agora-requirements-01-overview
|
#+ID: agora-requirements-01-overview
|
||||||
#+STARTUP: content
|
#+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.
|
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
|
* 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
|
** 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.
|
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
|
*** 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.
|
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.
|
- *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.
|
- *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
|
*** 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.
|
- Show "Your Twitter follows on Agora" for easy reconnecting.
|
||||||
- Surface collectives matching imported community memberships.
|
- 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")
|
*** Order 1: The First 1,000 (The "Founders")
|
||||||
- *Target:* Technical enthusiasts, privacy advocates, and niche professional guilds (e.g., decentralized AI devs).
|
- *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.
|
- *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.
|
- *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.
|
- *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.
|
- *Sovereign Control:* Users have absolute control over their own data in their PDS.
|
||||||
@@ -1,9 +1,13 @@
|
|||||||
#+title: Identity: The Genesis of Your Digital Being
|
#+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)
|
** 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
|
*** 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.
|
- 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 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 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.*)
|
- 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.
|
- 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.
|
- Each `persona'` index within this derivation path MUST represent a distinct DID (Decentralized Identifier), ensuring global uniqueness and unlinkability.
|
||||||
@@ -5,9 +5,13 @@
|
|||||||
#+ID: agora-requirements-03-infrastructure
|
#+ID: agora-requirements-03-infrastructure
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 3b43a9b8-31d1-4479-a35f-22273b74f0c7
|
||||||
|
:END:
|
||||||
* The Sovereign Infrastructure: Your Digital Foundation
|
* 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
|
** Personal Data Store (PDS): Your Digital Fortress
|
||||||
|
|
||||||
@@ -53,7 +57,7 @@ To send a private message:
|
|||||||
|
|
||||||
*** PDS Migration: Seamless Sovereignty Transfer
|
*** 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
|
**** Concept
|
||||||
|
|
||||||
@@ -610,10 +614,9 @@ For Collectives, NGOs, or LLCs managing sensitive operations, relying on "free"
|
|||||||
- *Fees:* Reasonable pricing?
|
- *Fees:* Reasonable pricing?
|
||||||
- *Users:* Number of active personas (network effect)
|
- *Users:* Number of active personas (network effect)
|
||||||
|
|
||||||
|
|
||||||
** Search & Indexing: The Firehose Indexers
|
** 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
|
*** Requirements
|
||||||
- Indexing Nodes MUST ingest public Content Objects from the Relay firehose.
|
- 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
|
** Related Documents
|
||||||
|
|
||||||
- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure and core encryption primitives.
|
- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure and core encryption primitives.
|
||||||
- [[file:agora-requirements-05-social.org][Social]] - Messaging models, social publishing, and the attention marketplace.
|
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Messaging models, social publishing, and the attention marketplace.
|
||||||
- [[file:agora-requirements-02-identity.org][Identity]] - Master Key (Psyche) and Persona governance.
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][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:90484f4a-5b70-4001-93d6-e610e54ed573][Exchange and Contracts]] - Economic primitives, fee structures, and the SCAL layer.
|
||||||
|
|
||||||
** Gaps
|
** Gaps
|
||||||
|
|
||||||
@@ -5,7 +5,11 @@
|
|||||||
#+ID: agora-requirements-04-the-primitive
|
#+ID: agora-requirements-04-the-primitive
|
||||||
#+STARTUP: content
|
#+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
|
** Concept: The Universal Data Primitive
|
||||||
|
|
||||||
@@ -158,7 +162,7 @@ Agora implements strict validation to ensure network integrity.
|
|||||||
},
|
},
|
||||||
"contract": {
|
"contract": {
|
||||||
"type": "object",
|
"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
|
"additionalProperties": true
|
||||||
},
|
},
|
||||||
"payload": {
|
"payload": {
|
||||||
@@ -414,10 +418,10 @@ Validation error: Notifications (`notify`) require the target DID to be present
|
|||||||
|
|
||||||
** Related Documents
|
** Related Documents
|
||||||
|
|
||||||
- [[file:agora-requirements-02-identity.org][Identity]] - Personas and contracts
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Personas and contracts
|
||||||
- [[file:agora-requirements-03-infrastructure.org][Infrastructure]] - PDS and Relay
|
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Infrastructure]] - PDS and Relay
|
||||||
- [[file:agora-requirements-05-social.org][Social]] - Relationships and communication
|
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Relationships and communication
|
||||||
- [[file:agora-requirements-06-exchange.org][Exchange]] - Economic layer
|
- Exchange (see Exchange and Contracts spec) - Economic layer
|
||||||
|
|
||||||
** Gaps
|
** Gaps
|
||||||
|
|
||||||
@@ -5,9 +5,13 @@
|
|||||||
#+ID: agora-requirements-05-social-space
|
#+ID: agora-requirements-05-social-space
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 0f949f6c-4cf1-49eb-b9a4-ebcac27ee548
|
||||||
|
:END:
|
||||||
* Social Space: Where Human Connection Becomes Sovereign
|
* 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
|
** 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 updates create new CIDs, preserving a verifiable history of the identity's presentation.
|
||||||
|
|
||||||
*** Profile as Static Site
|
*** 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)
|
** The Attention Marketplace (The Information Router)
|
||||||
|
|
||||||
@@ -176,6 +180,6 @@ Moderation is treated as "Competitive Labeling." Users subscribe to multiple Lab
|
|||||||
|
|
||||||
** Related Documents
|
** Related Documents
|
||||||
|
|
||||||
- [[file:agora-requirements-06-exchange-and-contracts.org][06: Exchange and Contracts]] - Economic layer and human connection formalization.
|
- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06: Exchange and Contracts]] - Economic layer and human connection formalization.
|
||||||
- [[file:agora-requirements-02-identity.org][02: Identity]] - Personas and Master Keys.
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]] - Personas and Master Keys.
|
||||||
- [[file:agora-requirements-03-infrastructure.org][03: Infrastructure]] - PDS and Relays.
|
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03: Infrastructure]] - PDS and Relays.
|
||||||
@@ -5,11 +5,15 @@
|
|||||||
#+ID: agora-requirements-06-exchange
|
#+ID: agora-requirements-06-exchange
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 90484f4a-5b70-4001-93d6-e610e54ed573
|
||||||
|
:END:
|
||||||
* Exchange
|
* Exchange
|
||||||
|
|
||||||
** Concept
|
** 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
|
** 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.
|
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
|
*** 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").
|
- *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`).
|
- *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.
|
- *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.
|
- *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
|
*** 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).
|
- *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.
|
- *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.
|
- *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 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.
|
- *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
|
** Advanced Exchange Features
|
||||||
|
|
||||||
@@ -297,9 +301,9 @@ Agora handles recurring payments natively without centralized payment processors
|
|||||||
|
|
||||||
** Related Documents
|
** Related Documents
|
||||||
|
|
||||||
- [[file:agora-requirements-04-the-primitive.org][The Primitive]] - Content Object structure
|
- [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][The Primitive]] - Content Object structure
|
||||||
- [[file:agora-requirements-05-social.org][Social]] - Connection types for economic relationships
|
- [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social]] - Connection types for economic relationships
|
||||||
- [[file:agora-requirements-02-identity.org][Identity]] - Contracts and attestations
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Identity]] - Contracts and attestations
|
||||||
|
|
||||||
** Gaps
|
** Gaps
|
||||||
|
|
||||||
@@ -5,13 +5,17 @@
|
|||||||
#+ID: agora-requirements-06-advanced-integration
|
#+ID: agora-requirements-06-advanced-integration
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: a3243dd0-3209-423b-98e1-51c3eada2658
|
||||||
|
:END:
|
||||||
* Advanced Integration
|
* Advanced Integration
|
||||||
|
|
||||||
** AI Integration
|
** AI Integration
|
||||||
|
|
||||||
*** Overview
|
*** 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)
|
*** 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.
|
- AI providers set their own pricing; market competition drives efficiency.
|
||||||
|
|
||||||
**** Execution Tiers & Compute Swarms
|
**** 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 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.
|
- *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.
|
- 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 run locally on the client or as trusted services in the user's PDS.
|
||||||
- Algorithms MUST be content-addressed (CID) for integrity verification.
|
- 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
|
**** Curation Algorithms
|
||||||
- *Feed Ranking:* Sort posts by relevance, recency, engagement, or custom criteria.
|
- *Feed Ranking:* Sort posts by relevance, recency, engagement, or custom criteria.
|
||||||
@@ -5,6 +5,10 @@
|
|||||||
#+ID: agora-requirements-07-library
|
#+ID: agora-requirements-07-library
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: df02cddc-944a-4bcd-8ef5-f080870d5f49
|
||||||
|
:END:
|
||||||
* Library
|
* Library
|
||||||
|
|
||||||
** Concept
|
** Concept
|
||||||
@@ -39,7 +43,7 @@ The Library consists of three core components:
|
|||||||
- Full-text search across documents, subtitles, metadata
|
- Full-text search across documents, subtitles, metadata
|
||||||
- Tag-based organization (genre, year, creator, etc.)
|
- Tag-based organization (genre, year, creator, etc.)
|
||||||
- Content deduplication via CID comparison
|
- 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
|
*** Library Managers
|
||||||
|
|
||||||
@@ -5,11 +5,15 @@
|
|||||||
#+ID: agora-requirements-08-implementation
|
#+ID: agora-requirements-08-implementation
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d
|
||||||
|
:END:
|
||||||
* Implementation
|
* Implementation
|
||||||
|
|
||||||
** Client Architecture
|
** 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
|
*** Requirements
|
||||||
|
|
||||||
@@ -66,7 +70,7 @@ The client MUST be capable of handling asynchronous events pushed from the Gover
|
|||||||
|
|
||||||
*** Protocol-First Design
|
*** 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
|
*** Core Protocol Versioning
|
||||||
|
|
||||||
@@ -141,7 +145,7 @@ Agora's decentralized and sovereign nature requires a multi-layered testing stra
|
|||||||
|
|
||||||
*** Agora-to-Web Gateways
|
*** 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 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.
|
- Clients MAY embed Gateway content in web views for hybrid experiences.
|
||||||
|
|
||||||
@@ -4,11 +4,15 @@
|
|||||||
#+ID: agora-requirements-10-governance
|
#+ID: agora-requirements-10-governance
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 68ffa49f-f0d8-42cf-8b69-ae69de8bb815
|
||||||
|
:END:
|
||||||
* Governance and Physical Assets
|
* Governance and Physical Assets
|
||||||
|
|
||||||
** Overview
|
** 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)
|
** Governance Executable Module (GEM)
|
||||||
|
|
||||||
@@ -2,9 +2,13 @@
|
|||||||
#+AUTHOR: Project Agora
|
#+AUTHOR: Project Agora
|
||||||
#+DATE: 2026-03-26
|
#+DATE: 2026-03-26
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 2cace571-76bb-4c34-a5f4-68bc20b2e884
|
||||||
|
:END:
|
||||||
* The Sovereign User Journey
|
* 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)
|
** 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.
|
- *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
|
* Related Documents
|
||||||
- [[file:agora-requirements-02-identity.org][02 Identity (Master Keys & Personas)]]
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02 Identity (Master Keys & Personas)]]
|
||||||
- [[file:agora-requirements-03-infrastructure.org][03 Infrastructure (PDS & WebRTC Seeding)]]
|
- [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][03 Infrastructure (PDS & WebRTC Seeding)]]
|
||||||
- [[file:agora-requirements-06-exchange-and-contracts.org][06 Exchange & Contracts (HODL Escrows & Arbitration)]]
|
- [[id:90484f4a-5b70-4001-93d6-e610e54ed573][06 Exchange & Contracts (HODL Escrows & Arbitration)]]
|
||||||
@@ -5,16 +5,20 @@
|
|||||||
#+ID: agora-requirements-10-assessment
|
#+ID: agora-requirements-10-assessment
|
||||||
#+STARTUP: content
|
#+STARTUP: content
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 72570648-d943-42e5-a781-3b09791ac6ec
|
||||||
|
:END:
|
||||||
* Realistic Assessment: Practicality, Technology, and Performance
|
* 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
|
** 1. Practicality: The Sovereignty vs. UX Trade-off
|
||||||
|
|
||||||
Agora's practicality hinges on whether users can manage its cryptographic complexity without constant friction.
|
Agora's practicality hinges on whether users can manage its cryptographic complexity without constant friction.
|
||||||
|
|
||||||
*** Strengths
|
*** 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.
|
- *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
|
*** Challenges
|
||||||
@@ -28,7 +32,7 @@ The technical stack is grounded in industry-standard primitives used in Bitcoin
|
|||||||
*** Technological Pillars
|
*** Technological Pillars
|
||||||
- *Identity:* Leveraging BIP-44 and Ed25519 provides a battle-tested foundation for unlinkable personas.
|
- *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.
|
- *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
|
*** 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.
|
- *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
|
** Related Documents
|
||||||
|
|
||||||
- [[file:agora-requirements-01-overview.org][01: Overview]]
|
- [[id:b25bf753-9799-41ab-82f5-1a1416db756b][01: Overview]]
|
||||||
- [[file:agora-requirements-02-identity.org][02: Identity]]
|
- [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][02: Identity]]
|
||||||
- [[file:agora-requirements-09-implementation.org][09: Implementation]]
|
- [[id:8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d][09: Implementation]]
|
||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542
|
:ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542
|
||||||
:END:
|
:END:
|
||||||
#+title: Impact on the AI and GPU Industry
|
#+title: Impact on the AI and GPU Industry
|
||||||
@@ -6,10 +7,10 @@
|
|||||||
|
|
||||||
If a symbolic-bootstrapping architecture becomes popular, the industry structure shifts fundamentally:
|
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."
|
**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.
|
**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.
|
||||||
|
|||||||
@@ -1,15 +1,16 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 57f9538a-6270-4302-8d07-d742168419eb
|
||||||
:ID: alternative-growth-social-first
|
:ID: alternative-growth-social-first
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Alternative Growth — Social-First Scenario
|
#+title: Alternative Growth — Social-First Scenario
|
||||||
#+filetags: :passepartout:growth:strategy:alternative:
|
#+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
|
* 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.
|
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
|
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
|
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
|
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.
|
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/.
|
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:
|
Revenue:
|
||||||
| Stream | Year 1 target | Mature |
|
| 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).
|
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.
|
- 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.
|
- 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.
|
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.
|
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
|
* References
|
||||||
|
|
||||||
- [[file:growth-strategy.org][Primary growth strategy — institution-first]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Primary growth strategy — institution-first]]
|
||||||
- [[file:revenue-hub.org][Revenue streams by component]]
|
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams by component]]
|
||||||
- [[file:agora-contracts.org][Agora contract platform details]]
|
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform details]]
|
||||||
- [[file:effects-growth-flywheel.org][Effects and growth as interleaved curves]]
|
- [[id:528a0f6c-6fd6-41ed-9d59-237958bdaef2][Effects and growth as interleaved curves]]
|
||||||
- [[file:time-estimates.org][Development timeline — Phase Zero and End State]]
|
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline — Phase Zero and End State]]
|
||||||
|
|
||||||
#+begin_quote
|
#+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
|
#+end_quote
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 0a4e0b8f-25e0-4b78-9633-fc37d03cefe9
|
||||||
:ID: asset-protection-structures
|
:ID: asset-protection-structures
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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:
|
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
|
* 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)
|
- 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
|
- 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 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.
|
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.
|
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
|
** Structure D: Delaware C-Corp + Delaware LLC Series + Offshore
|
||||||
|
|
||||||
- Delaware C-Corp as parent
|
- 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
|
- IP held in an offshore company, licensed to each series LLC
|
||||||
- Series LLCs protect assets within each series from liabilities arising in other series
|
- 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 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**
|
** 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.
|
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:
|
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.
|
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]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
|
||||||
- [[file:competitive-landscape-agora.org][Agora competitive landscape]]
|
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]]
|
||||||
- [[file:agora-entry-strategy.org][Entry strategy — organized communities]]
|
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
||||||
- [[file:outbound-sales-compliance.org][Outbound sales compliance framework]]
|
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 2afd9a3c-e96a-54c7-ac77-a05a28065b4b
|
:ID: 2afd9a3c-e96a-54c7-ac77-a05a28065b4b
|
||||||
:END:
|
:END:
|
||||||
#+title: Biology as Proof of the Lisp Model
|
#+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
|
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
|
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.
|
||||||
|
|||||||
@@ -1,18 +1,19 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: a5d59d12-b23e-58d6-a81b-9b8b06556949
|
:ID: a5d59d12-b23e-58d6-a81b-9b8b06556949
|
||||||
:END:
|
:END:
|
||||||
#+title: Collective Regression Suite — Specification
|
#+title: Collective Regression Suite — Specification
|
||||||
#+filetags: :passepartout:evaluation:regression:suite:collective:
|
#+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**
|
**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**
|
**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**
|
**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.
|
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 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)
|
- 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**
|
**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.
|
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.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 04c2f221-c54f-51e5-b40a-48822cd16d45
|
:ID: 04c2f221-c54f-51e5-b40a-48822cd16d45
|
||||||
:END:
|
:END:
|
||||||
#+title: Common Logic (ISO 24707) — Relevance to Passepartout
|
#+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.
|
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.
|
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.
|
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
|
4. A bridge to RDF/OWL data sources
|
||||||
5. A cautionary example for the CIC prover design (careful about higher-order scope)
|
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.
|
||||||
|
|||||||
@@ -1,10 +1,11 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 00ab3a4d-e3de-5605-a67d-12935bb36ab5
|
:ID: 00ab3a4d-e3de-5605-a67d-12935bb36ab5
|
||||||
:END:
|
:END:
|
||||||
#+title: Comparison with Symbolics Genera
|
#+title: Comparison with Symbolics Genera
|
||||||
#+filetags: :passepartout:history:symbolics:comparison:
|
#+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) |
|
| Lines | ~1,000,000 | ~21,000 (self-driving target) |
|
||||||
| Developer-years | ~10 years, large team | ~1 year, 1-3 devs |
|
| Developer-years | ~10 years, large team | ~1 year, 1-3 devs |
|
||||||
@@ -13,4 +14,4 @@
|
|||||||
| Market | $50K-$100K/seat | $5K-$50K/appliance |
|
| Market | $50K-$100K/seat | $5K-$50K/appliance |
|
||||||
| Scope | Full OS + environment | Cognitive agent + hardware acceleration |
|
| 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.
|
||||||
|
|||||||
@@ -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/<slug>/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)
|
|
||||||
128
ideas/competitive-analysis.org
Normal file
128
ideas/competitive-analysis.org
Normal file
@@ -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)
|
||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f
|
||||||
:ID: competitive-landscape-agora
|
:ID: competitive-landscape-agora
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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 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.
|
- *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.
|
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
|
* References
|
||||||
|
|
||||||
- [[file:agora.org][Agora overview]] (brain docs)
|
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]] (brain docs)
|
||||||
- [[file:agora-contracts.org][Agora contract platform]]
|
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform]]
|
||||||
- [[file:alternative-growth-social-first.org][Social-first growth scenario]]
|
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
||||||
- Agora Protocol Overview (spec repo)
|
- Agora Protocol Overview (spec repo)
|
||||||
- Social Space specification
|
- Social Space specification
|
||||||
- Exchange and Contracts specification
|
- Exchange and Contracts specification
|
||||||
|
|||||||
22
ideas/competitors/aider.org
Normal file
22
ideas/competitors/aider.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/claude-code.org
Normal file
22
ideas/competitors/claude-code.org
Normal file
@@ -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/<slug>/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.
|
||||||
22
ideas/competitors/codex-cli.org
Normal file
22
ideas/competitors/codex-cli.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/continue.org
Normal file
22
ideas/competitors/continue.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/gemini-cli.org
Normal file
22
ideas/competitors/gemini-cli.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/hermes-agent.org
Normal file
22
ideas/competitors/hermes-agent.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/openclaw.org
Normal file
22
ideas/competitors/openclaw.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/opencode.org
Normal file
22
ideas/competitors/opencode.org
Normal file
@@ -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.
|
||||||
22
ideas/competitors/thoth.org
Normal file
22
ideas/competitors/thoth.org
Normal file
@@ -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.
|
||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 36e5b948-e07b-477f-9036-4dfe88254347
|
||||||
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
|
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:UPDATED: [2026-05-23 Sat]
|
:UPDATED: [2026-05-23 Sat]
|
||||||
@@ -6,43 +7,43 @@
|
|||||||
#+title: Compliance Framework Mapping — Global Regulated Industries
|
#+title: Compliance Framework Mapping — Global Regulated Industries
|
||||||
#+filetags: :passepartout:triad:compliance:global:index:
|
#+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 [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] for the hub with per-framework links.
|
||||||
See [[file:compliance/first-mover-window.org][First-mover window analysis]] for timing.
|
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][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:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for pricing and TAM.
|
||||||
|
|
||||||
Each framework is its own file in [[file:compliance/][compliance/]]:
|
Each framework is its own file in [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]:
|
||||||
- [[file:compliance/hipaa.org][HIPAA]]
|
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]]
|
||||||
- [[file:compliance/soc2.org][SOC 2]]
|
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]]
|
||||||
- [[file:compliance/gdpr.org][GDPR]]
|
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
||||||
- [[file:compliance/fedramp.org][[[file:compliance/fedramp.org][FedRAMP]]]]
|
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]
|
||||||
- [[file:compliance/sox.org][SOX]]
|
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]]
|
||||||
- [[file:compliance/glba.org][GLBA]]
|
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]]
|
||||||
- [[file:compliance/ny-dfs-500.org][[[file:compliance/ny-dfs-500.org][NY DFS 500]]]]
|
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]]
|
||||||
- [[file:compliance/ccpa-cpra.org][CCPA/CPRA]]
|
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]]
|
||||||
- [[file:compliance/quebec-law-25.org][[[file:compliance/quebec-law-25.org][Quebec Law 25]]]]
|
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]
|
||||||
- [[file:compliance/uk-gdpr.org][[[file:compliance/uk-gdpr.org][UK [[file:compliance/gdpr.org][GDPR]]]]]]
|
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
||||||
- [[file:compliance/nis2.org][NIS2]]
|
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]]
|
||||||
- [[file:compliance/eu-ai-act.org][[[file:compliance/eu-ai-act.org][EU AI Act]]]]
|
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]]
|
||||||
- [[file:compliance/dora.org][DORA]]
|
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]]
|
||||||
- [[file:compliance/eidas2.org][eIDAS 2.0]]
|
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]]
|
||||||
- [[file:compliance/cra.org][CRA]]
|
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]]
|
||||||
- [[file:compliance/appi.org][APPI]]
|
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]]
|
||||||
- [[file:compliance/ismap.org][ISMAP]]
|
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]]
|
||||||
- [[file:compliance/pipa.org][PIPA]]
|
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]]
|
||||||
- [[file:compliance/privacy-act-aus.org][Privacy Act Australia]]
|
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act Australia]]
|
||||||
- [[file:compliance/apra-cps-234.org][[[file:compliance/apra-cps-234.org][APRA CPS 234]]]]
|
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]]
|
||||||
- [[file:compliance/irap.org][IRAP]]
|
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]]
|
||||||
- [[file:compliance/dpdp-act.org][[[file:compliance/dpdp-act.org][DPDP Act]] India]]
|
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]]
|
||||||
- [[file:compliance/lgpd.org][LGPD Brazil]]
|
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD Brazil]]
|
||||||
- [[file:compliance/lfp-dppp.org][LFPDPPP Mexico]]
|
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP Mexico]]
|
||||||
- [[file:compliance/iso-27001.org][[[file:compliance/iso-27001.org][ISO 27001]]]]
|
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]]
|
||||||
- [[file:compliance/iso-27701.org][[[file:compliance/iso-27701.org][ISO 27701]]]]
|
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]]
|
||||||
- [[file:compliance/basel-iii.org][[[file:compliance/basel-iii.org][Basel III]]]]
|
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]]
|
||||||
- [[file:compliance/fatf.org][FATF AML/CFT]]
|
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF AML/CFT]]
|
||||||
- [[file:compliance/ifrs.org][IFRS]]
|
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]]
|
||||||
- [[file:compliance/oecd.org][OECD Privacy/AI]]
|
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Privacy/AI]]
|
||||||
- [[file:compliance/world-bank-esf.org][[[file:compliance/world-bank-esf.org][World Bank ESF]]]]
|
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]]
|
||||||
- [[file:compliance/ifc-ps.org][IFC PS]]
|
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]]
|
||||||
- [[file:compliance/un-cefact.org][UN/CEFACT]]
|
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]]
|
||||||
|
|||||||
7
ideas/compliance/_index.org
Normal file
7
ideas/compliance/_index.org
Normal file
@@ -0,0 +1,7 @@
|
|||||||
|
#+title: Compliance
|
||||||
|
#+filetags: :compliance:index:
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 1c4c91ec-c465-44ab-bd91-4c3b45909ddb
|
||||||
|
:END:
|
||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: b852ec69-0fc2-435c-ae1e-6b83e49b3ca3
|
||||||
:ID: auto-appi
|
:ID: auto-appi
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -23,4 +24,6 @@ Japanese residents.
|
|||||||
Why it matters: APPI's cross-border transfer restrictions require fine-grained
|
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
|
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
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 904f5f12-ec9a-4cbf-854a-0b9b1e11a521
|
||||||
:ID: auto-apra-cps-234
|
:ID: auto-apra-cps-234
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -21,7 +22,7 @@ license cancellation for non-compliance. Personal liability for board and
|
|||||||
senior management.
|
senior management.
|
||||||
|
|
||||||
Why it matters: CPS 234's control testing requirement creates demand for
|
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
|
provide. First-mover advantage: CPS 234 is mature (2019) but enforcement is
|
||||||
escalating. No vendor provides a deterministic control-testing pipeline.
|
escalating. No vendor provides a deterministic control-testing pipeline.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 4eef0993-6671-41cf-ba20-d1443a3ec49d
|
||||||
:ID: auto-basel-iii
|
:ID: auto-basel-iii
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
and produce auditable proof that capital calculations follow the correct
|
||||||
methodology. First-mover advantage: Basel compliance is done via spreadsheets
|
methodology. First-mover advantage: Basel compliance is done via spreadsheets
|
||||||
and specialized risk platforms. No platform uses formal verification for
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 87996d87-100c-4bf6-8546-a860b9d7c25b
|
||||||
:ID: auto-ccpa-cpra
|
:ID: auto-ccpa-cpra
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -6,7 +7,7 @@
|
|||||||
#+filetags: :passepartout:compliance:framework:ccpa:
|
#+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
|
CPRA (effective 2023) amended and strengthened CCPA. Key rights: right to
|
||||||
know, delete, opt out of sale/sharing, correct inaccurate data, limit use
|
know, delete, opt out of sale/sharing, correct inaccurate data, limit use
|
||||||
of sensitive PI. Private right of action for data breaches.
|
of sensitive PI. Private right of action for data breaches.
|
||||||
|
|||||||
@@ -6,63 +6,63 @@
|
|||||||
#+title: Compliance Framework Index — Global Regulated Industries
|
#+title: Compliance Framework Index — Global Regulated Industries
|
||||||
#+filetags: :passepartout:triad:compliance:global:index:hub:
|
#+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.
|
selling into regulated industries. These industries buy compliance, not software.
|
||||||
Each framework below maps to a gate package the triad can sell — ACL2-verified
|
Each framework below maps to a gate package the triad can sell — ACL2-verified
|
||||||
gate rules that produce deterministic audit trails.
|
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
|
* US Frameworks
|
||||||
|
|
||||||
- [[file:hipaa.org][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs)
|
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs)
|
||||||
- [[file:soc2.org][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs)
|
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs)
|
||||||
- [[file:fedramp.org][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers)
|
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers)
|
||||||
- [[file:sox.org][SOX]] — Financial controls ($50K/yr, 10K orgs)
|
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] — Financial controls ($50K/yr, 10K orgs)
|
||||||
- [[file:glba.org][GLBA]] — Financial privacy ($40K/yr, 20K orgs)
|
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] — Financial privacy ($40K/yr, 20K orgs)
|
||||||
- [[file:ny-dfs-500.org][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs)
|
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs)
|
||||||
- [[file:ccpa-cpra.org][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs)
|
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs)
|
||||||
|
|
||||||
* Canada
|
* 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
|
* UK and EU
|
||||||
|
|
||||||
- [[file:gdpr.org][GDPR]] — EU privacy ($50K/yr, 500K+ orgs)
|
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] — EU privacy ($50K/yr, 500K+ orgs)
|
||||||
- [[file:uk-gdpr.org][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs)
|
- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs)
|
||||||
- [[file:nis2.org][NIS2]] — Network security ($50K/yr, 160K orgs)
|
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] — Network security ($50K/yr, 160K orgs)
|
||||||
- [[file:eu-ai-act.org][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs)
|
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs)
|
||||||
- [[file:dora.org][DORA]] — Financial resilience ($50K/yr, 22K+ orgs)
|
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] — Financial resilience ($50K/yr, 22K+ orgs)
|
||||||
- [[file:eidas2.org][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs)
|
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs)
|
||||||
- [[file:cra.org][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs)
|
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs)
|
||||||
|
|
||||||
* Asia-Pacific
|
* Asia-Pacific
|
||||||
|
|
||||||
- [[file:appi.org][APPI]] — Japan privacy ($40K/yr, 100K+ orgs)
|
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] — Japan privacy ($40K/yr, 100K+ orgs)
|
||||||
- [[file:ismap.org][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers)
|
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers)
|
||||||
- [[file:pipa.org][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs)
|
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs)
|
||||||
- [[file:privacy-act-aus.org][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs)
|
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs)
|
||||||
- [[file:apra-cps-234.org][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs)
|
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs)
|
||||||
- [[file:irap.org][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers)
|
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers)
|
||||||
- [[file:dpdp-act.org][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs)
|
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs)
|
||||||
|
|
||||||
* Latin America
|
* Latin America
|
||||||
|
|
||||||
- [[file:lgpd.org][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs)
|
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs)
|
||||||
- [[file:lfp-dppp.org][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs)
|
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs)
|
||||||
|
|
||||||
* International
|
* International
|
||||||
|
|
||||||
- [[file:iso-27001.org][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs)
|
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs)
|
||||||
- [[file:iso-27701.org][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs)
|
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs)
|
||||||
- [[file:basel-iii.org][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs)
|
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs)
|
||||||
- [[file:fatf.org][FATF]] — AML/CFT ($50K/yr, 50K+ orgs)
|
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] — AML/CFT ($50K/yr, 50K+ orgs)
|
||||||
- [[file:ifrs.org][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs)
|
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs)
|
||||||
- [[file:oecd.org][OECD Guidelines]] — Privacy/AI principles (indirect)
|
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Guidelines]] — Privacy/AI principles (indirect)
|
||||||
- [[file:world-bank-esf.org][World Bank ESF]] — Development finance ($50K/yr)
|
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] — Development finance ($50K/yr)
|
||||||
- [[file:ifc-ps.org][IFC PS]] — Project finance ($50K/yr)
|
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] — Project finance ($50K/yr)
|
||||||
- [[file:un-cefact.org][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs)
|
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs)
|
||||||
|
|
||||||
* Strategic View
|
* 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) |
|
| Latin America | 2 | ~$7B | LGPD (largest LATAM market) |
|
||||||
| International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) |
|
| 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]]
|
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] is enforced through
|
||||||
See also: [[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/domain-gate-packages.org][[[file:../domain-gate-packages.org][Domain gate packages]]]],
|
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] running on a
|
||||||
[[file:../../ideas/compute-marketplace.org][[[file:../compute-marketplace.org][Compute marketplace]]]], [[file:../../ideas/infrastructure-lock-in.org][Infrastructure lock-in]]
|
[[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.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: ce81fefc-b7a8-4be5-912f-55fd30970b6e
|
||||||
:ID: auto-cra
|
:ID: auto-cra
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -23,8 +24,8 @@ Penalties: Up to 15M EUR or 2.5% of global turnover for non-compliance with
|
|||||||
reporting obligations.
|
reporting obligations.
|
||||||
|
|
||||||
Why it matters: CRA's CE marking requirement creates a certification pipeline
|
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
|
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 [[file:../evaluation-harness.org][evaluation harness]]), it becomes the
|
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:
|
compliance infrastructure for any product built on it. First-mover advantage:
|
||||||
Class II products require notified body assessment — the bottleneck is notified
|
Class II products require notified body assessment — the bottleneck is notified
|
||||||
body capacity. The gate stack's automated evidence pipeline bypasses the
|
body capacity. The gate stack's automated evidence pipeline bypasses the
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 717ef2df-2a80-4362-b23a-5e7e12554251
|
||||||
:ID: auto-dora
|
:ID: auto-dora
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
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.
|
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).
|
advantage is extremely time-sensitive: DORA is already in effect (January 2025).
|
||||||
Financial institutions are scrambling for compliance tooling. A DORA gate package
|
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.
|
at $50K/yr with zero incremental cost per additional user is an immediate sale.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: fed19a24-ad81-4837-a12b-dafbd3ec110a
|
||||||
:ID: auto-dpdp-act
|
:ID: auto-dpdp-act
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
A DPDP gate package at $30K/yr (discounted for India market) captures a market
|
||||||
of hundreds of thousands of businesses with no incumbent vendor.
|
of hundreds of thousands of businesses with no incumbent vendor.
|
||||||
|
|
||||||
|
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: b8cf51e8-5f39-49ad-9547-a792a2e446aa
|
||||||
:ID: auto-eidas2
|
:ID: auto-eidas2
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
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
|
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
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 06fcdb02-2643-4f9d-ab41-e711a99cc390
|
||||||
:ID: auto-eu-ai-act
|
:ID: auto-eu-ai-act
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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)
|
if the AI system output is used in the EU. Scope covers GPAI (general-purpose AI)
|
||||||
with additional obligations for systemic-risk GPAI.
|
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
|
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
|
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
|
force: an ACL2-verified gate stack is the most defensible approach to AI Act
|
||||||
compliance. First-mover advantage: the regulation takes effect August 2026.
|
compliance. First-mover advantage: the regulation takes effect August 2026.
|
||||||
No certification body or tool vendor has an ACL2-based compliance pipeline.
|
No certification body or tool vendor has an ACL2-based compliance pipeline.
|
||||||
First to market captures the standard-setting role.
|
First to market captures the standard-setting role.
|
||||||
|
|
||||||
** DORA (Digital Operational Resilience Act)
|
** [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA (Digital Operational Resilience Act)]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 03ebdb80-a9af-4e76-a443-8556424996ed
|
||||||
:ID: auto-fatf
|
:ID: auto-fatf
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
Why it matters: FATF's CDD requirements are the most widespread and
|
||||||
rule-complex compliance obligation globally. The gate stack can encode
|
rule-complex compliance obligation globally. The gate stack can encode
|
||||||
tiered CDD rules, prove that every customer onboarding followed the correct
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: e6993701-3c67-49bf-82f3-06907572cbf3
|
||||||
:ID: auto-fedramp
|
:ID: auto-fedramp
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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.
|
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).
|
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.
|
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
|
authorization can sell to every federal agency. The gate stack's deterministic
|
||||||
audit trail maps directly to FedRAMP's continuous monitoring requirement —
|
audit trail maps directly to FedRAMP's continuous monitoring requirement —
|
||||||
producing verifiable evidence of control effectiveness on every access, not
|
producing verifiable evidence of control effectiveness on every access, not
|
||||||
just during the annual assessment. This is what justifies the
|
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
|
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
|
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
|
provider for five years cannot switch without re-running the entire authorization
|
||||||
process with a new provider.
|
process with a new provider.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 558154ea-e63a-4c45-998c-26ce8588585b
|
||||||
:ID: auto-first-mover-window
|
:ID: auto-first-mover-window
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -12,12 +13,16 @@ dominance before incumbents respond or the market settles on a standard approach
|
|||||||
|
|
||||||
| Window | Frameworks | Rationale |
|
| 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. |
|
| **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)** | [[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. |
|
| **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)** | [[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. |
|
| **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)** | [[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. |
|
| **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]],
|
These windows define which frameworks are worth building a gate package for
|
||||||
[[file:../../ideas/verification-appliance.org][[[file:../verification-appliance.org][Verification appliance]]]], [[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]]
|
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.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 513d5996-4ac7-4567-a992-18fc01599104
|
||||||
:ID: auto-gdpr
|
:ID: auto-gdpr
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
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
|
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
|
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
|
maintain DPAs with all clients. Proof logs themselves may constitute personal
|
||||||
data if they reference natural persons (names in access rules, etc.), creating
|
data if they reference natural persons (names in access rules, etc.), creating
|
||||||
a demand for privacy-preserving proof techniques. This is why the
|
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
|
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]].
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 4a2bc62b-3f21-4212-9cd9-f9add8fc0be1
|
||||||
:ID: auto-glba
|
:ID: auto-glba
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -19,5 +20,5 @@ and directors personally liable.
|
|||||||
Why it matters: The Safeguards Rule maps directly to gate stack access controls.
|
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.
|
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
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f
|
||||||
:ID: auto-hipaa
|
:ID: auto-hipaa
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -34,11 +35,11 @@ imprisonment). State AGs can also bring civil actions.
|
|||||||
** Why it matters for the triad
|
** Why it matters for the triad
|
||||||
|
|
||||||
HIPAA is the largest single compliance market in US healthcare — every hospital,
|
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
|
($50K/yr) encodes the Privacy Rule and Security Rule as ACL2-verifiable gate
|
||||||
constraints. Every PHI access attempt passes through the gate stack, producing
|
constraints. Every PHI access attempt passes through the gate stack, producing
|
||||||
a machine-checkable audit trail that satisfies the Security Rule's audit control
|
a machine-checkable audit trail that satisfies the Security Rule's audit control
|
||||||
requirement automatically. No separate logging infrastructure needed. Over a
|
requirement automatically. No separate logging infrastructure needed. Over a
|
||||||
five-year deployment, the accumulated fact store and proof history create
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 68c55deb-72bf-4b15-ac28-bcc792057543
|
||||||
:ID: auto-ifc-ps
|
:ID: auto-ifc-ps
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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,
|
advantage: World Bank compliance is entirely document-based (reports, audits,
|
||||||
site visits). A verified gate system is unprecedented.
|
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
|
International Finance Corporation's standards for environmental and social
|
||||||
sustainability in private sector investment. Eight standards: PS1 (risk
|
sustainability in private sector investment. Eight standards: PS1 (risk
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: fc736aec-ef53-4759-9787-62bc8deea2e7
|
||||||
:ID: auto-ifrs
|
:ID: auto-ifrs
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -23,4 +24,6 @@ most rule-complex — requiring actuarial models, expected credit loss calculati
|
|||||||
and contract classification algorithms.
|
and contract classification algorithms.
|
||||||
|
|
||||||
Who must comply: Publicly listed companies in 166 jurisdictions including the
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 7f46764b-47b8-4892-a526-2c1b9ee6e6df
|
||||||
:ID: auto-irap
|
:ID: auto-irap
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -9,14 +10,14 @@
|
|||||||
** IRAP (Infosec Registered Assessors Program)
|
** IRAP (Infosec Registered Assessors Program)
|
||||||
|
|
||||||
Australian government's cloud security assessment program — analogous to
|
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).
|
IRAP assessment. Managed by the Australian Cyber Security Centre (ACSC).
|
||||||
Assessment levels: Protected (highest), Secret (top secret), Unclassified DLM.
|
Assessment levels: Protected (highest), Secret (top secret), Unclassified DLM.
|
||||||
|
|
||||||
Who must comply: Cloud providers selling to Australian federal, state, and
|
Who must comply: Cloud providers selling to Australian federal, state, and
|
||||||
local government agencies. Also critical infrastructure providers.
|
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
|
Protected-level assessment is expensive and takes 6-12 months. First-mover
|
||||||
advantage: the gate stack's deterministic audit trail can be the primary
|
advantage: the gate stack's deterministic audit trail can be the primary
|
||||||
evidence artifact, reducing assessment scope/cost.
|
evidence artifact, reducing assessment scope/cost.
|
||||||
|
|||||||
@@ -1,16 +1,17 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 085b76cc-4a65-4660-9c70-85aee10ca99e
|
||||||
:ID: auto-ismap
|
:ID: auto-ismap
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: ISMAP (Government Security Framework — Japan)
|
#+title: ISMAP (Government Security Framework — Japan)
|
||||||
#+filetags: :passepartout:compliance:framework:ismap:
|
#+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.
|
amendments added requirements that created compliance gaps.
|
||||||
|
|
||||||
** ISMAP (Government Information System Security Management and Assessment Program)
|
** 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
|
used by Japanese government agencies must be ISMAP-authorized. Managed by the
|
||||||
Digital Agency and the Information-technology Promotion Agency (IPA).
|
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.
|
government agencies.
|
||||||
|
|
||||||
Why it matters: Like FedRAMP, ISMAP is a procurement gate. Authorization is
|
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
|
authorization has exclusive access to the Japanese government market. First-mover
|
||||||
advantage is significant — as of 2025, fewer than 100 services are ISMAP-registered.
|
advantage is significant — as of 2025, fewer than 100 services are ISMAP-registered.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: e2ab887d-9f28-4da6-8388-e6c035e9d9c5
|
||||||
:ID: auto-iso-27001
|
:ID: auto-iso-27001
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
binders). A gate stack that produces audit evidence automatically is not
|
||||||
competing with other software — it is competing with binders.
|
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)
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 748b0cc7-7f42-49fb-8ee3-1ae49048a178
|
||||||
:ID: auto-iso-27701
|
:ID: auto-iso-27701
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -6,8 +7,8 @@
|
|||||||
#+filetags: :passepartout:compliance:framework:iso:
|
#+filetags: :passepartout:compliance:framework:iso:
|
||||||
|
|
||||||
|
|
||||||
International standard extending [[file:iso-27001.org][ISO 27001]] for privacy information management.
|
International standard extending [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] for privacy information management.
|
||||||
Aligns with [[file:gdpr.org][GDPR]] requirements. Provides a framework for PII (personally
|
Aligns with [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] requirements. Provides a framework for PII (personally
|
||||||
identifiable information) controllers and processors.
|
identifiable information) controllers and processors.
|
||||||
|
|
||||||
Why it matters: ISO 27701 bridges information security and privacy compliance.
|
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
|
growing but still low (~1,000 certifications). Early gate package captures the
|
||||||
growth market.
|
growth market.
|
||||||
|
|
||||||
** Basel III (Bank for International Settlements — Basel Committee)
|
** [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III (Bank for International Settlements — Basel Committee)]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: bafdaa23-de0b-444c-9151-c87ac65add32
|
||||||
:ID: auto-lfp-dppp
|
:ID: auto-lfp-dppp
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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)
|
pushing toward privacy regime interoperability. A bilingual (Spanish/English)
|
||||||
gate package covering both LFPDPPP and US frameworks serves the massive
|
gate package covering both LFPDPPP and US frameworks serves the massive
|
||||||
US-Mexico cross-border commerce market. First-mover advantage: LFPDPPP is
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: c871a9f4-dd53-4e93-aa50-6acf0c606a9b
|
||||||
:ID: auto-lgpd
|
:ID: auto-lgpd
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -7,7 +8,7 @@
|
|||||||
|
|
||||||
|
|
||||||
Brazil's comprehensive privacy law (effective 2020, fines effective 2023).
|
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),
|
(controller and operator), requires appointment of DPO (data protection officer),
|
||||||
mandates breach notification to ANPD (National Data Protection Authority) and
|
mandates breach notification to ANPD (National Data Protection Authority) and
|
||||||
affected data subjects. 10 legal bases for processing (vs 6 in GDPR).
|
affected data subjects. 10 legal bases for processing (vs 6 in GDPR).
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 748db16a-1382-4e5e-8812-a5d57a8de131
|
||||||
:ID: auto-nis2
|
:ID: auto-nis2
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
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.
|
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]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 581666ba-f72c-406b-8556-93876d2b30bf
|
||||||
:ID: auto-ny-dfs-500
|
:ID: auto-ny-dfs-500
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
produces. First-mover advantage is significant (few vendors target NY DFS 500
|
||||||
specifically) and the regulation is a template that other states are adopting.
|
specifically) and the regulation is a template that other states are adopting.
|
||||||
|
|
||||||
|
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 022109ad-f031-44c4-8ea0-0b3c9402ca90
|
||||||
:ID: auto-oecd
|
:ID: auto-oecd
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -17,7 +18,7 @@ approach.
|
|||||||
OECD Privacy Guidelines (revised 2013): Eight principles — collection limitation,
|
OECD Privacy Guidelines (revised 2013): Eight principles — collection limitation,
|
||||||
data quality, purpose specification, use limitation, security safeguards,
|
data quality, purpose specification, use limitation, security safeguards,
|
||||||
openness, individual participation, accountability. Non-binding but foundational
|
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
|
OECD AI Principles (adopted 2019, updated 2024): Five values-based principles
|
||||||
— inclusive growth and well-being, human-centered values and fairness,
|
— inclusive growth and well-being, human-centered values and fairness,
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: e777064d-9950-42d5-980d-8c78cda91500
|
||||||
:ID: auto-pipa
|
:ID: auto-pipa
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -21,7 +22,7 @@ against major tech companies. Class action lawsuits permitted.
|
|||||||
Who must comply: Any organization handling personal information of South Korean
|
Who must comply: Any organization handling personal information of South Korean
|
||||||
residents. Extraterritorial scope is broad and actively enforced.
|
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
|
enforcement and higher penalties relative to market size. The gate stack's
|
||||||
purpose-boundary gates map directly to PIPA's purpose limitation requirement.
|
purpose-boundary gates map directly to PIPA's purpose limitation requirement.
|
||||||
First-mover advantage is large — PIPA has fewer compliance automation vendors
|
First-mover advantage is large — PIPA has fewer compliance automation vendors
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 834689e9-be0a-4822-9085-9b6b22294fd2
|
||||||
:ID: auto-privacy-act-aus
|
:ID: auto-privacy-act-aus
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
reforms are being legislated now; early adoption positions the gate stack as
|
||||||
the reference implementation.
|
the reference implementation.
|
||||||
|
|
||||||
** APRA CPS 234 (Prudential Standard — Information Security)
|
** [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234 (Prudential Standard — Information Security)]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: f6a0c00e-e922-44af-99ce-6412c4b73745
|
||||||
:ID: auto-quebec-law-25
|
:ID: auto-quebec-law-25
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -13,7 +14,7 @@ verifiable audit trail — they are all document-based.
|
|||||||
** Canadian provincial privacy (Quebec Law 25, Ontario PHIPA)
|
** Canadian provincial privacy (Quebec Law 25, Ontario PHIPA)
|
||||||
|
|
||||||
Quebec Law 25 (2023-2024 phased) is Canada's most aggressive privacy
|
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
|
privacy impact assessments, consent modernization, data portability, right to
|
||||||
de-index, algorithm transparency (automated decision-making disclosures).
|
de-index, algorithm transparency (automated decision-making disclosures).
|
||||||
Penalties up to $25M CAD or 4% of global revenue.
|
Penalties up to $25M CAD or 4% of global revenue.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 81a815ee-bf2b-4365-9894-b814e4196850
|
||||||
:ID: auto-revenue-table
|
:ID: auto-revenue-table
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -9,39 +10,39 @@
|
|||||||
|
|
||||||
| Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
|
| 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 |
|
| 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 |
|
| [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
|
||||||
| [[file:fedramp.org][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
|
| [[id:e6993701-3c67-49bf-82f3-06907572cbf3][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 |
|
| [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
|
||||||
| [[file:glba.org][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
| [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
||||||
| [[file:ny-dfs-500.org][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
| [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
||||||
| CCPA/CPRA | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
|
| [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][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 |
|
| [[id:748db16a-1382-4e5e-8812-a5d57a8de131][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 |
|
| [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][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 |
|
| [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
|
||||||
| eIDAS 2.0 | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
|
| [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][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 |
|
| [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][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 |
|
| [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
|
||||||
| [[file:appi.org][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
|
| [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][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 |
|
| [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][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: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 |
|
| 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 |
|
| [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][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 |
|
| [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][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 |
|
| [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
|
||||||
| [[file:lgpd.org][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
| [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
||||||
| LFPDPPP | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
|
| [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
|
||||||
| [[file:iso-27001.org][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
|
| [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][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 |
|
| [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][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 |
|
| [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][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 |
|
| [[id:03ebdb80-a9af-4e76-a443-8556424996ed][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 |
|
| [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][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 |
|
| [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][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 |
|
| [[id:177aad72-5626-444d-a2e4-af8e1263b125][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: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
|
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
||||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
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.
|
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||||
At 10,000 such enterprises: $5B/yr.
|
At 10,000 such enterprises: $5B/yr.
|
||||||
|
|
||||||
See also: [[file:compliance-index.org][Compliance index]], [[file:first-mover-window.org][First-mover window analysis]],
|
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
||||||
[[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]], [[file:../../ideas/compute-marketplace.org][Compute marketplace]]
|
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.
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: ed65031c-cbd2-4ad2-bd53-a67791e183cd
|
||||||
:ID: auto-soc2
|
:ID: auto-soc2
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -42,12 +43,12 @@ enterprise customers. Misrepresentation of certification status is fraud.
|
|||||||
|
|
||||||
** Why it matters for the triad
|
** 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
|
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
|
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
|
deterministic gate log serves as the evidence artifact for the audit. No
|
||||||
separate logging SIEM needed. This is the prerequisite to the larger
|
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.
|
buy domain-specific gate packages for the same infrastructure.
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: c9830152-0160-4bdc-ab03-6f308ad43536
|
||||||
:ID: auto-sox
|
:ID: auto-sox
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
advantage: SOX is mature (24 years old) but the audit market is $4B+ and
|
||||||
entirely manual — no competitor has automated the evidence pipeline.
|
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)]]
|
||||||
|
|
||||||
|
|||||||
@@ -1,12 +1,13 @@
|
|||||||
:PROPERTIES:
|
: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]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: UK GDPR (Post-Brexit Data Protection)
|
#+title: UK GDPR (Post-Brexit Data Protection)
|
||||||
#+filetags: :passepartout:compliance:framework:uk:
|
#+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
|
Act 2018. Substantively identical to EU GDPR but diverging over time. The UK
|
||||||
has announced separate reforms targeting AI and digital identity. ICO (Information
|
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.
|
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
|
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.
|
(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)
|
||||||
|
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 6a5884c8-e9b5-477e-bbf6-aa9ffd967739
|
||||||
:ID: auto-un-cefact
|
:ID: auto-un-cefact
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -8,7 +9,7 @@
|
|||||||
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 and Africa. The US (GAAP) is the major holdout.
|
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
|
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
|
reporting error. The gate stack's ACL2 prover can verify that the calculation
|
||||||
implementations match the standard's mathematical requirements. First-mover
|
implementations match the standard's mathematical requirements. First-mover
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 177aad72-5626-444d-a2e4-af8e1263b125
|
||||||
:ID: auto-world-bank-esf
|
:ID: auto-world-bank-esf
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
: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
|
Non-binding but influential — the AI Act, Canada's AIDA, and Japan's AI
|
||||||
guidelines all cite them.
|
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
|
alignment with OECD principles is often a procurement requirement for
|
||||||
international organizations and development finance institutions. First-mover
|
international organizations and development finance institutions. First-mover
|
||||||
advantage is about standard-setting: the gate package that maps to OECD
|
advantage is about standard-setting: the gate package that maps to OECD
|
||||||
|
|||||||
@@ -1,18 +1,19 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 3c6b0449-a8fb-5b89-b82a-34efb21ef5b5
|
:ID: 3c6b0449-a8fb-5b89-b82a-34efb21ef5b5
|
||||||
:END:
|
:END:
|
||||||
#+title: Agora Compute Marketplace
|
#+title: Agora Compute Marketplace
|
||||||
#+filetags: :passepartout:agora:revenue: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:
|
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.
|
**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
|
- Carries errors-and-omissions insurance for the specific regulation
|
||||||
- Submits to annual third-party audits
|
- Submits to annual third-party audits
|
||||||
- Maintains compliance documentation for the proof pipeline
|
- 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).
|
**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).
|
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]].
|
||||||
|
|||||||
@@ -1,14 +1,15 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
|
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
|
||||||
:END:
|
:END:
|
||||||
#+title: Cost Structure — Zero Marginal Cost
|
#+title: Cost Structure — Zero Marginal Cost
|
||||||
#+filetags: :passepartout:economics:cost:marginal:zero:
|
#+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
|
- **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
|
- **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.
|
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.
|
||||||
|
|||||||
@@ -1,17 +1,18 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
|
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
|
||||||
:END:
|
:END:
|
||||||
#+title: Domain Gate Rule Subscriptions
|
#+title: Domain Gate Rule Subscriptions
|
||||||
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:
|
#+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
|
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] package: $50K/yr
|
||||||
- [[file:compliance/soc2.org][SOC2]] package: $50K/yr
|
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] package: $50K/yr
|
||||||
- [[file:compliance/gdpr.org][GDPR]] package: $50K/yr
|
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] package: $50K/yr
|
||||||
- [[file:compliance/fedramp.org][FedRAMP]] package: $100K/yr
|
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] package: $100K/yr
|
||||||
- Combined enterprise: $250K/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]].
|
||||||
|
|||||||
@@ -1,11 +1,12 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2
|
||||||
:ID: effects-growth-flywheel
|
:ID: effects-growth-flywheel
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other
|
#+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other
|
||||||
#+filetags: :passepartout:strategy:growth:effects:flywheel:
|
#+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.
|
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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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.
|
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 |
|
| 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/ |
|
| 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 |
|
| 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).
|
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.
|
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
|
* 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⁶ | 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 |
|
| 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
|
* References
|
||||||
|
|
||||||
- [[file:triad-systemic-effects.org][Systemic effects over time]]
|
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]]
|
||||||
- [[file:growth-strategy.org][Growth phases — zero to billions]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth phases — zero to billions]]
|
||||||
- [[file:time-estimates.org][Development timeline]]
|
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||||
- [[file:revenue-hub.org][Revenue per phase]]
|
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue per phase]]
|
||||||
- [[file:compute-marketplace.org][Compute marketplace]]
|
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||||
- [[file:agora-contracts.org][Attestation and insurance]]
|
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Attestation and insurance]]
|
||||||
- [[file:verification-monopoly.org][Verification monopoly]]
|
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
|
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
|
||||||
:END:
|
:END:
|
||||||
#+title: Evaluation Harness as Certification Service
|
#+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.
|
**Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
|
||||||
**Price:** $50K-$200K per certification.
|
**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.
|
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]].
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
|
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
|
||||||
:END:
|
:END:
|
||||||
#+title: Gate Rule Encoding from Codified Domains
|
#+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."
|
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.
|
||||||
|
|||||||
@@ -1,11 +1,12 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f
|
||||||
:ID: growth-strategy
|
:ID: growth-strategy
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Growth — Two Engines, One Infrastructure
|
#+title: Growth — Two Engines, One Infrastructure
|
||||||
#+filetags: :passepartout:growth:network:strategy:agora:
|
#+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.
|
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.
|
*Growth lever:* Enterprise sales + direct integration. No network effects yet — value must be real without anyone else using it.
|
||||||
|
|
||||||
*Tactics:*
|
*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.
|
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.
|
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.
|
*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.
|
*Growth lever:* Stoa premium enterprise features + insurance marketplace.
|
||||||
|
|
||||||
*Tactics:*
|
*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.
|
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.
|
*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
|
* References
|
||||||
|
|
||||||
- [[file:time-estimates.org][Development timeline]]
|
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||||
- [[file:revenue-hub.org][Revenue streams]]
|
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]
|
||||||
- [[file:investment-thesis.org][Investment thesis]]
|
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]]
|
||||||
- [[file:alternative-growth-social-first.org][Social-first alternative (now integrated)]]
|
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first alternative (now integrated)]]
|
||||||
- [[file:agora-entry-strategy.org][Entry strategy — organized communities]]
|
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
||||||
- [[file:competitive-landscape-agora.org][Agora competitive landscape]]
|
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]]
|
||||||
- [[file:triad-systemic-effects.org][Systemic effects]]
|
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects]]
|
||||||
- [[file:compute-marketplace.org][Compute marketplace]]
|
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||||
- [[file:verification-monopoly.org][Verification monopoly]]
|
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||||
- [[file:agora-contracts.org][Agora contracts]]
|
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]]
|
||||||
- Agora Protocol Specification — full requirements (spec repo at /tmp/agora)
|
- 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)
|
||||||
|
|||||||
@@ -1,16 +1,17 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
|
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
|
||||||
:END:
|
:END:
|
||||||
#+title: Infrastructure Lock-In and Switching Costs
|
#+title: Infrastructure Lock-In and Switching Costs
|
||||||
#+filetags: :passepartout:economics:moats:lock-in:switching:
|
#+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 fact store with a decade of compliance decisions
|
||||||
- A proof forest of verified rules
|
- A proof forest of verified rules
|
||||||
- An empirical decision history tied to their specific deployment
|
- An empirical decision history tied to their specific deployment
|
||||||
- Customized gate rules encoding their specific workflows and approvals
|
- 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.
|
||||||
|
|||||||
@@ -1,17 +1,20 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
|
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
|
||||||
:END:
|
:END:
|
||||||
#+title: Investment Thesis
|
#+title: Investment Thesis
|
||||||
#+filetags: :passepartout:economics: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:
|
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
|
- **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):** [[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)
|
- **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+):** [[file:verification-monopoly.org][verification monopoly]] (UL certification for AI), [[file:infrastructure-lock-in.org][infrastructure lock-in]], planetary compute marketplace
|
- **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."
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 5ac2f037-fc3c-45ac-a6e8-acc20e005cb0
|
||||||
:ID: legal-structure-alternatives
|
:ID: legal-structure-alternatives
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -43,7 +44,7 @@ Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organizatio
|
|||||||
|
|
||||||
** Relevance to This Venture
|
** 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
|
** 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
|
** 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).
|
/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
|
* References
|
||||||
|
|
||||||
- [[file:legal-structure-practical-setup.org][Practical setup guide — Delaware C-Corp + BVI IP Co]]
|
- [[id:433236a2-e5ad-41d4-a27e-4682f8bbc207][Practical setup guide — Delaware C-Corp + BVI IP Co]]
|
||||||
- [[file:asset-protection-structures.org][Asset protection structures overview]]
|
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures overview]]
|
||||||
- [[file:growth-strategy.org][Combined growth strategy]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 433236a2-e5ad-41d4-a27e-4682f8bbc207
|
||||||
:ID: legal-structure-practical-setup
|
:ID: legal-structure-practical-setup
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -17,8 +18,8 @@ Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co).
|
|||||||
[BVI Business Company (IP Co)]
|
[BVI Business Company (IP Co)]
|
||||||
│
|
│
|
||||||
owns the IP assets
|
owns the IP assets
|
||||||
(Passepartout code, gate rules,
|
([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules,
|
||||||
ACL2 libraries, [[file:agora.org][Agora]] protocol
|
ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] protocol
|
||||||
spec, trademarks, domain names)
|
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.
|
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.
|
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
|
* Layer 3: Founders' Ownership
|
||||||
|
|
||||||
@@ -199,6 +200,6 @@ The IP transfer must happen /before/ the IP has significant value. Incorporating
|
|||||||
|
|
||||||
* References
|
* References
|
||||||
|
|
||||||
- [[file:asset-protection-structures.org][Asset protection structures — options analysis]]
|
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]]
|
||||||
- [[file:outbound-sales-compliance.org][Outbound sales compliance — data protection law]]
|
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]]
|
||||||
- [[file:growth-strategy.org][Combined growth strategy — Logos + Agora]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Logos + Agora]]
|
||||||
|
|||||||
@@ -1,12 +1,13 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 67faf52f-9126-50a7-b87e-2bedc610dac7
|
:ID: 67faf52f-9126-50a7-b87e-2bedc610dac7
|
||||||
:END:
|
:END:
|
||||||
#+title: Licensing — AGPLv3 + Commercial
|
#+title: Licensing — AGPLv3 + Commercial
|
||||||
#+filetags: :passepartout:ip:licensing:agpl: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:**
|
**AGPL only covers modifications to code, not:**
|
||||||
- Gate rules specific to a domain (these are data, not code)
|
- Gate rules specific to a domain (these are data, not code)
|
||||||
|
|||||||
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
|
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
|
||||||
:END:
|
:END:
|
||||||
#+title: Why Lisp Is Economically Viable Now
|
#+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.
|
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.
|
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.
|
||||||
|
|||||||
@@ -1,16 +1,17 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b
|
:ID: 1c95ce7d-a2db-506a-9608-df68f9ae211b
|
||||||
:END:
|
:END:
|
||||||
#+title: Lisp Machine Security — Unified Memory Threat Model
|
#+title: Lisp Machine Security — Unified Memory Threat Model
|
||||||
#+filetags: :passepartout:security:lisp-machine:pmp:isolation:
|
#+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.
|
This note analyzes the threat model and proposes a hardware-enforced privilege separation within the single Lisp image.
|
||||||
|
|
||||||
**The problem**
|
**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:
|
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 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.
|
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 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?
|
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**
|
**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
|
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
|
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
|
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
|
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
|
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
|
||||||
|
|||||||
@@ -1,17 +1,18 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
|
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
|
||||||
:END:
|
:END:
|
||||||
#+title: Competitive Moats
|
#+title: Competitive Moats
|
||||||
#+filetags: :passepartout:economics:moats:competition:
|
#+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):**
|
**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.
|
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.
|
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.
|
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. **[[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.
|
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.
|
**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.
|
||||||
|
|||||||
@@ -7,7 +7,7 @@
|
|||||||
|
|
||||||
** What
|
** 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.
|
knowledge base — no pandoc conversion, no markdown intermediary.
|
||||||
|
|
||||||
Currently gbrain provides vector search + entity linking over markdown,
|
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.
|
This is adequate while the gate stack and planner are the priority.
|
||||||
The native org module replaces gbrain entirely once built.
|
The native org module replaces gbrain entirely once built.
|
||||||
|
|
||||||
** See also
|
The nightly pipeline uses gbrain to provide hybrid search across the existing
|
||||||
[[file:../../concepts/compliance-framework-mapping.org][[[file:compliance-framework-mapping.org][Compliance framework mapping]]]]
|
org files. The [[id:36e5b948-e07b-477f-9036-4dfe88254347][compliance framework mapping]] is the largest single
|
||||||
[[file:../../ideas/passepartout-economics.org][[[file:passepartout-economics.org][Passepartout economics]]]]
|
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.
|
||||||
|
|||||||
@@ -2,6 +2,7 @@
|
|||||||
#+filetags: :passepartout:framework:time:scale:hierarchy:
|
#+filetags: :passepartout:framework:time:scale:hierarchy:
|
||||||
|
|
||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 2cdca4b0-6b41-44b4-acb0-af21d0e27b00
|
||||||
:ID: orders-of-magnitude-time
|
:ID: orders-of-magnitude-time
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
@@ -17,7 +18,7 @@ The hierarchy:
|
|||||||
| Days | Shippable thing, momentum building | Next day | Drift, distraction |
|
| Days | Shippable thing, momentum building | Next day | Drift, distraction |
|
||||||
| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
|
| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
|
||||||
| Months | Product cycle, hiring, traction | One data point | Bleeding out slow |
|
| 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 |
|
| Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility |
|
||||||
|
|
||||||
Practical use:
|
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).
|
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.
|
||||||
|
|||||||
@@ -1,11 +1,12 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: 98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b
|
||||||
:ID: outbound-sales-compliance
|
:ID: outbound-sales-compliance
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Outbound Sales — Legal Framework & Compliance Architecture
|
#+title: Outbound Sales — Legal Framework & Compliance Architecture
|
||||||
#+filetags: :passepartout:compliance:legal:gdpr:outbound:
|
#+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.
|
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: /unsubscribe-link/ — every message must carry a working opt-out
|
||||||
- Gate: /no-harvesting/ — if contact was sourced via automated scraping, flag for review
|
- 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:
|
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.
|
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: /erasure-compliance/ — maintain an erasure queue with 30-day SLA
|
||||||
- Gate: /data-minimization/ — reject leads with unnecessary enrichment data
|
- 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.
|
/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)
|
- CAN-SPAM Act (15 U.S.C. 7701-7713)
|
||||||
- GDPR (Regulation (EU) 2016/679)
|
- 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)
|
- Egypt PDPL (Law No. 151 of 2020)
|
||||||
- CASL (S.C. 2010, c. 23)
|
- CASL (S.C. 2010, c. 23)
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
@@ -1,4 +1,5 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
|
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
|
||||||
:END:
|
:END:
|
||||||
#+title: Patent Strategy
|
#+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.
|
**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.
|
||||||
|
|||||||
@@ -1,10 +1,11 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
:ID: 1a2b38df-20ba-58ca-ba55-a072be67bd0d
|
:ID: 1a2b38df-20ba-58ca-ba55-a072be67bd0d
|
||||||
:END:
|
:END:
|
||||||
#+title: Personal Data Store as a Service
|
#+title: Personal Data Store as a Service
|
||||||
#+filetags: :passepartout:agora:revenue:pds:saas:
|
#+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
|
- **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
|
- **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).
|
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]].
|
||||||
|
|||||||
@@ -1,24 +1,25 @@
|
|||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
:ID: ed05cab4-88e9-4e25-b7c9-346fa39c69a0
|
||||||
:ID: revenue-hub
|
:ID: revenue-hub
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Revenue Streams — Overview
|
#+title: Revenue Streams — Overview
|
||||||
#+filetags: :passepartout:revenue:index:business-model:
|
#+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
|
* Revenue by Triad Component
|
||||||
|
|
||||||
** Logos (the mind) — Revenue streams
|
** 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 |
|
| 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 |
|
| Domain gate packages | Zero | SaaS subscriptions per compliance domain |
|
||||||
| Evaluation harness | Zero | Certification-as-a-service, regression suite access |
|
| 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 |
|
| Verified skill marketplace | End State | Commission on third-party gate rules |
|
||||||
|
|
||||||
*** Unexplored Logos streams
|
*** 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. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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 |
|
| Stream | Phase | Rationale |
|
||||||
|--------+-------+-----------|
|
|--------+-------+-----------|
|
||||||
| Lisp Machine hardware | End State | Tenstorrent/FPGA appliances. Hardware margins + recurring gate rules. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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
|
** 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 |
|
| 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.
|
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
|
* 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 |
|
| Multi-instance governance | Agora | Large | Enterprise | Annual |
|
||||||
| Namespace sub-leasing | Agora | Small | Individuals | Per-transaction |
|
| 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)
|
** End State streams (full Lisp Machine, 2-5 years)
|
||||||
|
|
||||||
| Stream | Component | TAM | Revenue type |
|
| 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 |
|
| Infrastructure lock-in | All | $100B+ | Rent extraction |
|
||||||
| Compute marketplace | Agora | Venture-scale | Transaction fees |
|
| Compute marketplace | Agora | Venture-scale | Transaction fees |
|
||||||
| Lisp Machine hardware | Stoa | Large | Hardware + subs |
|
| 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
|
* 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 |
|
| 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
|
* Detailed References
|
||||||
|
|
||||||
- [[file:passepartout-economics.org][Passepartout economics (full thesis)]] — the unified economics document
|
- [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics (full thesis)]] — the unified economics document
|
||||||
- [[file:investment-thesis.org][Investment thesis]] — three revenue horizons, $2M to $1B+
|
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] — three revenue horizons, $2M to $1B+
|
||||||
- [[file:cost-structure.org][Cost structure and zero marginal cost]]
|
- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]]
|
||||||
- [[file:compliance/revenue-table.org][Compliance [[file:compliance/revenue-table.org][revenue table]]]] — concrete pricing per framework
|
- [[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] — concrete pricing per framework
|
||||||
- [[file:compliance/compliance-index.org][Compliance framework index]] — 41 frameworks by region and priority
|
- [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] — 41 frameworks by region and priority
|
||||||
- [[file:compliance/first-mover-window.org][First-mover window analysis]]
|
- [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]]
|
||||||
- [[file:time-estimates.org][Development timeline]] — Phase Zero vs End State
|
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State
|
||||||
- [[file:licensing.org][Licensing strategy]] — AGPL + commercial
|
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing strategy]] — AGPL + commercial
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user