Compare commits
55 Commits
cc3976fb7f
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
|
67fac2444b | ||
|
|
284c5bd324 | ||
|
|
9ce3883005 | ||
|
|
2ee60b5b4a | ||
|
|
d938f353e4 | ||
|
|
8b1b481828 | ||
|
|
5ac701e8ec | ||
|
|
60e9c1d7a6 | ||
|
|
0956711af4 | ||
|
|
01bea0c982 | ||
|
|
c5d0695acf | ||
|
|
6e992cc0c5 | ||
|
|
2e8cf19f9e | ||
|
|
9b795df14e | ||
|
|
ac99eed182 | ||
|
|
63279a995f | ||
|
|
dd8759179a | ||
|
|
a176eedd2b | ||
|
|
179bcbaaa4 | ||
|
|
9553a90060 | ||
|
|
b1d00c79e6 | ||
|
|
47be29b1d0 | ||
|
|
1f5fc89b46 | ||
|
|
56f0588b54 | ||
|
|
47ca8689fc | ||
|
|
5087f98e4d | ||
|
|
dbd651ba2c | ||
|
|
2f1aacd39c | ||
|
|
af132f7e88 | ||
|
|
3efbf760e6 | ||
|
|
7fa9dceb82 | ||
|
|
ed232e2122 | ||
|
|
386e6d40be | ||
|
|
f8240967f5 | ||
|
|
f10bd14091 | ||
|
|
a4113c2d5c | ||
|
|
0b77ea0ac9 | ||
|
|
73fc33f02f | ||
|
|
f09a59aaf3 | ||
|
|
6b6838fb2c | ||
|
|
f3e2d15d47 | ||
|
|
cf3bd2ee54 | ||
|
|
d2387f1074 | ||
|
|
64d027a0a0 | ||
|
|
5086ac4fbe | ||
|
|
73dea1f654 | ||
|
|
d3300adbf7 | ||
|
|
34ab923308 | ||
|
|
335735b655 | ||
|
|
4c38127b45 | ||
|
|
ede891f2ce | ||
|
|
348f2736a8 | ||
|
|
0a8e77e949 | ||
|
|
4b60244919 | ||
|
|
2578bfee61 |
307
.org-ids.json
307
.org-ids.json
@@ -1,119 +1,200 @@
|
|||||||
{
|
{
|
||||||
"284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f": "_index.org",
|
"284f5c7a-1d2b-4e3f-8c6d-9a0b1c2d3e4f": "_index.org",
|
||||||
"04c2f221-c54f-51e5-b40a-48822cd16d45": "ideas/common-logic-iso-24707.org",
|
"09a03e7f-c3f8-438a-abe3-7a7570957565": "resources/worse-is-better.org",
|
||||||
"42c86e6f-4f27-4993-8238-b7bc7d15fb7b": "ideas/stoa-overview.org",
|
"4f4c1cf2-490d-4b9a-b6a5-4917d3b66887": "resources/_index.org",
|
||||||
"2f783eb4-638e-5afa-9b59-6224d086a712": "ideas/infrastructure-lock-in.org",
|
"ee8f3b2a-4c7d-4e1b-9b0a-6d8f2e3c1a5b": "resources/neurosymbolic.org",
|
||||||
"1a2b38df-20ba-58ca-ba55-a072be67bd0d": "ideas/pds-as-a-service.org",
|
"a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d": "projects/_index.org",
|
||||||
"1c95ce7d-a2db-506a-9608-df68f9ae211b": "ideas/lisp-machine-security.org",
|
"89f592aa-9c46-42db-a6c7-54dc91fe2172": "projects/cl-modernization/_index.org",
|
||||||
"00ab3a4d-e3de-5605-a67d-12935bb36ab5": "ideas/comparison-with-symbolics.org",
|
"433236a2-e5ad-41d4-a27e-4682f8bbc207": "projects/flags/legal-structure-practical-setup.org",
|
||||||
"5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "ideas/legal-structure-alternatives.org",
|
"0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "projects/flags/asset-protection-structures.org",
|
||||||
"dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "ideas/time-estimates.org",
|
"5ac2f037-fc3c-45ac-a6e8-acc20e005cb0": "projects/flags/legal-structure-alternatives.org",
|
||||||
|
"1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b": "projects/flags/_index.org",
|
||||||
|
"7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/_index.org",
|
||||||
|
"04c2f221-c54f-51e5-b40a-48822cd16d45": "projects/passepartout/common-logic-iso-24707.org",
|
||||||
|
"29a7d05f-1aec-41a4-a213-e52551eeb9eb": "projects/passepartout/ROADMAP.org",
|
||||||
|
"d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f": "projects/passepartout/architecture/distinguishing-features.org",
|
||||||
|
"3129eae6-f9f2-40fe-a419-8c1af728c86d": "projects/passepartout/architecture/faster-theorem-proving.org",
|
||||||
|
"af9ce196-24a5-4035-bc02-83ddd60c1b09": "projects/passepartout/architecture/repo-organization.org",
|
||||||
|
"f6a7b8c9-0d1e-2f3a-4b5c-6d7e8f90abcd": "projects/passepartout/architecture/biomimicry.org",
|
||||||
|
"a7b8c9d0-1e2f-3a4b-5c6d-7e8f90abcdef": "projects/passepartout/architecture/neuro-neuromorphic-symbolic-comparison.org",
|
||||||
|
"1c95ce7d-a2db-506a-9608-df68f9ae211b": "projects/passepartout/architecture/security.org",
|
||||||
|
"be9bccc7-5adf-4d0d-8ee4-8855892189bf": "projects/passepartout/architecture/neurosymbolic-loop-architectures.org",
|
||||||
|
"26725506-399c-48c5-a797-46b48e8861d7": "projects/passepartout/architecture/self.org",
|
||||||
|
"5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a": "projects/passepartout/architecture/_index.org",
|
||||||
|
"b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba": "projects/passepartout/architecture/systemic-effects.org",
|
||||||
|
"7f4e6b9a-2c1d-5e8f-9a3b-6d7c4e5f2a1b": "projects/passepartout/architecture/org-knowledge-base.org",
|
||||||
|
"971cd9e7-2cc5-4743-8042-2469dbe4078f": "projects/passepartout/architecture/lisp-foundation.org",
|
||||||
|
"d2722576-fc9b-4bd3-bc2f-f5692b561b4e": "projects/passepartout/architecture/academic.org",
|
||||||
|
"8cb760e2-37c6-4a78-af4d-f89f69d1678b": "projects/passepartout/architecture/stages/_index.org",
|
||||||
|
"4a1f23b0-abc8-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-7-remaining.org",
|
||||||
|
"4a1f23b0-abc6-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-5-weights.org",
|
||||||
|
"4a1f23b0-abc7-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-6-training.org",
|
||||||
|
"4a1f23b0-abc3-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-1-gate.org",
|
||||||
|
"4a1f23b0-abc5-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-4-inference.org",
|
||||||
|
"4a1f23b0-abc4-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-3-lisp-machine.org",
|
||||||
|
"4a1f23b0-abc2-4def-9876-543210abcdef": "projects/passepartout/architecture/stages/stage-2-social-protocol.org",
|
||||||
|
"4b5c6d7e-8f9a-0b1c-2d3e-4f5a6b7c8d9e": "projects/passepartout/architecture/knowledge-layers/neurological-empirical.org",
|
||||||
|
"329bd4fb-702a-4a2b-9c63-69281aacb83a": "projects/passepartout/architecture/knowledge-layers/_index.org",
|
||||||
|
"5c6d7e8f-9a0b-1c2d-3e4f-5a6b7c8d9e0f": "projects/passepartout/architecture/knowledge-layers/practical-implications.org",
|
||||||
|
"27c03e1d-283f-4e3d-9f32-6476aafde97e": "projects/passepartout/architecture/design/open-questions.org",
|
||||||
|
"9d2255b0-e6c9-479e-9e93-4f871a2193fe": "projects/passepartout/architecture/design/relation-to-passepartouts-existing-architecture.org",
|
||||||
|
"e32290a0-a02a-4af7-ae22-243d04a7ac82": "projects/passepartout/architecture/design/_index.org",
|
||||||
|
"e9c7a384-b42d-4dff-8da7-d4b62bb69956": "projects/passepartout/architecture/design/the-symbolic-engine/the-five-architecture-options.org",
|
||||||
|
"1937ee88-945e-4014-b5a0-cb3c8dcf1689": "projects/passepartout/architecture/design/the-two-brains/the-probabilistic-deterministic-split.org",
|
||||||
|
"d251d338-f52e-4a17-b458-a255dd097b98": "projects/passepartout/architecture/design/validation/whiteheads-process-philosophy-and-type-theory.org",
|
||||||
|
"183253ff-a0b7-468e-9858-6cb8ae2fb246": "projects/passepartout/architecture/design/knowledge-sources/semantic-wikipedia-as-entity-backbone.org",
|
||||||
|
"772ae489-b10a-48a0-bc3b-29136163d45b": "projects/passepartout/architecture/design/implementation-properties/performance-why-ontology-growth-doesnt-make-the-system-slower.org",
|
||||||
|
"0a33bd83-ff3c-4eac-bc97-83eb6702051a": "projects/passepartout/architecture/design/foundation/non-negotiable-identity.org",
|
||||||
|
"1ede13cb-05c0-4b1a-a873-98cf89bade81": "projects/passepartout/architecture/design/engineering-infrastructure/the-repl-as-cognitive-substrate.org",
|
||||||
|
"02f01d02-fc56-4551-81da-8704dbd65d89": "projects/passepartout/architecture/design/safety-self-preservation/self-preservation-the-active-third-law.org",
|
||||||
|
"e5f6a7b8-9c0d-1e2f-3a4b-5c6d7e8f90ab": "projects/passepartout/hardware/server-build-bom.org",
|
||||||
|
"d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f90": "projects/passepartout/hardware/_index.org",
|
||||||
|
"a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d": "projects/passepartout/hardware/server-rack-build.org",
|
||||||
|
"68ffa49f-f0d8-42cf-8b69-ae69de8bb815": "projects/passepartout/social-protocol/requirements-10-governance-and-assets.org",
|
||||||
|
"b25bf753-9799-41ab-82f5-1a1416db756b": "projects/passepartout/social-protocol/requirements-01-overview.org",
|
||||||
|
"a3243dd0-3209-423b-98e1-51c3eada2658": "projects/passepartout/social-protocol/requirements-07-advanced-integration.org",
|
||||||
|
"0f949f6c-4cf1-49eb-b9a4-ebcac27ee548": "projects/passepartout/social-protocol/requirements-05-social.org",
|
||||||
|
"72570648-d943-42e5-a781-3b09791ac6ec": "projects/passepartout/social-protocol/requirements-11-assessment.org",
|
||||||
|
"90484f4a-5b70-4001-93d6-e610e54ed573": "projects/passepartout/social-protocol/requirements-06-exchange-and-contracts.org",
|
||||||
|
"2cace571-76bb-4c34-a5f4-68bc20b2e884": "projects/passepartout/social-protocol/requirements-10-user-journey.org",
|
||||||
|
"6fe67db6-25bd-4d11-bd1d-b44ec809e858": "projects/passepartout/social-protocol/requirements-02-identity.org",
|
||||||
|
"8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d": "projects/passepartout/social-protocol/requirements-09-implementation.org",
|
||||||
|
"f6cfc54b-919b-4311-bcbf-65e976755d40": "projects/passepartout/social-protocol/requirements-04-the-primitive.org",
|
||||||
|
"df02cddc-944a-4bcd-8ef5-f080870d5f49": "projects/passepartout/social-protocol/requirements-08-library.org",
|
||||||
|
"8b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e": "projects/passepartout/social-protocol/_index.org",
|
||||||
|
"3b43a9b8-31d1-4479-a35f-22273b74f0c7": "projects/passepartout/social-protocol/requirements-03-infrastructure.org",
|
||||||
|
"10289e64-a4ff-4c34-828f-f3a9c769b73d": "projects/passepartout/social-protocol/requirements-00-readme.org",
|
||||||
|
"c34940cc-090e-57c4-8020-e78b1d32b96c": "projects/passepartout/strategy/domain-gate-packages.org",
|
||||||
|
"6d2e3f4a-5b6c-7d8e-9f0a-1b2c3d4e5f6a": "projects/passepartout/strategy/adoption.org",
|
||||||
|
"72db9428-d6e4-472d-9693-49335f888e48": "projects/passepartout/strategy/game-theory.org",
|
||||||
|
"b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e": "projects/passepartout/strategy/hosting-economics.org",
|
||||||
|
"67faf52f-9126-50a7-b87e-2bedc610dac7": "projects/passepartout/strategy/licensing.org",
|
||||||
|
"c7d3f1a2-8b4e-5d6f-9a1c-3b2d4e5f6a7b": "projects/passepartout/strategy/domain-sequencing.org",
|
||||||
|
"9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f": "projects/passepartout/strategy/_index.org",
|
||||||
|
"aa6d062e-a520-5d14-8773-00687ed9c689": "projects/passepartout/strategy/moats.org",
|
||||||
|
"29e4dbf3-cf19-589c-8b14-389e8a39d564": "projects/passepartout/strategy/upgrade-lifecycle.org",
|
||||||
|
"ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "projects/passepartout/strategy/revenue.org",
|
||||||
|
"dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70": "projects/passepartout/strategy/time-estimates.org",
|
||||||
|
"1a2b38df-20ba-58ca-ba55-a072be67bd0d": "projects/passepartout/strategy/pds-as-a-service.org",
|
||||||
|
"3c6b0449-a8fb-5b89-b82a-34efb21ef5b5": "projects/passepartout/strategy/compute-marketplace.org",
|
||||||
|
"3aa22300-2f25-57b0-8787-9f199cc978b1": "projects/passepartout/strategy/competitors/competitive-analysis.org",
|
||||||
|
"a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d": "projects/passepartout/strategy/competitors/rainbird-ai-case-study.org",
|
||||||
|
"00ab3a4d-e3de-5605-a67d-12935bb36ab5": "projects/passepartout/strategy/competitors/comparison-with-symbolics.org",
|
||||||
|
"0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a": "projects/passepartout/strategy/competitors/_index.org",
|
||||||
|
"1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f": "projects/passepartout/strategy/competitors/social-protocol-competitive-landscape.org",
|
||||||
|
"85ca69dd-d085-4a55-ad11-021910b1f82e": "projects/passepartout/strategy/competitors/ai-agents-scoping/openclaw.org",
|
||||||
|
"7a060b36-36db-4eb7-b8cc-844bd6ac9d36": "projects/passepartout/strategy/competitors/ai-agents-scoping/opencode.org",
|
||||||
|
"416bab7c-4300-4d50-838a-5c7a8ad45d96": "projects/passepartout/strategy/competitors/ai-agents-scoping/thoth.org",
|
||||||
|
"6883c4d2-b63b-4d2b-b224-2240ae748e7f": "projects/passepartout/strategy/competitors/ai-agents-scoping/_index.org",
|
||||||
|
"c3aab2e8-7e43-4abc-93f0-741675cfd78c": "projects/passepartout/strategy/competitors/ai-agents-scoping/aider.org",
|
||||||
|
"8d73ccb9-34e4-4899-b0c3-605998e9bebc": "projects/passepartout/strategy/competitors/ai-agents-scoping/gemini-cli.org",
|
||||||
|
"22d0a159-68a2-4587-9375-5046beddc20c": "projects/passepartout/strategy/competitors/ai-agents-scoping/continue.org",
|
||||||
|
"e929ff32-28d8-4a29-bf74-d55babc040d1": "projects/passepartout/strategy/competitors/ai-agents-scoping/codex-cli.org",
|
||||||
|
"c652688a-1ea0-487c-9222-00e954efe8a1": "projects/passepartout/strategy/competitors/ai-agents-scoping/hermes-agent.org",
|
||||||
|
"512dd121-2292-4f3d-ac53-31bf3d12a60f": "projects/passepartout/strategy/competitors/ai-agents-scoping/claude-code.org",
|
||||||
|
"8c7b9812-f8d6-4347-8915-ce8e520b7914": "projects/passepartout/strategy/social-protocol/social-protocol-entry-strategy.org",
|
||||||
|
"1d074690-a279-59cb-b91d-e9a22ae104ad": "projects/passepartout/strategy/social-protocol/social-protocol-overview.org",
|
||||||
|
"75bc14db-d241-4af8-a4e0-f14aff654d17": "projects/passepartout/strategy/social-protocol/_index.org",
|
||||||
|
"2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "projects/passepartout/strategy/social-protocol/social-protocol-usernames.org",
|
||||||
|
"64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "projects/passepartout/strategy/social-protocol/social-protocol-contracts.org",
|
||||||
|
"7c4c5cca-1c63-4398-9b75-cf221e77dba0": "projects/passepartout/strategy/compliance/_index.org",
|
||||||
|
"98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b": "projects/passepartout/strategy/compliance/outbound-sales-compliance.org",
|
||||||
|
"b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "projects/passepartout/strategy/compliance/compliance-regimes/appi.org",
|
||||||
|
"e777064d-9950-42d5-980d-8c78cda91500": "projects/passepartout/strategy/compliance/compliance-regimes/pipa.org",
|
||||||
|
"e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "projects/passepartout/strategy/compliance/compliance-regimes/iso-27001.org",
|
||||||
|
"4a2bc62b-3f21-4212-9cd9-f9add8fc0be1": "projects/passepartout/strategy/compliance/compliance-regimes/glba.org",
|
||||||
|
"03ebdb80-a9af-4e76-a443-8556424996ed": "projects/passepartout/strategy/compliance/compliance-regimes/fatf.org",
|
||||||
|
"e6993701-3c67-49bf-82f3-06907572cbf3": "projects/passepartout/strategy/compliance/compliance-regimes/fedramp.org",
|
||||||
|
"7f46764b-47b8-4892-a526-2c1b9ee6e6df": "projects/passepartout/strategy/compliance/compliance-regimes/irap.org",
|
||||||
|
"fc736aec-ef53-4759-9787-62bc8deea2e7": "projects/passepartout/strategy/compliance/compliance-regimes/ifrs.org",
|
||||||
|
"68c55deb-72bf-4b15-ac28-bcc792057543": "projects/passepartout/strategy/compliance/compliance-regimes/ifc-ps.org",
|
||||||
|
"513d5996-4ac7-4567-a992-18fc01599104": "projects/passepartout/strategy/compliance/compliance-regimes/gdpr.org",
|
||||||
|
"6a5884c8-e9b5-477e-bbf6-aa9ffd967739": "projects/passepartout/strategy/compliance/compliance-regimes/un-cefact.org",
|
||||||
|
"84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f": "projects/passepartout/strategy/compliance/compliance-regimes/hipaa.org",
|
||||||
|
"177aad72-5626-444d-a2e4-af8e1263b125": "projects/passepartout/strategy/compliance/compliance-regimes/world-bank-esf.org",
|
||||||
|
"834689e9-be0a-4822-9085-9b6b22294fd2": "projects/passepartout/strategy/compliance/compliance-regimes/privacy-act-aus.org",
|
||||||
|
"904f5f12-ec9a-4cbf-854a-0b9b1e11a521": "projects/passepartout/strategy/compliance/compliance-regimes/apra-cps-234.org",
|
||||||
|
"1c4c91ec-c465-44ab-bd91-4c3b45909ddb": "projects/passepartout/strategy/compliance/compliance-regimes/_index.org",
|
||||||
|
"c871a9f4-dd53-4e93-aa50-6acf0c606a9b": "projects/passepartout/strategy/compliance/compliance-regimes/lgpd.org",
|
||||||
|
"b8cf51e8-5f39-49ad-9547-a792a2e446aa": "projects/passepartout/strategy/compliance/compliance-regimes/eidas2.org",
|
||||||
|
"06fcdb02-2643-4f9d-ab41-e711a99cc390": "projects/passepartout/strategy/compliance/compliance-regimes/eu-ai-act.org",
|
||||||
|
"ed65031c-cbd2-4ad2-bd53-a67791e183cd": "projects/passepartout/strategy/compliance/compliance-regimes/soc2.org",
|
||||||
|
"c9830152-0160-4bdc-ab03-6f308ad43536": "projects/passepartout/strategy/compliance/compliance-regimes/sox.org",
|
||||||
|
"f6a0c00e-e922-44af-99ce-6412c4b73745": "projects/passepartout/strategy/compliance/compliance-regimes/quebec-law-25.org",
|
||||||
|
"748db16a-1382-4e5e-8812-a5d57a8de131": "projects/passepartout/strategy/compliance/compliance-regimes/nis2.org",
|
||||||
|
"87996d87-100c-4bf6-8546-a860b9d7c25b": "projects/passepartout/strategy/compliance/compliance-regimes/ccpa-cpra.org",
|
||||||
|
"ce81fefc-b7a8-4be5-912f-55fd30970b6e": "projects/passepartout/strategy/compliance/compliance-regimes/cra.org",
|
||||||
|
"085b76cc-4a65-4660-9c70-85aee10ca99e": "projects/passepartout/strategy/compliance/compliance-regimes/ismap.org",
|
||||||
|
"748b0cc7-7f42-49fb-8ee3-1ae49048a178": "projects/passepartout/strategy/compliance/compliance-regimes/iso-27701.org",
|
||||||
|
"022109ad-f031-44c4-8ea0-0b3c9402ca90": "projects/passepartout/strategy/compliance/compliance-regimes/oecd.org",
|
||||||
|
"fed19a24-ad81-4837-a12b-dafbd3ec110a": "projects/passepartout/strategy/compliance/compliance-regimes/dpdp-act.org",
|
||||||
|
"9bc29937-d59a-4ae4-9623-3d17a1fe6ebb": "projects/passepartout/strategy/compliance/compliance-regimes/uk-gdpr.org",
|
||||||
|
"4eef0993-6671-41cf-ba20-d1443a3ec49d": "projects/passepartout/strategy/compliance/compliance-regimes/basel-iii.org",
|
||||||
|
"581666ba-f72c-406b-8556-93876d2b30bf": "projects/passepartout/strategy/compliance/compliance-regimes/ny-dfs-500.org",
|
||||||
|
"bafdaa23-de0b-444c-9151-c87ac65add32": "projects/passepartout/strategy/compliance/compliance-regimes/lfp-dppp.org",
|
||||||
|
"717ef2df-2a80-4362-b23a-5e7e12554251": "projects/passepartout/strategy/compliance/compliance-regimes/dora.org",
|
||||||
|
"5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "projects/passepartout/strategy/impact/ai-industry-impact.org",
|
||||||
|
"c2d3e4f5-a6b7-8901-2cde-f01234567890": "projects/passepartout/strategy/impact/phase-2-impact.org",
|
||||||
|
"a0b1c2d3-e4f5-6789-0abc-def012345678": "projects/passepartout/strategy/impact/phase-0-impact.org",
|
||||||
|
"92ccd074-04a0-4e45-a44f-9da24ea20a9b": "projects/passepartout/strategy/impact/impact.org",
|
||||||
|
"96e7a54e-d801-4b6e-bdc9-ea9dbd4fa51d": "projects/passepartout/strategy/impact/_index.org",
|
||||||
|
"b1c2d3e4-f5a6-7890-1bcd-ef0123456789": "projects/passepartout/strategy/impact/phase-1-impact.org",
|
||||||
|
"e4f5a6b7-c8d9-0123-4ef0-123456789012": "projects/passepartout/strategy/impact/phase-4-impact.org",
|
||||||
|
"d3e4f5a6-b7c8-9012-3def-012345678901": "projects/passepartout/strategy/impact/phase-3-impact.org",
|
||||||
|
"827bc546-e887-5b7c-9b65-6392beaf0920": "projects/passepartout/strategy/verification/verification-monopoly.org",
|
||||||
|
"89909ac6-8b4f-4a60-bbeb-52992c8f5135": "projects/passepartout/strategy/verification/_index.org",
|
||||||
|
"d84679f1-c0c5-5be4-b19c-6573560640ee": "projects/passepartout/strategy/verification/verified-skill-marketplace.org",
|
||||||
|
"84a537b4-4256-50c8-91f5-dd5b4538418f": "projects/passepartout/strategy/verification/verification-appliance.org",
|
||||||
|
"efc76898-03f7-57ba-923d-35d65da88bb7": "projects/passepartout/strategy/verification/sufficiency-flip.org",
|
||||||
"2cdca4b0-6b41-44b4-acb0-af21d0e27b00": "ideas/orders-of-magnitude-time.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",
|
"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",
|
"329a30cd-55fb-496d-a60b-91388c211bba": "ideas/_index.org",
|
||||||
"67faf52f-9126-50a7-b87e-2bedc610dac7": "ideas/licensing.org",
|
"f467ce16-1861-4ebd-96ed-b52fea909515": "ideas/lisp-game-engine-substrate.org",
|
||||||
"36e5b948-e07b-477f-9036-4dfe88254347": "ideas/compliance-framework-mapping.org",
|
"aae3b3a9-05c2-4acd-bfd4-a7f65003c0bf": "ideas/lisp-geometry-engine.org",
|
||||||
"3c6b0449-a8fb-5b89-b82a-34efb21ef5b5": "ideas/compute-marketplace.org",
|
"8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e": "ideas/viability/passepartout-bootstrap-mathematica.org",
|
||||||
"1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f": "ideas/competitive-landscape-agora.org",
|
"7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d": "ideas/viability/open-source-wolfram-lisp.org",
|
||||||
"efc76898-03f7-57ba-923d-35d65da88bb7": "ideas/sufficiency-flip.org",
|
"f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f": "ideas/viability/schafmeister-clasp.org",
|
||||||
"1c3ec48b-446c-50d2-b53e-126a81f5143f": "ideas/triad-index.org",
|
"d08f4f7b-6800-4625-a8f6-f91b3231ae2e": "projects/passepartout/architecture/design/the-symbolic-engine/merkle-dag-for-version-history.org",
|
||||||
"45258a2d-1675-562c-9024-5d1eb2f1ea56": "ideas/evaluation-harness.org",
|
"f23e5518-bf2a-459e-8d2e-a9645fad76ac": "projects/passepartout/architecture/design/the-symbolic-engine/cardinality-policies-singular-dual-and-plural-facts.org",
|
||||||
"2e390c1d-65f3-5fb3-b898-ac3fc4291ee7": "ideas/agora-usernames.org",
|
"ce124de6-6777-4dca-aaf3-57e842c1855b": "projects/passepartout/architecture/design/the-symbolic-engine/how-categories-grow-the-organic-ontology.org",
|
||||||
"ed05cab4-88e9-4e25-b7c9-346fa39c69a0": "ideas/revenue-hub.org",
|
"49104db7-0c41-4507-8755-42b4a48b7cc9": "projects/passepartout/architecture/design/the-symbolic-engine/ontology-versioning-how-worldviews-change-without-losing-perspective.org",
|
||||||
"d84679f1-c0c5-5be4-b19c-6573560640ee": "ideas/verified-skill-marketplace.org",
|
"699de53a-06ff-4815-9f9d-70b006d372b8": "projects/passepartout/architecture/design/the-symbolic-engine/knowledge-graph-type-hierarchy-structural-anti-self-reference-v300.org",
|
||||||
"64708e1f-00e9-4cb7-b44b-ea0b98e5296d": "ideas/agora-contracts.org",
|
"5788ad0f-45fb-4b2d-a3ab-09a4d95f351c": "projects/passepartout/architecture/design/the-symbolic-engine/the-awakening-sufficiency-criterion.org",
|
||||||
"a1fac32a-47de-5fbd-b67d-29152c851747": "ideas/triad-overview.org",
|
"1b88cec6-76d8-4496-ae36-1bf16b5bc962": "projects/passepartout/architecture/design/the-symbolic-engine/ephemeral-first-persistent-later.org",
|
||||||
"827bc546-e887-5b7c-9b65-6392beaf0920": "ideas/verification-monopoly.org",
|
"b21917d8-cb6e-4959-96c0-9326b0611134": "projects/passepartout/architecture/design/the-symbolic-engine/the-chosen-path-option-4-starting-with-option-5.org",
|
||||||
"9af13fff-9725-542b-93b1-a555bc74ad72": "ideas/lisp-economics.org",
|
"28a8caf7-c0a1-4154-8ca3-3a0d11cf121a": "projects/passepartout/architecture/design/the-symbolic-engine/the-gate-to-fact-bootstrap-extracting-the-first-ontology-from-code.org",
|
||||||
"0a4e0b8f-25e0-4b78-9633-fc37d03cefe9": "ideas/asset-protection-structures.org",
|
"64be38aa-56ca-4960-92e1-f3fc4cb51a2e": "projects/passepartout/architecture/design/the-symbolic-engine/abstract-fact-store-interface-modular-by-design.org",
|
||||||
"13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70": "ideas/self-driving-lisp-machine.org",
|
"02798a39-c12b-4835-bc61-34f57a860cdb": "projects/passepartout/architecture/design/the-symbolic-engine/the-llm-as-proposer-verified-extraction.org",
|
||||||
"84a537b4-4256-50c8-91f5-dd5b4538418f": "ideas/verification-appliance.org",
|
"7cb7df45-982f-4f5a-afee-36cd5595c25c": "projects/passepartout/architecture/design/the-symbolic-engine/_index.org",
|
||||||
"5f55bbe6-d243-5766-8ccf-5c5cc88a6542": "ideas/ai-industry-impact.org",
|
"4fa7eb38-6bc0-4809-9d8a-77290760ea79": "projects/passepartout/architecture/design/the-two-brains/_index.org",
|
||||||
"c652688a-1ea0-487c-9222-00e954efe8a1": "ideas/competitors/hermes-agent.org",
|
"76d92677-1eb0-4a3a-bee7-561874841e45": "projects/passepartout/architecture/design/the-two-brains/the-dispatcher-as-learning-system.org",
|
||||||
"e929ff32-28d8-4a29-bf74-d55babc040d1": "ideas/competitors/codex-cli.org",
|
"dd9d7e5a-dd75-4762-8c31-f312de9c6585": "projects/passepartout/architecture/design/the-two-brains/core-knowledge-the-four-pillars-of-agentic-reliability.org",
|
||||||
"416bab7c-4300-4d50-838a-5c7a8ad45d96": "ideas/competitors/thoth.org",
|
"3d25a808-d623-42fb-a054-15fb28cd464b": "projects/passepartout/architecture/design/validation/historical-lineage-mccarthys-advice-taker.org",
|
||||||
"85ca69dd-d085-4a55-ad11-021910b1f82e": "ideas/competitors/openclaw.org",
|
"4c65fdbb-a45c-4c71-ac29-6488e9271f4a": "projects/passepartout/architecture/design/validation/marcus-2020-the-case-against-pure-deep-learning.org",
|
||||||
"7a060b36-36db-4eb7-b8cc-844bd6ac9d36": "ideas/competitors/opencode.org",
|
"e66a5d5f-70ff-4953-93c3-569e05eaff73": "projects/passepartout/architecture/design/validation/_index.org",
|
||||||
"c3aab2e8-7e43-4abc-93f0-741675cfd78c": "ideas/competitors/aider.org",
|
"2e7d9fe6-6e78-41a0-96ad-b07777275d23": "projects/passepartout/architecture/design/validation/the-competitive-argument.org",
|
||||||
"512dd121-2292-4f3d-ac53-31bf3d12a60f": "ideas/competitors/claude-code.org",
|
"ec267c73-4e0d-4efb-9497-cb72f74538e4": "projects/passepartout/architecture/design/validation/gaur--sheth-2023-crest-trustworthy-neurosymbolic-ai.org",
|
||||||
"22d0a159-68a2-4587-9375-5046beddc20c": "ideas/competitors/continue.org",
|
"a56c8e07-9e5b-4070-a0f9-280188ccd6b7": "projects/passepartout/architecture/design/validation/sheth-et-al-2022-knowledge-infused-learning.org",
|
||||||
"8d73ccb9-34e4-4899-b0c3-605998e9bebc": "ideas/competitors/gemini-cli.org",
|
"b572b3a0-0238-470f-9bf8-63d356f68fe0": "projects/passepartout/architecture/design/knowledge-sources/empirical-validation-momo-and-modular-ontology-engineering.org",
|
||||||
"0f949f6c-4cf1-49eb-b9a4-ebcac27ee548": "ideas/agora/agora-requirements-05-social.org",
|
"bc537cf8-5ac8-46b9-a625-1d4f678ee9fc": "projects/passepartout/architecture/design/knowledge-sources/_index.org",
|
||||||
"2cace571-76bb-4c34-a5f4-68bc20b2e884": "ideas/agora/agora-requirements-10-user-journey.org",
|
"617a1031-495d-438c-a8e8-6e066b364e41": "projects/passepartout/architecture/design/implementation-properties/_index.org",
|
||||||
"df02cddc-944a-4bcd-8ef5-f080870d5f49": "ideas/agora/agora-requirements-08-library.org",
|
"2e3e576e-8839-4566-bae1-f40137428bb9": "projects/passepartout/architecture/design/implementation-properties/the-provenance-chain-as-product.org",
|
||||||
"90484f4a-5b70-4001-93d6-e610e54ed573": "ideas/agora/agora-requirements-06-exchange-and-contracts.org",
|
"7dee11bc-72b0-43a3-9bc8-2f022b59ba49": "projects/passepartout/architecture/design/foundation/homoiconicity-as-foundation.org",
|
||||||
"72570648-d943-42e5-a781-3b09791ac6ec": "ideas/agora/agora-requirements-11-assessment.org",
|
"1076101b-6201-4461-81e5-38d7886b66af": "projects/passepartout/architecture/design/foundation/the-unified-memory-argument.org",
|
||||||
"6fe67db6-25bd-4d11-bd1d-b44ec809e858": "ideas/agora/agora-requirements-02-identity.org",
|
"4bf2264c-db97-4d7b-9972-5a5d052d80be": "projects/passepartout/architecture/design/foundation/org-mode-as-unified-ast.org",
|
||||||
"f6cfc54b-919b-4311-bcbf-65e976755d40": "ideas/agora/agora-requirements-04-the-primitive.org",
|
"92e314a1-a650-4878-958a-9646aef4e032": "projects/passepartout/architecture/design/foundation/one-single-agent.org",
|
||||||
"8b4e0cec-a7b0-4e75-a1e3-c55ae820eb6d": "ideas/agora/agora-requirements-09-implementation.org",
|
"2c880b7d-e97f-459a-88d1-61fac760a0dd": "projects/passepartout/architecture/design/foundation/_index.org",
|
||||||
"68ffa49f-f0d8-42cf-8b69-ae69de8bb815": "ideas/agora/agora-requirements-10-governance-and-assets.org",
|
"bffb1695-5bf5-4434-8f64-e74f19d2e537": "projects/passepartout/architecture/design/engineering-infrastructure/the-mcp-strategy.org",
|
||||||
"a3243dd0-3209-423b-98e1-51c3eada2658": "ideas/agora/agora-requirements-07-advanced-integration.org",
|
"876fe3af-80fb-42dc-a0d0-714670e5b964": "projects/passepartout/architecture/design/engineering-infrastructure/token-economics-and-performance-advantage.org",
|
||||||
"3b43a9b8-31d1-4479-a35f-22273b74f0c7": "ideas/agora/agora-requirements-03-infrastructure.org",
|
"3f4573b2-aa55-44a7-a6c8-861dc443ac32": "projects/passepartout/architecture/design/engineering-infrastructure/definite-description-resolution.org",
|
||||||
"b25bf753-9799-41ab-82f5-1a1416db756b": "ideas/agora/agora-requirements-01-overview.org",
|
"a6dd0808-4366-4bda-be6e-f6d43f2eeab8": "projects/passepartout/architecture/design/engineering-infrastructure/the-evaluation-harness.org",
|
||||||
"10289e64-a4ff-4c34-828f-f3a9c769b73d": "ideas/agora/agora-requirements-00-readme.org",
|
"bf3f84da-358b-4d87-bc1a-fa91d1994e20": "projects/passepartout/architecture/design/engineering-infrastructure/the-cybernetic-loop-why-the-metabolic-pipeline-works.org",
|
||||||
"558154ea-e63a-4c45-998c-26ce8588585b": "ideas/compliance/first-mover-window.org",
|
"e6269aec-ea0a-406e-8b44-9dbd7b38c83a": "projects/passepartout/architecture/design/engineering-infrastructure/literate-programming-as-discipline.org",
|
||||||
"b852ec69-0fc2-435c-ae1e-6b83e49b3ca3": "ideas/compliance/appi.org",
|
"3747ae5f-b4e5-4503-b397-a5b07862062d": "projects/passepartout/architecture/design/engineering-infrastructure/local-first-architecture.org",
|
||||||
"e777064d-9950-42d5-980d-8c78cda91500": "ideas/compliance/pipa.org",
|
"9e9950a8-82a5-42db-af2d-742ba09ff8ed": "projects/passepartout/architecture/design/engineering-infrastructure/time-awareness-as-a-structural-advantage.org",
|
||||||
"e2ab887d-9f28-4da6-8388-e6c035e9d9c5": "ideas/compliance/iso-27001.org",
|
"7e575c8d-aa28-4588-bfa1-5f6144165a13": "projects/passepartout/architecture/design/engineering-infrastructure/_index.org",
|
||||||
"4a2bc62b-3f21-4212-9cd9-f9add8fc0be1": "ideas/compliance/glba.org",
|
"ee527687-28e2-4f0f-8d3c-af5cc531e3d4": "projects/passepartout/architecture/design/engineering-infrastructure/observability-and-the-thought-trace.org",
|
||||||
"03ebdb80-a9af-4e76-a443-8556424996ed": "ideas/compliance/fatf.org",
|
"c47b80ec-2cf2-44ce-9781-96c14498669d": "projects/passepartout/architecture/design/safety-self-preservation/type-level-gates-structural-safety-from-self-modification.org",
|
||||||
"e6993701-3c67-49bf-82f3-06907572cbf3": "ideas/compliance/fedramp.org",
|
"7e2f0f84-c2ad-4036-b2ba-0630776c73c8": "projects/passepartout/architecture/design/safety-self-preservation/layered-signal-authentication-trust-in-the-pipe.org",
|
||||||
"7f46764b-47b8-4892-a526-2c1b9ee6e6df": "ideas/compliance/irap.org",
|
"f74cb007-58a7-494f-93b7-a0fdf4b9f052": "projects/passepartout/architecture/design/safety-self-preservation/_index.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"
|
|
||||||
}
|
}
|
||||||
21
_index.org
21
_index.org
@@ -5,21 +5,14 @@
|
|||||||
#+title: Brain
|
#+title: Brain
|
||||||
#+filetags: :index:navigation:
|
#+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.
|
Personal knowledge base — projects, ideas, and concepts.
|
||||||
|
|
||||||
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.
|
** Projects
|
||||||
|
|
||||||
**Sections:**
|
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][CL Modernization]] — bringing Common Lisp forward by 25 years: build system, LSP, standard library, and a verified prover for a self-improving Lisp machine.
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout]] — a verifiable personal intelligence: self-bootstrapping Lisp machine, gate-verified reasoning, social protocol. Architecture, staged roadmap, strategy, competitive analysis, compliance landscape.
|
||||||
|
- [[id:1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b][Flags]] — legal structures: entity types, jurisdictional analysis, asset protection, practical setup guides.
|
||||||
|
|
||||||
- [[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
|
** Ideas and concepts
|
||||||
- [[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:329a30cd-55fb-496d-a60b-91388c211bba][Ideas]] — cross-domain frameworks, in-depth analysis, reference material, and thinking tools.
|
||||||
|
|
||||||
- [[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
|
|
||||||
|
|||||||
@@ -6,4 +6,14 @@
|
|||||||
#+title: Ideas
|
#+title: Ideas
|
||||||
#+filetags: :index:
|
#+filetags: :index:
|
||||||
|
|
||||||
Section index for ideas. Browse by file.
|
Cross-domain concepts, speculative analysis, and architectural thinking for the Passepartout project.
|
||||||
|
|
||||||
|
**Earlier ideas:**
|
||||||
|
|
||||||
|
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as Proof of the Lisp Model]] — biological systems as evidence for Lisp architecture
|
||||||
|
- [[id:dddd52a7-adb8-470e-a459-614ade5f76af][Closing the Lisp Gap]] — performance and ecosystem gaps between Lisp and C/Rust, and how Passepartout closes them
|
||||||
|
- [[id:85f963a7-a10f-45cc-ace6-6edfeefee762][Lisp, Provers, and vs Rust]] — Lisp vs Rust analysis, prover architecture, HOL bootstrap, comparison with Lean
|
||||||
|
- [[id:be9bccc7-5adf-4d0d-8ee4-8855892189bf][Neurosymbolic Loop Architectures]] — how neurosymbolic systems loop between symbolic reasoning and neural learning
|
||||||
|
- [[id:d2722576-fc9b-4bd3-bc2f-f5692b561b4e][Who Is Closest to Passepartout?]] — nearest-neighbor analysis of related projects
|
||||||
|
- [[id:3129eae6-f9f2-40fe-a419-8c1af728c86d][Faster Theorem Proving]] — engineering approaches to making formal verification practical
|
||||||
|
- [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][Orders of Magnitude — Time]] — a time-scale framework for Passepartout's roadmap and development cycle
|
||||||
|
|||||||
@@ -1,194 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 57f9538a-6270-4302-8d07-d742168419eb
|
|
||||||
:ID: alternative-growth-social-first
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Alternative Growth — Social-First Scenario
|
|
||||||
#+filetags: :passepartout:growth:strategy:alternative:
|
|
||||||
|
|
||||||
The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. The triad components (Logos, [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]], [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]) are the same; the order of operations and the primary growth levers differ fundamentally.
|
|
||||||
|
|
||||||
* Why This Path Exists
|
|
||||||
|
|
||||||
The institution-first scenario ([[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.
|
|
||||||
|
|
||||||
Historical precedent: Instagram was a check-in app with filters. The camera and social graph came first; the advertising platform came later. Twitter was SMS broadcast; the real-time news network was emergent. In each case the product that users wanted had a different shape than the product that ultimately captured value.
|
|
||||||
|
|
||||||
* Phase 0: Unified Digital Existence Layer (0 → 10K users, 3-12 months)
|
|
||||||
|
|
||||||
The key premise: the Agora is not an identity product. It is four layers in one — a publishing network, a contract platform, a payment network, and decentralized infrastructure — all unified under a single identity. No product on the market offers this combination. ENS is names only. Bluesky is social only. Stripe is payments only. The Agora replaces all of them with one provable layer.
|
|
||||||
|
|
||||||
Customer: Anyone who touches more than one of these layers today and feels the friction of managing separate accounts, separate reputations, and separate data silos. The most likely first adopters:
|
|
||||||
- Creators who publish across platforms and want verified ownership of their content
|
|
||||||
- Freelancers and contractors who send invoices, sign agreements, and manage multiple identities
|
|
||||||
- Crypto-natives who understand self-sovereignty but are tired of blockchain UX
|
|
||||||
- Developers building agents that need a persistent identity, payment channel, and data store
|
|
||||||
|
|
||||||
The /minimum viable Agora/ must ship all four layers at Phase 0. Not fully featured, but functional — enough that a user can register, publish a signed post, send a payment, and sign a simple contract using one identity. The value is in the unification: one account replaces four.
|
|
||||||
|
|
||||||
Growth lever: Multi-vector network effects. The Agora grows not on a single curve but on four simultaneous curves:
|
|
||||||
1. Publishing: each new creator attracts readers, who may become creators
|
|
||||||
2. Payments: each new payment user creates liquidity that makes the network more useful for everyone
|
|
||||||
3. Contracts: each new contract written on the Agora creates a template and a precedent
|
|
||||||
4. PDS: each new PDS increases the federation surface and the [[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.
|
|
||||||
|
|
||||||
Tactics:
|
|
||||||
|
|
||||||
1. /Entry point optimization./ Ship all four layers but actively measure which one drives signups in each channel. If a blog post about "verified publishing" drives 10× more signups than a post about "decentralized identity," double down on publishing. The platform is unified enough that users who join for one reason discover the other three.
|
|
||||||
|
|
||||||
2. /Creator tools./ Offer a one-click "publish with provenance" widget. A creator writes on Substack, Medium, or their own blog, pastes the Agora embed, and every post is automatically signed and timestamped. Readers see a blue checkmark that links to the Agora attestation. This is a /better/ blue checkmark than Twitter's because it's cryptographically verifiable — and it works /across/ platforms.
|
|
||||||
|
|
||||||
3. /Freelancer onboarding./ Ship an invoice-and-contract template: "Send a verified invoice. Get a signed contract. Get paid on the Agora." The freelancer registers once, and their invoices, contracts, and payment history are provably theirs. This is a /productivity tool/ first and a social network second — users join to get paid, stay because their professional reputation is on it.
|
|
||||||
|
|
||||||
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 [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow.
|
|
||||||
|
|
||||||
Revenue:
|
|
||||||
| Stream | Year 1 target | Mature |
|
|
||||||
|--------+--------------+--------|
|
|
||||||
| Payment processing fees (0.5-2%) | $100K-1M | $10-50M/yr |
|
|
||||||
| PDS hosting subscriptions | $50K-200K | $1-3M/yr |
|
|
||||||
| Marketplace contract commissions | $20K-100K | $5-20M/yr |
|
|
||||||
| Premium username auctions | $50K-300K | $2-5M/yr |
|
|
||||||
| Creator tools (Pro tier) | $50K-200K | $2-10M/yr |
|
|
||||||
| Total | $270K-1.8M | $20-88M/yr |
|
|
||||||
|
|
||||||
The fees are the key difference from my earlier estimate. The Agora's payment and contract layers generate revenue /per transaction/ without requiring subscription growth. A user who never pays for PDS hosting still generates fees if they send a payment or sign a contract on the network.
|
|
||||||
|
|
||||||
Key metric: Platform usage across any of the four layers. Fee volume (total value processed through payments + contracts). Not DAU — a user who joins for payments and never publishes is still generating revenue.
|
|
||||||
|
|
||||||
Failure mode: The unified platform is harder to explain than a single-purpose product. "One account for identity, publishing, payments, and contracts" sounds like a pitch deck, not a product. The risk is that the /scope/ of the Agora makes it incomprehensible — users don't know what problem it solves because it solves too many. The mitigations: optimize for a single entry vector per channel, let users discover the others naturally.
|
|
||||||
|
|
||||||
* Phase 1: Network Effects — The Social Graph (10K → 1M users, 1-3 years)
|
|
||||||
|
|
||||||
Customer: The early adopter base expands to include privacy-conscious mainstream users. The trigger is a /platform failure event/: a major platform bans a creator, de-platforms a community, or suffers a data breach. When that happens, the Agora is ready — it offers the same social primitives (messaging, identity, publishing) but with ownership.
|
|
||||||
|
|
||||||
Growth lever: Metcalfe's law + switching cost. Each new user makes the network more valuable. But the real lock-in is the /reputation graph/: attestations, signatures, and data provenance are cumulative. A user with 3 years of verified activity on the Agora cannot replicate that on any other platform. The switching cost grows with time.
|
|
||||||
|
|
||||||
Tactics:
|
|
||||||
|
|
||||||
1. Ship verified messaging. Every message between Agora users is signed and timestamped. No third party can modify or delete it. The product pitch: /Twitter, but your tweets are yours, and nobody can rewrite history/.
|
|
||||||
|
|
||||||
2. Publish an attestation API. Third-party services (news outlets, marketplaces, social platforms) can query the Agora to verify a user's reputation. News comments show "verified human, 2yr history, no abuse flags." This creates /outbound value/ — the network becomes useful to people who aren't even on it.
|
|
||||||
|
|
||||||
3. Offer PDS-to-PDS federation. Agora instances communicate directly. No central server. This differentiates from every centralized platform and gives a structural privacy advantage that no amount of VC funding can replicate.
|
|
||||||
|
|
||||||
4. Introduce data licensing. Users can license their verified data to AI training companies, researchers, advertisers — on their own terms, with their own price. The Agora takes a 10-15% commission. This creates a /revenue share/ that users understand viscerally. Compare: X/Twitter makes billions selling user data and gives nothing back. Agora users get paid.
|
|
||||||
|
|
||||||
5. Verification becomes visible. Each user's profile shows a "verification score" based on the length and depth of their attested history. Long-time users get a visible badge. This creates status competition around the /one thing nobody else can offer/: provable history.
|
|
||||||
|
|
||||||
Revenue:
|
|
||||||
| Stream | Year 3 target | Mature |
|
|
||||||
|--------+--------------+--------|
|
|
||||||
| PDS hosting subscriptions | $500K-2M | $10-50M/yr |
|
|
||||||
| Data licensing commissions | $200K-1M | $20-100M/yr |
|
|
||||||
| Premium username renewals | $100K-500K | $5-10M/yr |
|
|
||||||
| Verified badge program | $100K-300K | $2-5M/yr |
|
|
||||||
| Attestation API (per-query) | $50K-200K | $5-20M/yr |
|
|
||||||
| Total | $1-4M | $42-185M/yr |
|
|
||||||
|
|
||||||
Key metric: Daily active PDS users. Inter-instance messages per day. Attestation API queries.
|
|
||||||
|
|
||||||
Failure mode: Network effects fail to trigger because the user experience is not /better/ than existing platforms — it's /different/. Different is not enough. The product must match or exceed the UX of mainstream social platforms while offering the ownership advantage. If the UX gap is too large, users stay on Twitter/Bluesky/Threads despite the privacy cost.
|
|
||||||
|
|
||||||
* Phase 2: The Institution Crossover (1M → 10M users, 2-5 years)
|
|
||||||
|
|
||||||
Customer: At 1M+ active identities, the network has critical mass. Institutions (universities, media companies, government agencies, enterprises) can no longer ignore it because /their users are on it/. The crossover happens organically: a university registrar wants to issue verified credentials. A newsroom wants to publish with verified provenance. A regulator wants to use the Agora's attestation infrastructure because it already has users.
|
|
||||||
|
|
||||||
Growth lever: Institutional network effects. Every institution that joins brings 10K-100K users with it (employees, students, customers). Each new institutional user increases the value of verification for everyone else. The growth curve becomes logistic with institutional jumps, not smooth organic growth.
|
|
||||||
|
|
||||||
Tactics:
|
|
||||||
|
|
||||||
1. Ship the Stoa enterprise bundle (SSO, compliance reports, fleet management, audit logging). This was the /entire/ Phase 0-1 of the institution-first scenario. Here it is a Phase 2 feature — built to serve institutions that are already /inside/ the network, not sold to cold prospects.
|
|
||||||
|
|
||||||
2. Offer verified credentialing: degrees, certifications, professional licenses, issued on the Agora, verifiable by anyone. The institution pays for the issuance. The graduate gets a portable, provable credential.
|
|
||||||
|
|
||||||
3. Offer provenance publishing: news organizations publish articles signed by their Agora identity. Readers verify provenance in one click. Deepfakes and misinformation are detectable because the authentic source is attested. This creates a /consumer pull/ for verification that never existed in the institution-first scenario.
|
|
||||||
|
|
||||||
4. Verification appliances are now a /fulfillment order/, not a sales pitch. Institutions already inside the network ask: "Can we run our own instance?" The answer is yes — here is a Stoa appliance. The gate rule SDK is a value-up, not a product.
|
|
||||||
|
|
||||||
5. The compute marketplace activates naturally. With 10M+ users and thousands of institutions, compute supply and demand are both present without bootstrapping.
|
|
||||||
|
|
||||||
Revenue:
|
|
||||||
| Stream | Year 5 target | Mature |
|
|
||||||
|--------+--------------+--------|
|
|
||||||
| Enterprise Stoa seats | $5-20M | $50-200M/yr |
|
|
||||||
| Verified credential issuance | $2-10M | $20-100M/yr |
|
|
||||||
| Compute marketplace fees | $1-5M | $50-200M/yr |
|
|
||||||
| PDS hosting (scaled) | $2-10M | $20-50M/yr |
|
|
||||||
| Data licensing (scaled) | $1-5M | $20-100M/yr |
|
|
||||||
| Verification appliances | $2-10M | $50-100M/yr |
|
|
||||||
| Total | $13-60M | $210-750M/yr |
|
|
||||||
|
|
||||||
Key metric: Institutional join events. Enterprise Stoa subscriptions. Credentials issued.
|
|
||||||
|
|
||||||
Failure mode: The institution crossover never comes because the social graph stalls at 1M users — enough for a niche, not enough for critical mass. The network becomes a high-quality-but-small community like early App.net or Mastodon. Verification is real but irrelevant because the rest of the world is on different platforms. The institution-first scenario is still possible from here (direct enterprise sales), but the supposed advantage of "users first" has not materialized.
|
|
||||||
|
|
||||||
* Phase 3: Default Infrastructure (10M → 1B+, 5-15 years)
|
|
||||||
|
|
||||||
Customer: At this scale, the Agora is the default identity and communication layer for a significant fraction of internet users. New users join because /everyone is there/. Institutions join because /everyone is there/. The regulatory capture that the institution-first scenario required as a /growth lever/ happens here as a /consequence/ — regulators adopt Agora attestation because it is the standard.
|
|
||||||
|
|
||||||
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 — [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat:
|
|
||||||
|
|
||||||
- Institution-first moat: regulatory lock-in. You comply because the law requires it.
|
|
||||||
- Social-first moat: installed-base lock-in. You join because everyone is there.
|
|
||||||
|
|
||||||
The regulatory moat is faster to deploy but brittle (a change in government can undo it). The installed-base moat is slower to build but self-reinforcing.
|
|
||||||
|
|
||||||
Revenue: Same end state as growth-strategy.org Phase 3 — $1B+ across certification, infrastructure rent, marketplace fees, and insurance underwriting.
|
|
||||||
|
|
||||||
* Comparison: Two Paths Side By Side
|
|
||||||
|
|
||||||
| Dimension | Institution-first | Social-first |
|
|
||||||
|-----------+------------------+-------------|
|
|
||||||
| First customer | CISO, compliance buyer | Creators, devs, payment users |
|
|
||||||
| First revenue | $2-12M (year 1) | $500K-3M (year 1) |
|
|
||||||
| Time to $10M ARR | 12-24 months | 2-4 years |
|
|
||||||
| Time to $50M ARR | 2-4 years | 4-7 years |
|
|
||||||
| Time to $1B+ | 5-15 years | 8-20 years |
|
|
||||||
| Capital requirement | Low (revenue-funded) | Low-Moderate (fees fund growth) |
|
|
||||||
| Marketing cost | Sales team + compliance mktg | Community + product-led growth |
|
|
||||||
| Key execution skill | Enterprise sales | Consumer product + platform design |
|
|
||||||
| Network effect trigger | Developer SDK (Phase 1) | Multi-vector: any of 4 layers |
|
|
||||||
| Phase 0 offer | Compliance report | Unified identity + pub + pay + contract |
|
|
||||||
| Moat type | Regulatory + insurance | Installed base + attestation |
|
|
||||||
| Moat durability | Good (legal) | Strong (practical) |
|
|
||||||
| Entry vectors | One: compliance pain | Four: publishing, payments, contracts, ownership |
|
|
||||||
| Failure mode | Wrong pricing, too early | Any vector stalls — but all 4 must |
|
|
||||||
|
|
||||||
* Assessment: Which Is More Likely?
|
|
||||||
|
|
||||||
I initially assessed institution-first as significantly more likely. The unified-layer correction narrows the gap considerably. Here is the revised assessment:
|
|
||||||
|
|
||||||
The social-first path's strongest argument — which I dismissed too quickly — is that the Agora is not competing with any single product. A competitor who beats it on publishing (Substack, Medium) cannot also beat it on payments (Stripe, PayPal) and contracts (DocuSign, LexisNexis) and identity management — simultaneously. The unification is not a feature; it is the structural advantage. Each layer reinforces the others, and competing against the whole stack requires matching all four, which no existing product does.
|
|
||||||
|
|
||||||
The multi-vector growth also matters. The institution-first path has one entry vector (compliance pain) and one failure mode (wrong pricing or too early). The social-first path has four entry vectors, and any one of them reaching PMF carries the other three. The probability that publishing /or/ payments /or/ contracts /or/ identity ownership finds product-market fit is higher than the probability that any single one does. The failure requires /all four/ to fail simultaneously — a smaller target.
|
|
||||||
|
|
||||||
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 [[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.
|
|
||||||
|
|
||||||
My updated assessment: the institution-first path is still higher probability, but not by the wide margin I initially claimed. The gap is narrower because the Agora as a unified layer is genuinely unprecedented. If the team can hire consumer product talent (or one founder has that skill), the social-first path becomes competitive.
|
|
||||||
|
|
||||||
The hybrid path may be the strongest: ship the four-layer Agora as a public platform /alongside/ the enterprise compliance sales. Let payments, publishing, and contracts grow organically while institutions fund the operation. The enterprise revenue buys time for the consumer product to find PMF. The consumer platform gives the enterprise pitch credibility ("we have 1M users") that pure enterprise sales cannot match. Neither path needs to be chosen — both can run in parallel as long as the enterprise revenue covers the burn.
|
|
||||||
|
|
||||||
* References
|
|
||||||
|
|
||||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Primary growth strategy — institution-first]]
|
|
||||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams by component]]
|
|
||||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform details]]
|
|
||||||
- [[id:528a0f6c-6fd6-41ed-9d59-237958bdaef2][Effects and growth as interleaved curves]]
|
|
||||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline — Phase Zero and End State]]
|
|
||||||
|
|
||||||
#+begin_quote
|
|
||||||
The social-first path is attractive because the end state is stronger. But the path to it requires building a consumer product alongside the deep-tech verification infrastructure — essentially running two startups in parallel. The [[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
|
|
||||||
@@ -1,221 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f
|
|
||||||
:ID: competitive-landscape-agora
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Agora Competitive Landscape
|
|
||||||
#+filetags: :passepartout:agora:competitive:strategy:landscape:
|
|
||||||
|
|
||||||
The Agora is a decentralized social operating system that replaces the entire centralized internet platform stack: every function that currently runs on Facebook, Twitter, Instagram, YouTube, TikTok, Reddit, Medium, Substack, OnlyFans, Pornhub, WhatsApp, Signal, Telegram, Discord, LinkedIn, eBay, Etsy, GitHub, DocuSign, Stripe, and Google/Apple ID — all through one unified identity, one data model (the Note), one communication protocol (DIDComm), one payment rail (Lightning), and one contract layer (SCAL).
|
|
||||||
|
|
||||||
There is no single competitor. The competition is the /category/ of centralized internet platforms and the psychological status quo of managing 15+ separate accounts.
|
|
||||||
|
|
||||||
This page maps every platform the Agora replaces, organized by domain, with the specific Agora capability that makes the replacement possible.
|
|
||||||
|
|
||||||
* Social Graph & Publishing
|
|
||||||
|
|
||||||
** Twitter/X
|
|
||||||
- *User need:* Broadcast short-form content, follow interesting people, real-time news
|
|
||||||
- *Agora replacement:* Feeds and streams via the Note primitive (`is_feed: true`), with Lens architecture for customizable curation. Follows are cryptographic subscriptions, not API-gated relationships.
|
|
||||||
- *Agora advantage:* No algorithmic manipulation, no ads, no shadowbanning. Users choose their Feed Generators via the Algorithm Marketplace. Portable social graph — follows are signed Notes, not a database row.
|
|
||||||
- *Migration:* Twitter archive import for followed accounts.
|
|
||||||
|
|
||||||
** Facebook / Meta
|
|
||||||
- *User need:* Social graph, family/friend connections, event management, groups
|
|
||||||
- *Agora replacement:* Collective Personas for groups, DID-based social graph (not platform-controlled), Persona isolation for work/personal/family
|
|
||||||
- *Agora advantage:* No central feed algorithm that optimizes for engagement over well-being. Portable identity — your social graph leaves the platform when you do. No data mining.
|
|
||||||
- *Timing:* Year 3+ after network effects. Facebook's moat is the largest social graph; Agora's Persona system makes it portable by design.
|
|
||||||
|
|
||||||
** Instagram
|
|
||||||
- *User need:* Visual content sharing, photo feeds, stories
|
|
||||||
- *Agora replacement:* Visual Notes with `content_type: image/*`. Lens architecture renders them through an "Instagram-style" grid or a "Pinterest-style" discovery view depending on user-selected Lens.
|
|
||||||
- *Agora advantage:* User-chosen discovery algorithm. No engagement-maximized feed. Content is not manipulated for ad placement.
|
|
||||||
|
|
||||||
** LinkedIn
|
|
||||||
- *User need:* Professional identity, job market, professional networking
|
|
||||||
- *Agora replacement:* Professional Persona (unlinkable from personal), Aletheia Portfolio (static site published natively to the network), Contract Notes for hiring/service agreements
|
|
||||||
- *Agora advantage:* Portable professional reputation — not locked to a platform. Verified work history via signed Notes. Direct hiring without platform intermediation fees.
|
|
||||||
|
|
||||||
** Reddit / Forums (phpBB, vBulletin)
|
|
||||||
- *User need:* Community discussion, Q&A, interest-based groups
|
|
||||||
- *Agora replacement:* Social Spaces with Collective Personas, pluggable feed generation, competitive labeling for moderation
|
|
||||||
- *Agora advantage:* Sovereign moderation (users choose their Labelers), portable identity across communities, no censorship risk. Communities can fork if the Collective governance fails.
|
|
||||||
- *Migration:* Import subscribed subreddits.
|
|
||||||
|
|
||||||
** Medium / Substack
|
|
||||||
- *User need:* Long-form publishing, subscription-based content, creator monetization
|
|
||||||
- *Agora replacement:* Feed Notes (`is_feed: true`) with paywalled content via LSAT protocol (Lightning Service Authentication Tokens). Subscriptions are streaming Lightning payments.
|
|
||||||
- *Agora advantage:* Near-zero platform fees (relay costs only). Content ownership — readers subscribe to the creator's DID, not to a platform. No censorship risk.
|
|
||||||
- *Strategic target:* Phase 1 platform replacement.
|
|
||||||
|
|
||||||
* Video & Audio
|
|
||||||
|
|
||||||
** YouTube
|
|
||||||
- *User need:* Video hosting, discovery, comments, monetization
|
|
||||||
- *Agora replacement:* Video Notes (`content_type: video/*`) viewed through a "YouTube Lens" (displaying comments via `reply_to` and related videos). The exact same Note can be viewed through an "Educational Lens" or "Podcast Lens."
|
|
||||||
- *Agora advantage:* No algorithm that optimizes for watch time over well-being. Lens architecture lets users choose discovery logic. Content monetized via LSAT + Seeder Rewards — creators earn directly, and bandwidth providers (seeders) earn micro-rewards.
|
|
||||||
|
|
||||||
** TikTok
|
|
||||||
- *User need:* Short-form vertical video, discovery algorithm
|
|
||||||
- *Agora replacement:* Short-duration video Notes trigger a "TikTok-style" vertical scroll and auto-play in the UI when `content_type: "video/mp4"` and duration is short.
|
|
||||||
- *Agora advantage:* The "For You" algorithm is a user-chosen Lens, not a platform-controlled black box. No engagement-extremification.
|
|
||||||
|
|
||||||
** Podcasts / Audio
|
|
||||||
- *User need:* Audio content, background play
|
|
||||||
- *Agora replacement:* Audio Notes (`content_type: audio/mpeg`) viewed through a "Podcast Lens" with 1.5x speed and background play. Same Note can be listened to or watched depending on Lens.
|
|
||||||
|
|
||||||
* Messaging & Communication
|
|
||||||
|
|
||||||
** WhatsApp / Signal / Telegram
|
|
||||||
- *User need:* Private messaging, group chats, voice/video calls, encryption
|
|
||||||
- *Agora replacement:* DIDComm v2 for transport, Double Ratchet Algorithm (Signal Protocol) for Perfect Forward Secrecy, WebRTC for voice/video with decentralized signaling via DIDComm. PDS acts as encrypted mailbox proxy.
|
|
||||||
- *Agora advantage:* Multi-persona isolation — Work DID and Personal DID have separate message queues that never mix. Onion routing for metadata privacy. Off-the-Record mode for ephemeral interactions. No central server controlling the directory.
|
|
||||||
|
|
||||||
** Discord / Slack
|
|
||||||
- *User need:* Community chat, voice channels, collaboration
|
|
||||||
- *Agora replacement:* Social Spaces with Collective Personas. DIDComm-based group messaging. Governance modules (GEM) for roles, permissions, and moderation.
|
|
||||||
- *Agora advantage:* Server ownership is cryptographic, not corporate. Communities can fork. No per-seat pricing. Portable membership history.
|
|
||||||
|
|
||||||
** Email
|
|
||||||
- *User need:* Asynchronous messaging, identity, document delivery
|
|
||||||
- *Agora replacement:* Directed Notes (Copy-on-Send model). PDS as encrypted mailbox. The Note is a universal message format — no separate email protocol needed.
|
|
||||||
- *Agora advantage:* End-to-end encryption by default. Cryptographic sender verification (no phishing, no spoofing). No spam (relays only route to subscribed destinations). Attachments are CIDs, not MIME blobs.
|
|
||||||
|
|
||||||
** Zoom / Google Meet
|
|
||||||
- *User need:* Video conferencing, screen sharing
|
|
||||||
- *Agora replacement:* WebRTC over DIDComm signaling. P2P tunnel — no central server sees call data.
|
|
||||||
- *Agora advantage:* No Zoom-bombing (call is authenticated by DID). No platform listening in. No account required beyond your DID.
|
|
||||||
|
|
||||||
* E-Commerce & Marketplaces
|
|
||||||
|
|
||||||
** eBay / Etsy
|
|
||||||
- *User need:* Buy and sell goods, auction, fixed-price listings, dispute resolution
|
|
||||||
- *Agora replacement:* Contract Notes as product listings (Offer → Take model). HODL invoice escrow for payments. SCAL (Sovereign Contract & Arbitration Layer) for dispute resolution.
|
|
||||||
- *Agora advantage:* Fees below 5% (vs. 10-15%). Transparent reputation system based on DID history. No account bans. Multi-level arbitration (Local Elders → Guilds → Global Juries).
|
|
||||||
|
|
||||||
** OnlyFans / Patreon / Fansly
|
|
||||||
- *User need:* Subscription content, adult content, creator-direct monetization
|
|
||||||
- *Agora replacement:* Paywalled Notes via LSAT protocol. Streaming Lightning subscriptions. Encrypted content with Blind CDN seeding.
|
|
||||||
- *Agora advantage:* Censorship-resistant (no payment processor can cut you off). Near-zero platform fees. Pseudonymous by default. Adult content doesn't face the banking discrimination that existing platforms do.
|
|
||||||
- *Strategic target:* Phase 1 platform replacement (underserved, clear pain point).
|
|
||||||
|
|
||||||
** Pornhub / Adult content
|
|
||||||
- *User need:* Adult content hosting, discovery, monetization
|
|
||||||
- *Agora replacement:* Same Note primitive with `content_type: video/*`. LSAT for paywalled access. Blind CDN for distribution.
|
|
||||||
- *Agora advantage:* No centralized moderation that can delist creators. Lightning-native payments bypass banking discrimination. Privacy (identity not tied to consumption).
|
|
||||||
- *Strategic target:* Phase 1 platform replacement.
|
|
||||||
|
|
||||||
* Work & Collaboration
|
|
||||||
|
|
||||||
** GitHub / GitLab
|
|
||||||
- *User need:* Version control, code hosting, issues, pull requests, CI
|
|
||||||
- *Agora replacement:* Code is stored as Merkle DAGs of commit Notes. Issues and PRs are Contract Notes. Collective Personas own repositories.
|
|
||||||
- *Agora advantage:* Truly decentralized version control — no central repository host. Signed commits with DID. Smart contracts for bounty management (Lightning bounties).
|
|
||||||
|
|
||||||
** Google Docs / Office 365
|
|
||||||
- *User need:* Collaborative document editing, spreadsheets, presentations
|
|
||||||
- *Agora replacement:* Static pages (`is_feed: false`) with versioned CID history. Collaborative editing via Contract Notes defining access control.
|
|
||||||
- *Agora advantage:* Document history is immutable and verifiable. No platform lock-in.
|
|
||||||
|
|
||||||
** Project Management (Jira, Trello, Asana)
|
|
||||||
- *User need:* Task tracking, project management, team coordination
|
|
||||||
- *Agora replacement:* Tasks as Contract Notes in negotiation state. Status changes are signed state transitions.
|
|
||||||
- *Agora advantage:* Portable project history. Tasks are data you own.
|
|
||||||
|
|
||||||
** Upwork / Fiverr / Freelancer
|
|
||||||
- *User need:* Find freelancers, manage contracts, escrow payments
|
|
||||||
- *Agora replacement:* SCAL contracts for service agreements. HODL invoice escrow. Multi-level arbitration. Reputation tied to DID history.
|
|
||||||
- *Agora advantage:* Lower fees, portable reputation, no platform lock-in.
|
|
||||||
|
|
||||||
* Identity & Infrastructure
|
|
||||||
|
|
||||||
** Google / Apple ID
|
|
||||||
- *User need:* Single sign-on across the internet
|
|
||||||
- *Agora replacement:* DID-based authentication via Personas. No central identity provider. User controls which Persona is used for which service.
|
|
||||||
- *Agora advantage:* No surveillance (Google sees every SSO login). Granular persona isolation. No single point of failure.
|
|
||||||
|
|
||||||
** ENS (Ethereum Name Service)
|
|
||||||
- *User need:* Human-readable decentralized names
|
|
||||||
- *Agora replacement:* Agora naming registry with similar auction model. But integrated with PDS, messaging, contracts, and payments — a name in the Agora is a full identity, not just a pointer to a wallet.
|
|
||||||
- *Agora advantage:* Names come with native capabilities (PDS, messaging, contracts). ENS is names-only.
|
|
||||||
|
|
||||||
* The [[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 Real Competitor Is the Status Quo
|
|
||||||
|
|
||||||
The centralized internet works well enough for most people. The friction is spread across 20+ platforms — no single platform is bad enough to leave. The Agora's value proposition is not "Twitter but better" but "one account replaces every platform you use."
|
|
||||||
|
|
||||||
This is a harder sell because:
|
|
||||||
1. The status quo is familiar. Switching all 20+ platforms at once is cognitively overwhelming.
|
|
||||||
2. Network effects at each platform are entrenched. No single platform can be replaced without bringing the users.
|
|
||||||
3. The value of unification compounds with adoption — but requires critical mass to be visible.
|
|
||||||
|
|
||||||
** The Entry Vector Must Be a Niche, Not a Mass Market
|
|
||||||
|
|
||||||
The strategic documents recognize this explicitly. Phase 1 targets underserved communities with clear pain points:
|
|
||||||
- OnlyFans creators facing payment discrimination and censorship
|
|
||||||
- Reddit communities tired of centralized moderation
|
|
||||||
- Developers frustrated with platform lock-in
|
|
||||||
- Adult content platforms facing banking discrimination
|
|
||||||
- NGOs and guilds needing sovereign identity
|
|
||||||
|
|
||||||
Each of these communities has a /specific/ pain point that the Agora solves directly. The win condition is: a user joins for one reason (e.g., censorship-resistant adult content monetization) and discovers the other 19 capabilities as a free bonus.
|
|
||||||
|
|
||||||
** The Structural Advantage Is Unassailable
|
|
||||||
|
|
||||||
No centralized competitor can match the Agora's bundle:
|
|
||||||
- Meta cannot offer portable identity (it destroys their business model)
|
|
||||||
- Google cannot offer private messaging (it destroys their data model)
|
|
||||||
- Stripe cannot offer contracts and social (outside their competence)
|
|
||||||
- DocuSign cannot offer payments and publishing (outside their competence)
|
|
||||||
- The entire category of centralized platforms cannot offer user-owned data
|
|
||||||
|
|
||||||
The only way to compete with the Agora is to build a similar decentralized platform — and that requires matching all four layers (identity, publishing, payments, contracts) simultaneously. No decentralized project has done this. The closest (Farcaster) has identity and social but no payments or contracts. Bluesky has identity and social but no payments or contracts. Ethereum + ENS has identity, payments, and contracts but no social layer.
|
|
||||||
|
|
||||||
** The Risk Is Not Competition but Indifference
|
|
||||||
|
|
||||||
The Agora's biggest risk is not that a competitor builds a better product, but that the status quo friction is tolerable enough that users never switch. The centralized internet is bad — but it is familiar. The Agora is better — but unfamiliar.
|
|
||||||
|
|
||||||
The counterargument: this is true for every platform shift. Email was a worse experience than postal mail in 1992. The web was a worse experience than AOL in 1994. Instagram was a worse experience than Flickr in 2010. Each won because a /specific/ use case was dramatically better, and the rest of the ecosystem followed. The Agora must find its "camera with filters" moment — the one use case that is so clearly superior that users adopt it despite the rest of the ecosystem being immature.
|
|
||||||
|
|
||||||
* Comparison Summary
|
|
||||||
|
|
||||||
| Agora replaces | Incumbent | Agora advantage | Risk to Agora |
|
|
||||||
|----------------+-----------+----------------+---------------|
|
|
||||||
| Social graph | Facebook | Portable identity, no data mining | Facebook's 3B user moat |
|
|
||||||
| Microblogging | Twitter/X | Algorithm choice, no censorship | Network effects |
|
|
||||||
| Visual content | Instagram | No engagement-extremified algorithm | UX polish gap |
|
|
||||||
| Professional | LinkedIn | Portable rep, no platform fees | Professional network effects |
|
|
||||||
| Video | YouTube | Lens choice, Seeder Rewards | Content moderation surface |
|
|
||||||
| Short video | TikTok | Users choose the algorithm | Discovery algorithm sophistication |
|
|
||||||
| Forums | Reddit | Sovereign moderation, portable identity | Community migration inertia |
|
|
||||||
| Publishing | Medium/Substack | Near-zero fees, content ownership | Creator distribution |
|
|
||||||
| Messaging | WhatsApp/Signal | Multi-persona isolation, onion routing | Friend network effects |
|
|
||||||
| Community | Discord | Cryptographic ownership, forkable | Voice/UX maturity |
|
|
||||||
| E-commerce | eBay/Etsy | <5% fees, transparent reputation | Trust in new platform |
|
|
||||||
| Subscription | OnlyFans/Patreon | No payment discrimination | Creator acquisition cost |
|
|
||||||
| Video hosting | Pornhub | No censorship, Lightning payouts | Reputation risk |
|
|
||||||
| Code hosting | GitHub | Truly decentralized, DID-signed commits | Developer habit |
|
|
||||||
| Identity | Google/Apple ID | No surveillance, persona isolation | Convenience of SSO |
|
|
||||||
| Naming | ENS | Name + PDS + messaging + contracts | ENS's 2M domain moat |
|
|
||||||
| Collaboration | Google Docs | Verifiable history, no platform lock-in | Real-time collaboration UX |
|
|
||||||
| Freelance | Upwork/Fiverr | Lower fees, portable reputation | Liquidity of gig listings |
|
|
||||||
| Meetings | Zoom | P2P, no central server | Call quality/reliability |
|
|
||||||
|
|
||||||
* Conclusion
|
|
||||||
|
|
||||||
The Agora does not compete with any single platform. It offers an alternative to the /entire paradigm/ of centralized internet services. The competitive analysis is not about which platform to beat — it is about which /use case/ to lead with so that users adopt the unified platform despite the rest of the ecosystem being immature.
|
|
||||||
|
|
||||||
The OnlyFans/Patreon entry vector is the strongest Phase 1 play: a community with clear pain (payment discrimination, censorship), high willingness to pay, and low switching costs (creators want their audience independent of the platform). From there, publishing, messaging, and identity flow naturally.
|
|
||||||
|
|
||||||
* References
|
|
||||||
|
|
||||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora overview]] (brain docs)
|
|
||||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contract platform]]
|
|
||||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
|
||||||
- Agora Protocol Overview (spec repo)
|
|
||||||
- Social Space specification
|
|
||||||
- Exchange and Contracts specification
|
|
||||||
- User journey and platform replacement strategy
|
|
||||||
@@ -1,49 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 36e5b948-e07b-477f-9036-4dfe88254347
|
|
||||||
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:UPDATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Compliance Framework Mapping — Global Regulated Industries
|
|
||||||
#+filetags: :passepartout:triad:compliance:global:index:
|
|
||||||
|
|
||||||
This file has been split into atomic framework notes under [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]].
|
|
||||||
|
|
||||||
See [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] for the hub with per-framework links.
|
|
||||||
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] for timing.
|
|
||||||
See [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for pricing and TAM.
|
|
||||||
|
|
||||||
Each framework is its own file in [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]:
|
|
||||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]]
|
|
||||||
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]]
|
|
||||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
|
||||||
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]
|
|
||||||
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]]
|
|
||||||
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]]
|
|
||||||
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]]
|
|
||||||
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]]
|
|
||||||
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]
|
|
||||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
|
||||||
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]]
|
|
||||||
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]]
|
|
||||||
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]]
|
|
||||||
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]]
|
|
||||||
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]]
|
|
||||||
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]]
|
|
||||||
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]]
|
|
||||||
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]]
|
|
||||||
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act Australia]]
|
|
||||||
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]]
|
|
||||||
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]]
|
|
||||||
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]]
|
|
||||||
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD Brazil]]
|
|
||||||
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP Mexico]]
|
|
||||||
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]]
|
|
||||||
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]]
|
|
||||||
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]]
|
|
||||||
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF AML/CFT]]
|
|
||||||
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]]
|
|
||||||
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Privacy/AI]]
|
|
||||||
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]]
|
|
||||||
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]]
|
|
||||||
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]]
|
|
||||||
@@ -1,28 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 558154ea-e63a-4c45-998c-26ce8588585b
|
|
||||||
:ID: auto-first-mover-window
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: First-Mover Window Analysis
|
|
||||||
#+filetags: :passepartout:compliance:strategy:first-mover:
|
|
||||||
|
|
||||||
* First-Mover Window Analysis
|
|
||||||
|
|
||||||
The first-mover window is the time in which a new compliance tool can establish
|
|
||||||
dominance before incumbents respond or the market settles on a standard approach.
|
|
||||||
|
|
||||||
| Window | Frameworks | Rationale |
|
|
||||||
|--------|-----------|-----------|
|
|
||||||
| **Critical (<12 months)** | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] (Aug 2026 effective), [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Oct 2025 deadline), [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
|
|
||||||
| **Wide (12-36 months)** | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]; [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
|
|
||||||
| **Mature (commodity)** | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018), [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] (2002), [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] (1996), [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] (1999), [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] (2010), [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
|
|
||||||
| **Latent (undiscovered)** | [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] AI Principles, [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]], [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]], [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
These windows define which frameworks are worth building a gate package for
|
|
||||||
first. The [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] maps each to a
|
|
||||||
[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] gate package, and the
|
|
||||||
[[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] sizes the market. The
|
|
||||||
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] dynamics determine which window to enter
|
|
||||||
first.
|
|
||||||
@@ -1,67 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 81a815ee-bf2b-4365-9894-b814e4196850
|
|
||||||
:ID: auto-revenue-table
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Compliance Framework Revenue Table
|
|
||||||
#+filetags: :passepartout:compliance:revenue:pricing:
|
|
||||||
|
|
||||||
* Expanded Revenue Table
|
|
||||||
|
|
||||||
| Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
|
|
||||||
|-----------|--------|--------------|------------------|-------------------|---------------------|----------------|
|
|
||||||
| [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
|
|
||||||
| SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
|
|
||||||
| [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
|
|
||||||
| [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
|
|
||||||
| [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
|
|
||||||
| [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
|
||||||
| [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
|
||||||
| [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
|
|
||||||
| [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
|
|
||||||
| [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
|
|
||||||
| [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
|
|
||||||
| [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
|
|
||||||
| [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
|
|
||||||
| [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
|
|
||||||
| [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
|
|
||||||
| [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
|
|
||||||
| [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
|
|
||||||
| Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
|
|
||||||
| [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls |
|
|
||||||
| [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
|
|
||||||
| [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
|
|
||||||
| [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
|
||||||
| [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
|
|
||||||
| [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
|
|
||||||
| [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
|
|
||||||
| [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
|
|
||||||
| [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
|
|
||||||
| [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
|
|
||||||
| [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
|
|
||||||
| [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
|
|
||||||
| [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
|
|
||||||
|
|
||||||
A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP +
|
|
||||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
|
||||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
|
||||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
|
||||||
At 10,000 such enterprises: $5B/yr. The first-mover advantage is not about any
|
|
||||||
single framework — it is about being the first to offer a unified gate stack
|
|
||||||
that maps to all of them.
|
|
||||||
|
|
||||||
|
|
||||||
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
|
||||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
|
||||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
|
||||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
|
||||||
At 10,000 such enterprises: $5B/yr.
|
|
||||||
|
|
||||||
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
|
||||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
|
||||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
|
||||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
|
||||||
At 10,000 such enterprises: $5B/yr. See the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] for the full
|
|
||||||
framework list, [[id:558154ea-e63a-4c45-998c-26ce8588585b][first-mover window analysis]] for timing strategy, and
|
|
||||||
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] for the economic dynamics
|
|
||||||
behind the revenue.
|
|
||||||
@@ -1,15 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
|
|
||||||
:END:
|
|
||||||
#+title: Cost Structure — Zero Marginal Cost
|
|
||||||
#+filetags: :passepartout:economics:cost:marginal:zero:
|
|
||||||
|
|
||||||
- **One-time cost:** [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains)
|
|
||||||
- **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image
|
|
||||||
- **No recurring LLM API costs** for the 80% symbolic reasoning layer
|
|
||||||
- **After [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only
|
|
||||||
|
|
||||||
The cost curve inverts: generation is expensive, verification is cheap. This is the inversion [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] exploits. This is the core insight of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — symbolic verification costs approach zero while LLM token costs remain constant.
|
|
||||||
|
|
||||||
Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude.
|
|
||||||
@@ -1,18 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
|
|
||||||
:END:
|
|
||||||
#+title: Domain Gate Rule Subscriptions
|
|
||||||
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:
|
|
||||||
|
|
||||||
Pre-verified [[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.
|
|
||||||
|
|
||||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] package: $50K/yr
|
|
||||||
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] package: $50K/yr
|
|
||||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] package: $50K/yr
|
|
||||||
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] package: $100K/yr
|
|
||||||
- Combined enterprise: $250K/yr
|
|
||||||
|
|
||||||
Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[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 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,95 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2
|
|
||||||
:ID: effects-growth-flywheel
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other
|
|
||||||
#+filetags: :passepartout:strategy:growth:effects:flywheel:
|
|
||||||
|
|
||||||
The [[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 Flywheel, Not the Pipeline
|
|
||||||
|
|
||||||
The old model (sequential, linear):
|
|
||||||
|
|
||||||
Growth Phase 0 → Effects Phase 0 → Growth Phase 1 → Effects Phase 1 → ...
|
|
||||||
|
|
||||||
The real model (interleaved, amplifying):
|
|
||||||
|
|
||||||
Enterprise sale → compliance cost drops → more enterprises buy → compliance industry margin erodes → price drops further → small businesses afford gate rules → regulator notices → regulation-as-code → enterprises /must/ buy → ...
|
|
||||||
|
|
||||||
At every scale, the effect /is/ the growth mechanism. There is no waiting for effects to "arrive" after adoption reaches a threshold. The first enterprise that saves $500K on an audit has already triggered the compliance erosion effect — at scale 10⁶, that same effect is a structural industry shift, but it is the same mechanism operating at different magnitudes.
|
|
||||||
|
|
||||||
* Effect–Growth Map at Each Scale
|
|
||||||
|
|
||||||
** Phase 0 (0 → 10² instances, weeks–months)
|
|
||||||
|
|
||||||
| Instance count | Effect that starts | Growth driver generated |
|
|
||||||
|---------------+-------------------+------------------------|
|
|
||||||
| 1–10 | /Scientific reproducibility:/ the first verified paper | Universities buy [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] for their compute clusters |
|
|
||||||
| 1–10 | /Compliance erosion:/ first enterprise replaces audit with gate rule | Competitors must match the cost savings — enterprise sales accelerate |
|
|
||||||
| 10–50 | /Verification API gateway:/ first company runs LLM calls through Passepartout | /Any/ company using LLMs is a customer, not just triad adopters. This effect starts at 10 instances but can scale to millions of API users before growth Phase 1 |
|
|
||||||
|
|
||||||
Key observation: the verified API gateway decouples the effect from triad adoption. A company using the gateway never installs Passepartout — they send API calls to a proxy and get back a proof log. The gateway is an /effect/ that drives /economic growth/ (revenue) without requiring /ecosystem growth/ (instances).
|
|
||||||
|
|
||||||
** Phase 1 (10² → 10⁴ instances, months–years)
|
|
||||||
|
|
||||||
| Instance count | Effect that starts | Growth driver generated |
|
|
||||||
|-------+-------------------+------------------------|
|
|
||||||
| 100–500 | /Regulation as code:/ first regulator encodes a rule as a gate | All regulated entities under that regulator must adopt Passepartout — step function in demand |
|
|
||||||
| 500–2K | /AI safety shift:/ gate rule verification becomes expected in enterprise AI procurement | Every company buying AI services requires a proof log — API gateway demand explodes |
|
|
||||||
| 2K–10K | /Proof library compounding:/ the [[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.
|
|
||||||
|
|
||||||
** Phase 2 (10⁴ → 10⁶ instances, years)
|
|
||||||
|
|
||||||
| Instance count | Effect that starts | Growth driver generated |
|
|
||||||
|-------+-------------------+------------------------|
|
|
||||||
| 10K–50K | /Computational trust:/ PDS model makes surveillance advertising visibly obsolete | Consumer demand for PDS — "why does my bank still own my data?" |
|
|
||||||
| 50K–200K | /Verification cachet:/ /I verify/ becomes a resume signal | Developer adoption accelerates — not from enterprise mandate but from peer pressure and cultural norm |
|
|
||||||
| 200K–1M | /Attestation marketplace:/ verifiable reputation has enough data to be reliable | Insurance products become viable — insurers price unverified code higher |
|
|
||||||
|
|
||||||
Key observation: the shift from enterprise adoption to consumer adoption is cultural, not technical. The technology works at 10K instances. But consumers don't adopt because the tech works — they adopt because the /alternative is socially unacceptable/. The verification cachet effect /is/ the consumer growth engine.
|
|
||||||
|
|
||||||
** Phase 3 (10⁶ → 10⁹ instances, years–generations)
|
|
||||||
|
|
||||||
| Instance count | Effect that starts | Growth driver generated |
|
|
||||||
|-------+-------------------+------------------------|
|
|
||||||
| 1M–10M | /Insurance loop closes:/ premiums for unverified code are 10× verified | Economic necessity drives adoption — not engineering preference, not regulation, but /cost of doing business/ |
|
|
||||||
| 10M–100M | /[[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]:/ regulator references the early player's gate library | New entrants cannot compete with the installed proof base — the moat compounds with every new instance |
|
|
||||||
| 100M–1B | /Compute as geopolitical asset:/ nations run triad instances for digital sovereignty | Nation-state procurement — 100M to 1B happens via government mandate, not organic adoption |
|
|
||||||
|
|
||||||
Key observation: the insurance loop is the /completion of the flywheel/. At this point, adoption is no longer driven by the triad's features or benefits — it is driven by the /cost of non-adoption/. The flywheel transitions from pull (people want verification) to push (people cannot afford to be unverified).
|
|
||||||
|
|
||||||
* The Critical Path
|
|
||||||
|
|
||||||
The flywheel has two critical bottlenecks:
|
|
||||||
|
|
||||||
1. /First regulator encodes a rule as a gate./ This is the most leveraged event in Phase 0–1. It converts growth from organic to mandatory in a single domain. Whoever reaches a regulator first — and helps them write that first gate rule — wins that domain permanently.
|
|
||||||
|
|
||||||
2. /First insurer prices unverified code higher./ This is the Phase 2→3 transition. It converts growth from pull to push. The insurer does not need 1B instances to act — they need 10K instances with 2+ years of verifiable track records. The [[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
|
|
||||||
|
|
||||||
| Adoption (instances) | Dominant effect | Growth mechanism |
|
|
||||||
|---------------------+----------------+------------------|
|
|
||||||
| 0 → 10² | Compliance cost drops | Enterprise sales — the effect /is/ the value proposition |
|
|
||||||
| 10² → 10⁴ | Regulation becomes executable | Mandate — one regulator converts pull to push in a domain |
|
|
||||||
| 10² → 10⁴ | AI safety shifts to engineering | Verified API gateway sells to /any/ LLM user, decoupled from triad adoption |
|
|
||||||
| 10⁴ → 10⁶ | Trust shifts from institutional to computational | Consumer adoption — cultural norm, not technical requirement |
|
|
||||||
| 10⁶ → 10⁹ | Cost of non-verification exceeds cost of adoption | Insurance + regulation lock-in — economic necessity, not preference |
|
|
||||||
|
|
||||||
Each row's effect /is/ the growth driver for the next row's instance count. The flywheel is the product. The triad is the architecture. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] is the steady state.
|
|
||||||
|
|
||||||
* References
|
|
||||||
|
|
||||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]]
|
|
||||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth phases — zero to billions]]
|
|
||||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
|
||||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue per phase]]
|
|
||||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
|
||||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Attestation and insurance]]
|
|
||||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
|
||||||
@@ -1,18 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
|
|
||||||
:END:
|
|
||||||
#+title: Evaluation Harness as Certification Service
|
|
||||||
#+filetags: :passepartout:revenue:certification:evaluation:regression:
|
|
||||||
|
|
||||||
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness.
|
|
||||||
|
|
||||||
**Service:** "Run our 10,000-task suite against your AI agent and get a Merkle-verified score."
|
|
||||||
**Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
|
|
||||||
**Price:** $50K-$200K per certification.
|
|
||||||
|
|
||||||
The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] mechanism in action.
|
|
||||||
|
|
||||||
10 certifications in year one = $500K-$2M.
|
|
||||||
|
|
||||||
Long-term endpoint: this becomes the UL certification for AI — a third-party verification nobody can ignore. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]]. The certification relies on a [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] to run the tests in a trusted environment, creating [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]].
|
|
||||||
@@ -1,18 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
|
|
||||||
:END:
|
|
||||||
#+title: Gate Rule Encoding from Codified Domains
|
|
||||||
#+filetags: :passepartout:gates:rules:encoding:llm:translation:
|
|
||||||
|
|
||||||
Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
|
|
||||||
|
|
||||||
Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
|
|
||||||
- (if contract > $250K AND not small-business-set-aside → :deny)
|
|
||||||
- (if sole-source AND no justification-documented → :deny, produce-justification)
|
|
||||||
|
|
||||||
ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
|
|
||||||
|
|
||||||
The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
|
|
||||||
|
|
||||||
For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] that can be reused across deployments.
|
|
||||||
@@ -1,201 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f
|
|
||||||
:ID: growth-strategy
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Growth — Two Engines, One Infrastructure
|
|
||||||
#+filetags: :passepartout:growth:network:strategy:agora:
|
|
||||||
|
|
||||||
The triad has two independent growth engines that share the same infrastructure. Logos (verification) grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[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.
|
|
||||||
|
|
||||||
* The Two Engines
|
|
||||||
|
|
||||||
/Logos (top-down, revenue-funded):/
|
|
||||||
- Customer: CISO, compliance buyer
|
|
||||||
- Growth lever: Enterprise sales + gate rule library compounding
|
|
||||||
- Revenue: $2-12M/year by month 12
|
|
||||||
- Failure mode: Wrong pricing, too early for market
|
|
||||||
- Entry: Direct enterprise compliance engagements
|
|
||||||
|
|
||||||
/Agora (bottom-up, community-driven):/
|
|
||||||
- Customer: Organized communities, creators, developers
|
|
||||||
- Growth lever: Multi-vector network effects (identity, publishing, payments, contracts, governance)
|
|
||||||
- Revenue: Transaction fees, PDS hosting, marketplace commissions
|
|
||||||
- Failure mode: Never reaches critical mass on any vector
|
|
||||||
- Entry: Organized community onboarding pilot groups, then expand
|
|
||||||
|
|
||||||
* Phase 0: Bootstrapping (0 → 100 instances, 0 → 10K Agora users, 3-12 months)
|
|
||||||
|
|
||||||
** Logos Engine
|
|
||||||
|
|
||||||
*Customer:* Enterprise compliance teams. Clear buyer (CISO), existing budget, pain that maps directly to gate rules.
|
|
||||||
|
|
||||||
*Growth lever:* Enterprise sales + direct integration. No network effects yet — value must be real without anyone else using it.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. Ship [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] MVP — verifies code, applies gate rules, produces compliance report.
|
|
||||||
2. First sale encodes a regulation as gate rules, verifies the customer's deployment.
|
|
||||||
3. Each engagement funds the next. Gate rule library grows with every customer.
|
|
||||||
4. The [[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.
|
|
||||||
|
|
||||||
** Agora Engine
|
|
||||||
|
|
||||||
*Customer:* Organized communities — HOAs, clubs, cooperatives, PTAs, volunteer orgs, religious groups — any group that currently uses 3+ separate tools and has a leader who can onboard them.
|
|
||||||
|
|
||||||
*Growth lever:* Group density solves the cold start. The community exists before the platform. Onboard one HOA of 200 families, get 200 users at once.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. Identify 5-10 pilot communities via warm intros or personal networks.
|
|
||||||
2. Each gets a white-glove onboarding: admin sets up their Collective Persona, invites members via share link.
|
|
||||||
3. Members arrive to find a complete community space: announcement feed, group chat, task board, treasury, voting.
|
|
||||||
4. The first real use case (budget vote, dues collection, contractor hire) is the killer demo.
|
|
||||||
5. Ship identity + content + contracts + payments + governance. The bundle must work from day one for organized communities — they need all five layers.
|
|
||||||
|
|
||||||
*Revenue:* Minimal in Phase 0 ($20-100K in transaction fees). The goal is product-market fit with a specific community type, not revenue.
|
|
||||||
|
|
||||||
*Key metric for crossover:* Community retention at 90 days. If a community is still using the Agora for its core operations after 90 days, the bundle has stickiness.
|
|
||||||
|
|
||||||
*Phase 0 crossover:* The first enterprise compliance customer needs employee identities. Their PDS deployment seeds Agora identities for the compliance team. This is accidental — the enterprise's employees get DIDs as a side effect of their company buying verification. The Agora gets its first non-community users for free.
|
|
||||||
|
|
||||||
** Combined Summary
|
|
||||||
|
|
||||||
| Dimension | Logos | Agora |
|
|
||||||
|-----------+-------+-------|
|
|
||||||
| Customer | CISO, compliance buyer | HOA president, club leader |
|
|
||||||
| Entry | Cold sales | Warm intro to pilot communities |
|
|
||||||
| Revenue | $2-12M | $20-100K |
|
|
||||||
| Key metric | Instances deployed | Communities active at 90 days |
|
|
||||||
| Failure mode | Wrong pricing, too early | No community finds PMF |
|
|
||||||
| Build priority | Passepartout MVP | Note primitive, PDS, SCAL basics |
|
|
||||||
|
|
||||||
* Phase 1: Dual Growth (100 → 10K instances, 10K → 100K Agora users, 12-24 months)
|
|
||||||
|
|
||||||
** Logos Engine
|
|
||||||
|
|
||||||
*Customer:* Two-sided — enterprise compliance (continuing Phase 0) plus individual developers adopting Passepartout through AGPL.
|
|
||||||
|
|
||||||
*Growth lever:* Open-source adoption + platform economics. The gate rule SDK lets developers create and sell their own gate rules.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. Gate rule SDK launch — developers encode compliance domains as products.
|
|
||||||
2. Proof library compounding — every new instance contributes edge cases.
|
|
||||||
3. Attestation marketplace — track record of correct verifications carries weight.
|
|
||||||
4. Agora identities as employee benefit — every enterprise PDS includes DIDs for all employees.
|
|
||||||
|
|
||||||
*Revenue:* $10-50M. Verification appliances, marketplace fees, Agora username registrations.
|
|
||||||
|
|
||||||
*Key metric:* Third-party gate rules published. Active developer count.
|
|
||||||
|
|
||||||
** Agora Engine
|
|
||||||
|
|
||||||
*Customer:* Community refugees (banned subreddits, nuked Discord servers) + creators (OnlyFans/Patreon refugees who want to own their audience).
|
|
||||||
|
|
||||||
*Growth lever:* Crisis-driven migration + creator-led audience migration.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. Monitor deplatforming events. When a subreddit of 10K+ users gets banned, offer a ready-made Agora community space within 24 hours.
|
|
||||||
2. Ship creator tools: LSAT for paywalled content, Lightning subscriptions, Blind CDN for video distribution.
|
|
||||||
3. The Phase 0 pilot communities now have members who need to hire each other. Freelance contracts emerge organically.
|
|
||||||
4. Every enterprise PDS deployment from the Logos engine includes employee DIDs. Those employees can join Agora communities with zero friction.
|
|
||||||
|
|
||||||
*Revenue:* $1-5M. Transaction fees from contracts, LSAT subscriptions, PDS hosting.
|
|
||||||
|
|
||||||
*Key metric:* Communities onboarded. Paying subscribers. Contract volume.
|
|
||||||
|
|
||||||
** Phase 1 Crossover
|
|
||||||
|
|
||||||
This is the critical reinforcement point:
|
|
||||||
|
|
||||||
- Enterprise employees already have Agora DIDs (from their company's PDS). They can join Agora communities with one click — no registration, no password, no onboarding friction.
|
|
||||||
- Agora communities naturally need verification. An HOA's contractor hire should be verified. A community's vote results should be provable. The verification engine that Logos built for enterprises is now useful for communities.
|
|
||||||
- The compute marketplace now has two demand sources: enterprise verification (production workloads) and community verification (contract executions, attestation requests).
|
|
||||||
|
|
||||||
*Phase 1 crossover metric:* Percentage of Agora transactions that use Logos verification. Target: 10%+ by end of Phase 1.
|
|
||||||
|
|
||||||
* Phase 2: Convergence (10K → 1M instances, 100K → 10M Agora users, 2-5 years)
|
|
||||||
|
|
||||||
** Logos Engine
|
|
||||||
|
|
||||||
*Customer:* Enterprise compliance (continuing) + verification marketplace (scaling) + insurance industry.
|
|
||||||
|
|
||||||
*Growth lever:* Stoa premium enterprise features + insurance marketplace.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] premium ships SSO, compliance dashboards, fleet management.
|
|
||||||
2. Insurance marketplace forms — actuaries price proof insurance based on track records of 10K+ instances.
|
|
||||||
3. [[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.
|
|
||||||
|
|
||||||
** Agora Engine
|
|
||||||
|
|
||||||
*Customer:* Freelancers, gig workers, small businesses. The organized communities from Phase 0-1 now have enough history that their reputation graph carries real weight.
|
|
||||||
|
|
||||||
*Growth lever:* Professional network effects. A freelancer's contract history on the Agora is portable proof of reliability. The reputation is not tied to any platform — it's tied to their DID.
|
|
||||||
|
|
||||||
*Tactics:*
|
|
||||||
1. Freelancer marketplace emerges organically — communities that already use contracts start hiring across communities.
|
|
||||||
2. The Algorithm Marketplace creates differentiation — users choose their feed curation logic.
|
|
||||||
3. Agora identities hit 1M. The namespace has real scarcity. Premium username auctions produce significant revenue.
|
|
||||||
4. Enterprise adoption of Agora happens because employees already have DIDs. Companies start using Agora spaces for internal collaboration.
|
|
||||||
|
|
||||||
*Revenue:* $20-100M. Transaction fees, PDS hosting, marketplace commissions, username renewals.
|
|
||||||
|
|
||||||
** Phase 2 Crossover
|
|
||||||
|
|
||||||
The two engines begin to merge:
|
|
||||||
|
|
||||||
- Verification is no longer an enterprise-only product. It is a network service consumed by every Agora transaction. Every contract execution, every attestation, every vote runs through the compute marketplace.
|
|
||||||
- The Agora's reputation graph becomes the best source of verification track records. Actuaries price insurance based on DID history. The insurance products that Logos enables are /powered by/ Agora data.
|
|
||||||
- Enterprise employees use the same DID for compliance work and community participation. The boundary between "work identity" and "personal identity" is a Persona toggle — same infrastructure, different roles.
|
|
||||||
|
|
||||||
*Phase 2 crossover metric:* Percentage of verification requests that originate from Agora transactions. Target: 50%+ by end of Phase 2.
|
|
||||||
|
|
||||||
* Phase 3: Infrastructure (1M → 10M+ instances, 10M → 1B+ Agora users, 5-15 years)
|
|
||||||
|
|
||||||
** Both Engines
|
|
||||||
|
|
||||||
At this scale, the distinction between Logos and Agora becomes meaningless. Verification is the compute layer. The Agora is the application layer. They are the same infrastructure:
|
|
||||||
|
|
||||||
- /Verification monopoly:/ The gate library is the most comprehensive proof library ever assembled. Regulators reference it. Insurers require it.
|
|
||||||
- /Default identity:/ The Agora DID is the default identity for internet users. New services offer Agora login because users demand it.
|
|
||||||
- /Insurance lock-in:/ Insurers price unverified code out of existence. The cost of /not/ verifying exceeds the cost of adopting the triad.
|
|
||||||
- /Nation-state adoption:/ Countries run their own triad instances for digital sovereignty. The compute marketplace is a sovereign asset.
|
|
||||||
- /Installed base moat:/ A new entrant cannot replicate 10+ years of attestation history, 1B+ identities, and millions of verified contracts.
|
|
||||||
|
|
||||||
*Revenue:* $1B+. Certification monopoly revenue, infrastructure rent, marketplace fees, insurance underwriting, PDS hosting at global scale.
|
|
||||||
|
|
||||||
* The Combined Curve
|
|
||||||
|
|
||||||
| Phase | Logos scale | Agora scale | Revenue | Crossover | Failure mode |
|
|
||||||
|-------+-------------+-------------+---------+-----------+--------------|
|
|
||||||
| 0 | 0→100 instances | 0→10K users | $2-12M | Enterprise PDS seeds first DIDs | Either engine stalls |
|
|
||||||
| 1 | 100→10K inst | 10K→100K users | $11-55M | Employees join communities; communities need verification | Logos: developer UX. Agora: no vector reaches PMF |
|
|
||||||
| 2 | 10K→1M inst | 100K→10M users | $70-300M | Most verification serves Agora; most Agora data feeds verification | Logos: scaling compute. Agora: UX polish gap |
|
|
||||||
| 3 | 1M→10M+ inst | 10M→1B+ users | $1B+ | The layers are unified | Technology paradigm shift |
|
|
||||||
|
|
||||||
* Why This Works Together
|
|
||||||
|
|
||||||
Organized communities are the entry point that forces the Agora to ship the full bundle from day one. An HOA using the Agora for announcements, dues, contracts, and voting demonstrates the complete vision — identity + content + payments + contracts + governance — in a single, understandable use case. No marketing message can compete with a community member seeing their dues collected and a roof contract executed through one platform.
|
|
||||||
|
|
||||||
Enterprise compliance funds the build. A Phase 0 CISO engagement brings in $500K-2M, enough to pay a small team for a year. The same team ships the Agora Note primitive, PDS, and SCAL. The enterprise revenue buys time for the community adoption to find PMF.
|
|
||||||
|
|
||||||
The crossover is automatic. Enterprise employees get DIDs from their company's PDS. They join Agora communities because the DID works everywhere. Communities need verification for their contracts and votes. The verification engine is already running. The two engines were never separate — they were always the same infrastructure, just adopted by different users at different times.
|
|
||||||
|
|
||||||
* References
|
|
||||||
|
|
||||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
|
||||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]
|
|
||||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]]
|
|
||||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first alternative (now integrated)]]
|
|
||||||
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
|
||||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]]
|
|
||||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects]]
|
|
||||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
|
||||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
|
||||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]]
|
|
||||||
- The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Agora Social Space requirements]] define how organized communities interact through the gate stack. See also Agora Protocol Specification — full requirements (spec repo at /tmp/agora) — full requirements (spec repo at /tmp/agora)
|
|
||||||
@@ -1,17 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
|
|
||||||
:END:
|
|
||||||
#+title: Infrastructure Lock-In and Switching Costs
|
|
||||||
#+filetags: :passepartout:economics:moats:lock-in:switching:
|
|
||||||
|
|
||||||
A hospital that runs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] with [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rules ($50K/yr) for five years has accumulated:
|
|
||||||
|
|
||||||
- A fact store with a decade of compliance decisions
|
|
||||||
- A proof forest of verified rules
|
|
||||||
- An empirical decision history tied to their specific deployment
|
|
||||||
- Customized gate rules encoding their specific workflows and approvals
|
|
||||||
|
|
||||||
Switching to a competitor means discarding all of it. The accumulated value grows as the fact store deepens. Annual revenue per enterprise grows from $250K in year one to $500K-$1M by year five as more [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain packages]] are added.
|
|
||||||
|
|
||||||
This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][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,20 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
|
|
||||||
:END:
|
|
||||||
#+title: Investment Thesis
|
|
||||||
#+filetags: :passepartout:economics:investment:thesis:
|
|
||||||
|
|
||||||
The early player benefits from every other instance of the triad. Every deployed instance feeds edge cases into the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][regression suite]], grows the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], and validates the hardware designs. Network effects are positive sum.
|
|
||||||
|
|
||||||
Three revenue horizons:
|
|
||||||
|
|
||||||
- **Low-hanging fruit (year one, $2M-$12M):** [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliances]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate rule subscriptions]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness certification]], migration services
|
|
||||||
- **Medium-term (1-3 years, $10M-$50M):** [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], Relay Network, Lisp Machine hardware; [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]] ($10M/yr), [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS hosting]] ($18M/yr)
|
|
||||||
- **Big money (3-10 years, $100M-$1B+):** [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] (UL certification for AI), [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]], planetary compute marketplace
|
|
||||||
|
|
||||||
The [[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 [[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,20 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 67faf52f-9126-50a7-b87e-2bedc610dac7
|
|
||||||
:END:
|
|
||||||
#+title: Licensing — AGPLv3 + Commercial
|
|
||||||
#+filetags: :passepartout:ip:licensing:agpl:commercial:
|
|
||||||
|
|
||||||
**AGPLv3 for the public repository.** AGPL closes the ASP loophole: anyone who modifies the software and offers it over a network must release their modified source. Combined with a [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]], this creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against proprietary forks.
|
|
||||||
|
|
||||||
Crucially: AGPL is a *product requirement*, not a concession. The system's value proposition is provable correctness — every decision has Merkle provenance. This claim is structurally incredible with closed source. An enterprise buyer needs to inspect the gate stack, verify the Merkle implementation, and confirm ACL2 integration. AGPL makes this possible without signing an NDA. This transparency also enables a [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] model where enterprises can run their own infrastructure.
|
|
||||||
|
|
||||||
**AGPL only covers modifications to code, not:**
|
|
||||||
- Gate rules specific to a domain (these are data, not code)
|
|
||||||
- The fact store (empirical data generated from usage)
|
|
||||||
- Ontology categories (design decisions stored as configuration)
|
|
||||||
- Proprietary skills loaded at runtime (AGPL boundary on plugin systems is legally unsettled)
|
|
||||||
|
|
||||||
**Dual license model:**
|
|
||||||
- AGPLv3 for open source — builds ecosystem, trust, community
|
|
||||||
- Commercial license for enterprises that cannot accept AGPL — MySQL/SugarCRM/GraphQL model
|
|
||||||
@@ -1,17 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
|
|
||||||
:END:
|
|
||||||
#+title: Why Lisp Is Economically Viable Now
|
|
||||||
#+filetags: :passepartout:economics:lisp:history:C:viability:
|
|
||||||
|
|
||||||
The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. Lisp's verification infrastructure is now the cheaper option.
|
|
||||||
|
|
||||||
Four transformations flipped the economics:
|
|
||||||
|
|
||||||
1. **Memory is free.** 40MB runtime is noise on a $20 Raspberry Pi with 8GB RAM. In 1980, DRAM was ~$5,000/MB.
|
|
||||||
2. **Transistors are free.** Modern ARM Cortex-A72 has billions of transistors. GC and type dispatch cost nothing because the transistors are there whether used or not.
|
|
||||||
3. **Complexity saturates human verification.** Systems are tens of millions of lines. Testing is necessary but insufficient — zero-day vulnerabilities prove bugs survive all testing. Formal verification is the only known path.
|
|
||||||
4. **Cost of failure exceeds cost of verification.** A single breach costs millions. Regulation mandates provable compliance. Proving correctness is cheaper than not proving it.
|
|
||||||
|
|
||||||
The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][biology parallels]]. For the historical precedent, see the [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][comparison with Symbolics Genera]]. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI industry]] is the market-side consequence.
|
|
||||||
30
ideas/lisp-game-engine-substrate.org
Normal file
30
ideas/lisp-game-engine-substrate.org
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:ID: f467ce16-1861-4ebd-96ed-b52fea909515
|
||||||
|
:CREATED: [2026-06-05 Fri]
|
||||||
|
:END:
|
||||||
|
#+title: Lisp as Game Engine Substrate
|
||||||
|
|
||||||
|
The GOAL compiler (Naughty Dog, Jak and Daxter) proved Lisp could ship SOTA games on constrained hardware (PS2, 32MB RAM). Twenty years later, the question is whether Lisp can do it again on modern hardware — and whether the CL Modernization work makes it viable.
|
||||||
|
|
||||||
|
**What Lisp gives you that C++ cannot match:**
|
||||||
|
|
||||||
|
- Interactive development at runtime — change AI, physics, or rendering code while the game runs. No compile-link-run cycle. C++ engines for large projects measure iteration in minutes; Lisp measures it in frames.
|
||||||
|
- Macros for game DSLs — behavior trees, animation blend graphs, dialogue trees, state machines become native Lisp code instead of external tools with serialization boundaries.
|
||||||
|
- CLOS multiple dispatch for ECS — generic functions on component types replace manual message routing.
|
||||||
|
- Image-based workflow — save and resume the entire engine state (GPU, audio, physics, editor) from anywhere.
|
||||||
|
|
||||||
|
**Where Lisp falls short:**
|
||||||
|
|
||||||
|
- GC tail latency — concurrent generational GCs (single-digit ms) are acceptable for 60fps (16ms budget) but problematic for VR at 90fps (11ms) or competitive esports. The CL Modernization analysis identifies this as inherent but mitigatable, and eliminates it entirely on a tagged RISC-V core with hardware CONS and concurrent collection.
|
||||||
|
- GPU interop — no idiomatic Vulkan/DirectX 12 bindings. This is an ecosystem gap (fixable), not a language limitation.
|
||||||
|
- No modern engine exists — Unreal Engine 5 is ~5M lines of C++. At 3-5x density, a Lisp equivalent might be 1-2M lines. Massive but smaller than the C++ baseline.
|
||||||
|
|
||||||
|
**The GOAL lesson:** Naughty Dog's compiler used disciplined Lisp written to avoid allocation on hot paths, proving the constraint is programmer practice, not language capability. Modern SBCL with type declarations compiles to within 2x of C on hot numerical code — sufficient for games where the bottleneck is GPU fill rate, not CPU-bound game logic.
|
||||||
|
|
||||||
|
**What changes with the CL Modernization work:** A verified Lisp runtime eliminates the class of bugs that causes engine crashes; a RISC-V Lisp extension with hardware CONS and concurrent GC eliminates the tail-latency argument against real-time use; and the density advantage makes a from-scratch engine build tractable for an AI agent working at 10x human velocity.
|
||||||
|
|
||||||
|
For further analysis, see [[https://en.wikipedia.org/wiki/GOAL_(programming_language)]].
|
||||||
|
|
||||||
|
See also:
|
||||||
|
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][Lisp Foundation]] — the CL Modernization analysis this builds on
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the verified Lisp machine target
|
||||||
175
ideas/lisp-geometry-engine.org
Normal file
175
ideas/lisp-geometry-engine.org
Normal file
@@ -0,0 +1,175 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:ID: aae3b3a9-05c2-4acd-bfd4-a7f65003c0bf
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:END:
|
||||||
|
---
|
||||||
|
type: idea
|
||||||
|
title: All-Lisp Geometry Engine
|
||||||
|
created: '2026-06-04T00:00:00.000Z'
|
||||||
|
tags:
|
||||||
|
- APM
|
||||||
|
- CAD
|
||||||
|
- CAM
|
||||||
|
- UX
|
||||||
|
- architecture
|
||||||
|
- constraint-solving
|
||||||
|
- design-tools
|
||||||
|
- empirical
|
||||||
|
- gaming
|
||||||
|
- geometry-engine
|
||||||
|
- lisp
|
||||||
|
- provenance
|
||||||
|
- three-pronged
|
||||||
|
---
|
||||||
|
|
||||||
|
A unified Lisp geometry engine built on the three-pronged model — the
|
||||||
|
constraint kernel IS the physics, and the design world is aware of its own
|
||||||
|
physics by default because the system won't let you produce a design that
|
||||||
|
violates physical constraints without flagging it.
|
||||||
|
|
||||||
|
This is Ivan Sutherland's Sketchpad vision (1963), fully realized: the
|
||||||
|
drawing IS the program, the constraints ARE the physics, and the system
|
||||||
|
solves them in real-time — across CAD precision, game rendering, and UX
|
||||||
|
layout — from one kernel in one address space.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**The three prongs, applied to the geometry engine.**
|
||||||
|
|
||||||
|
The three-pronged architecture (deductive proofs / provenance-tracked
|
||||||
|
empirical models / probabilistic oracle, under one gate) is not an abstract
|
||||||
|
epistemological framework. It maps directly onto what a design tool needs.
|
||||||
|
|
||||||
|
**Prong 1 — deductive: the constraint solver.**
|
||||||
|
|
||||||
|
The geometry kernel IS deductive mathematics. When the solver determines
|
||||||
|
that four points are coplanar, or that an edge is tangent to a cylinder at
|
||||||
|
exactly 5mm offset, it is computing a deductive consequence of the
|
||||||
|
constraint system. The formulas for intersection, tangency, and spatial
|
||||||
|
relationships are formal geometry. ACL2 could verify them. The constraint
|
||||||
|
network is a theorem: the set of all poses that satisfy the specified
|
||||||
|
relations. Solving it is proving the theorem.
|
||||||
|
|
||||||
|
**Prong 2 — empirical: provenance-tracked material properties.**
|
||||||
|
|
||||||
|
This is the prong that changes design work fundamentally. Currently, design
|
||||||
|
software pretends material properties are true numbers. You pick "steel"
|
||||||
|
from a dropdown and see Young's modulus = 200 GPa. But that 200 GPa is an
|
||||||
|
average across 50 samples from different suppliers at different batch runs.
|
||||||
|
The actual value for your specific part is between 190 and 210 GPa, and the
|
||||||
|
software never tells you.
|
||||||
|
|
||||||
|
With provenance-tracked empirical models, every parameter in the constraint
|
||||||
|
network carries its epistemic status: measured from a specific experiment,
|
||||||
|
fitted to a published dataset, extrapolated beyond validation with a
|
||||||
|
confidence penalty, or guessed because no data exists. The provenance store
|
||||||
|
holds the source chain, validity envelope, and confidence interval for every
|
||||||
|
parameter. The constraint solver propagates uncertainty automatically.
|
||||||
|
|
||||||
|
The consequence: the designer designs to a distribution, not a platonic
|
||||||
|
number. The clearance at a joint shows as 0.03-0.08mm, not 0.05mm flat.
|
||||||
|
Material selection becomes a query with confidence thresholds, not a
|
||||||
|
dropdown. Tolerance stack-up falls out of provenance automatically. The
|
||||||
|
finished design carries a confidence budget: "Confidence this meets
|
||||||
|
specification under rated load: 95%. Material parameter uncertainty
|
||||||
|
contributes 3%, manufacturing tolerance contributes 1.5%."
|
||||||
|
|
||||||
|
The validity envelope constrains what the designer can even specify. You try
|
||||||
|
to design a seal for 500C operation. The provenance store says: the
|
||||||
|
empirical model for this material is validated to 300C. Above that, the only
|
||||||
|
data is a single 1973 paper with a 2x extrapolation factor and no confidence
|
||||||
|
interval. The gate flags it. The designer must explicitly accept the risk
|
||||||
|
(logged to the provenance chain with a signature) or select a material with
|
||||||
|
better empirical coverage.
|
||||||
|
|
||||||
|
Manufacturing feedback closes the loop. The part is made, as-manufactured
|
||||||
|
dimensions are measured, the real friction coefficient is recorded. These
|
||||||
|
values write back to the provenance store. The next design iteration has
|
||||||
|
tighter confidence intervals because it incorporates production data.
|
||||||
|
Datasheet revisions propagate retroactively: a bearing manufacturer revises
|
||||||
|
load rating downward, the provenance store updates, the gate re-checks all
|
||||||
|
existing designs and flags: "Your coupling assumed 5kN from the 2022
|
||||||
|
datasheet. The 2025 revision shows 4.2kN. Safety margin is now below
|
||||||
|
required threshold."
|
||||||
|
|
||||||
|
**Prong 3 — probabilistic: the LLM as constraint explorer.**
|
||||||
|
|
||||||
|
The LLM proposes constraint system structures: "Here's a four-bar linkage
|
||||||
|
with these initial parameters." The solver validates deductively. The LLM
|
||||||
|
diagnoses failures: "The solver can't converge because constraint A and
|
||||||
|
constraint B conflict — the offset exceeds available column space given the
|
||||||
|
pivot locations." The LLM proposes alternatives; the solver checks.
|
||||||
|
|
||||||
|
The LLM handles what cannot be formalized: model selection (which force
|
||||||
|
field for this molecule class?), interpretation (why did the simulation
|
||||||
|
fail?), creative generation (suggest a design that meets these spec limits).
|
||||||
|
The gate ensures the LLM proposes only — it never executes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**One representation, all domains.**
|
||||||
|
|
||||||
|
The same constraint kernel drives engineering (CAD/CAM — float64, micron
|
||||||
|
precision, batch solve), gaming (float32, 144fps, iterative solve), and UX
|
||||||
|
layout (pixel-aligned, 120fps, layout constraints). CLOS dispatch selects
|
||||||
|
the solver backend based on the precision context and frame deadline. The
|
||||||
|
constraint language is the same; the solver varies by domain.
|
||||||
|
|
||||||
|
Lisp macros generate optimized inner loops from the constraint DSL — typed,
|
||||||
|
inlined, unstyled — that SBCL compiles to within 2x of C. The hot path
|
||||||
|
narrowphase runs as native code, not through generic function dispatch.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Origin: Drexler's APM community and Godot.**
|
||||||
|
|
||||||
|
The motivation came from Eric Drexler's atomically precise manufacturing
|
||||||
|
community, which wanted to use Godot as a molecular machine design suite. A
|
||||||
|
game engine provides exactly what molecular nanotechnology design requires:
|
||||||
|
real-time 3D, constraint-based physics, collision detection, and interactive
|
||||||
|
spatial editing. But Godot's C++/GDScript substrate has no provenance
|
||||||
|
tracking, no validity envelopes, and no epistemic awareness. A Lisp geometry
|
||||||
|
engine on the three-pronged architecture provides what the APM design suite
|
||||||
|
needs: the constraint kernel ensures geometric consistency (deductive), the
|
||||||
|
provenance store tracks force field parameters and validity envelopes
|
||||||
|
(empirical), and the LLM proposes molecular machine designs guided by
|
||||||
|
physical constraints (probabilistic).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Computational feasibility.**
|
||||||
|
|
||||||
|
- CAD: feasible today on SBCL. Float64 is native, no frame deadline, CLOS
|
||||||
|
dispatch at design scale (thousands of constraints, not millions).
|
||||||
|
- UX layout: feasible today. 2D constraints at 120fps with moderate scene
|
||||||
|
complexity.
|
||||||
|
- Gaming at 144fps: needs Stage 3 hardware (tagged RISC-V, hardware GC,
|
||||||
|
geometry accelerators). CLOS dispatch overhead and GC tail latency on
|
||||||
|
commodity hardware consume too much of the 6.9ms frame budget for AAA
|
||||||
|
scene complexity.
|
||||||
|
- The LLM-guided constraint search (prong 3) makes the symbolic approach
|
||||||
|
tractable at assembly scale — the LLM proposes, the solver validates,
|
||||||
|
successful patterns cache as deductive rules.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Connection to Passepartout's three-pronged architecture.**
|
||||||
|
|
||||||
|
The three-pronged section of the architecture describes "two reasoning
|
||||||
|
engines and one data store": the symbolic engine (ACL2, formal proofs,
|
||||||
|
deductive gate rules), the provenance store (empirical parameters with
|
||||||
|
sources, validity envelopes, confidence intervals), and the probabilistic
|
||||||
|
oracle (the LLM, proposing within gate bounds).
|
||||||
|
|
||||||
|
The geometry engine is not an application that happens to use this
|
||||||
|
architecture. The geometry engine IS the architecture made concrete. The
|
||||||
|
constraint solver IS the symbolic engine reasoning about design rules. The
|
||||||
|
material property database IS the provenance store. The designer exploring
|
||||||
|
alternatives IS the LLM oracle proposing and the solver validating. The gate
|
||||||
|
checking a design against the validity envelope before permitting it to be
|
||||||
|
released to manufacturing IS the same gate that checks a shell command
|
||||||
|
against security policy.
|
||||||
|
|
||||||
|
Stage 3 hardware makes it run fast enough for real-time domains. That is
|
||||||
|
where the geometry engine meets the Lisp machine — the killer app that
|
||||||
|
justifies and defines the hardware feature set.
|
||||||
@@ -1,18 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
|
|
||||||
:END:
|
|
||||||
#+title: Competitive Moats
|
|
||||||
#+filetags: :passepartout:economics:moats:competition:
|
|
||||||
|
|
||||||
Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge.
|
|
||||||
|
|
||||||
**Actual moats (weaker than initially assumed):**
|
|
||||||
1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data. Write once, trivial to copy. Not a real moat.
|
|
||||||
2. **Empirical decision history** — every HITL decision is a Merkle fact. A fresh instance has none. Makes *your* instance more valuable but doesn't prevent competition — it's a switching cost, not a barrier to entry.
|
|
||||||
3. **[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
|
|
||||||
4. **[[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure integration]]** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
|
|
||||||
|
|
||||||
**Strongest competitor strategy:** Not copying your gate rules — offering the same architecture as a service with their own pre-seeded general knowledge and a consulting engagement to customize gate rules. The AGPL prevents closing the architecture but does not prevent offering it as a service with a customization layer.
|
|
||||||
|
|
||||||
**The defensible business is services, not product.** The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout." A [[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.
|
|
||||||
@@ -1,4 +1,4 @@
|
|||||||
#+title: Orders of Magnitude — Time
|
#+title: Orders of Magnitude
|
||||||
#+filetags: :passepartout:framework:time:scale:hierarchy:
|
#+filetags: :passepartout:framework:time:scale:hierarchy:
|
||||||
|
|
||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
|||||||
@@ -1,23 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
|
|
||||||
:END:
|
|
||||||
#+title: Patent Strategy
|
|
||||||
#+filetags: :passepartout:ip:patents:legal:
|
|
||||||
|
|
||||||
**Likely patentable:**
|
|
||||||
- Probabilistic-deterministic split with deterministic gates between LLM proposal and execution (vs every competitor using prompt-based guardrails)
|
|
||||||
- Foveal-peripheral context model with Org-tree structured retrieval (targets 2,000-4,000 tokens)
|
|
||||||
- Merkle-tree memory with copy-on-write snapshots and operation-level undo/redo
|
|
||||||
- Gate-to-fact bootstrap with sufficiency criterion (mechanically extracting facts from gate stack data structures)
|
|
||||||
- Macro-layer-as-skill bootstrapping architecture (theorem-proving as hot-reloadable skills)
|
|
||||||
|
|
||||||
**Likely not patentable (known techniques):**
|
|
||||||
- ACL2 itself (decades old)
|
|
||||||
- Screamer for consistency checking (obvious application)
|
|
||||||
- Hot-reloadable skills (40 years old)
|
|
||||||
- Org-mode as a data format
|
|
||||||
|
|
||||||
**Strongest single claim:** The specific combination of probabilistic model + deterministic zero-token safety gates + Merkle memory + symbolic engine with sufficiency criterion. Each element is known; the combination is novel and non-obvious.
|
|
||||||
|
|
||||||
**Counterargument:** A patent examiner will argue these are standard OS microkernel architecture, locality of reference, content-addressed storage, and capability-based security applied to an AI agent. The defense: they have never been *combined* in an AI agent, producing emergent effects no single principle produces. These patents would feed into a [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] strategy and create [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against competitors.
|
|
||||||
@@ -1,167 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:ID: ed05cab4-88e9-4e25-b7c9-346fa39c69a0
|
|
||||||
:ID: revenue-hub
|
|
||||||
:CREATED: [2026-05-23 Sat]
|
|
||||||
:END:
|
|
||||||
#+title: Revenue Streams — Overview
|
|
||||||
#+filetags: :passepartout:revenue:index:business-model:
|
|
||||||
|
|
||||||
This page is the entry point for revenue generation thinking across all three triad components. Revenue splits cleanly across the two development phases defined in [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]]. Each component enables different revenue primitives.
|
|
||||||
|
|
||||||
* Revenue by Triad Component
|
|
||||||
|
|
||||||
** Logos (the mind) — Revenue streams
|
|
||||||
|
|
||||||
Existing coverage — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness]], [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]], [[id:d84679f1-c0c5-5be4-b19c-6573560640ee][Verified skill marketplace]]:
|
|
||||||
|
|
||||||
| Stream | Phase | Description |
|
|
||||||
|--------+-------+-------------|
|
|
||||||
| Verification appliance | Zero | FPGA/Tenstorrent pre-loaded with [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] + gate rules |
|
|
||||||
| Domain gate packages | Zero | SaaS subscriptions per compliance domain |
|
|
||||||
| Evaluation harness | Zero | Certification-as-a-service, regression suite access |
|
|
||||||
| Compute marketplace | Both | Verified symbolic engine cycles via [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] |
|
|
||||||
| Verified skill marketplace | End State | Commission on third-party gate rules |
|
|
||||||
|
|
||||||
*** Unexplored Logos streams
|
|
||||||
|
|
||||||
| Stream | Phase | Rationale |
|
|
||||||
|--------+-------+-----------|
|
|
||||||
| Verified API gateway | Zero | Drop-in proxy for LLM calls. Passepartout verifies inputs, outputs, and provenance. Enterprise customers get a verifiable audit trail for every API call. Near-term product: run your OpenAI/Anthropic calls through Passepartout and get proof. |
|
|
||||||
| Agent-as-a-service | Zero | Cloud-hosted Passepartout instances. Pay-per-verification or monthly subscription. The compute marketplace for individuals who don't self-host. |
|
|
||||||
| Continuous compliance monitoring | Zero | Watch a deployment, continuously verify it against regulatory gate rules, alert on drift. Annual contract per monitored system. The evaluation harness as a product. |
|
|
||||||
| Gate rule SDK [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] | Both | Commercial license for the gate rule development toolkit. Free for open-source rules, paid for proprietary enterprise rule development. |
|
|
||||||
| Migration pipeline | Zero | Convert existing codebases to verified Lisp. Automated SaaS (point at a repo, get back a verified version). Per-enterprise: $50K-$500K for full migration. |
|
|
||||||
| Forensics / incident response | Zero | Merkle memory provides tamper-proof audit. Post-incident: produce an irrefutable chain of what happened, who authorized it, what gates were triggered. Service offering. |
|
|
||||||
| Proof repository marketplace | End State | Pre-verified proof libraries per domain (crypto, medical device, finance). Access to accumulated proof strategies from thousands of runs. |
|
|
||||||
| Training & certification | Zero | Certified Gate Rule Developer program. Developer camps, certification exams, continuing education. The Red Hat / AWS training model. |
|
|
||||||
| Enterprise support SLA | Zero | Guaranteed verification pipeline uptime, priority bug fixes, custom gate rule development. Red Hat subscription model. |
|
|
||||||
|
|
||||||
/Verified API gateway/ is notable because it requires zero buy-in to the triad vision. Any company using LLM APIs today can deploy Passepartout as a verification proxy and immediately get value (audit trail, gate compliance, prompt injection detection). It's a standalone product that seeds the ecosystem.
|
|
||||||
|
|
||||||
** Stoa (the body) — Revenue streams
|
|
||||||
|
|
||||||
This is the /least developed/ revenue arm. Existing docs essentially say people buy hardware and the lock-in compounds. There is a gap:
|
|
||||||
|
|
||||||
Existing coverage: essentially none beyond hardware sales.
|
|
||||||
|
|
||||||
| Stream | Phase | Rationale |
|
|
||||||
|--------+-------+-----------|
|
|
||||||
| Lisp Machine hardware | End State | Tenstorrent/FPGA appliances. Hardware margins + recurring gate rules. |
|
|
||||||
| [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa]] premium | Both | Enterprise features: SSO, audit logging, compliance reports, team management, centralized policy enforcement. Annual seat license. |
|
|
||||||
| Plugin and theme marketplace | End State | Verified plugins for Stoa (editors, browsers, shells, tools). Commission on each sale. Developer ecosystem. App Store for the Lisp Machine. |
|
|
||||||
| Commercial Lisp image distribution | Both | Verified, signed, compatibility-guaranteed Stoa images. Free self-build (AGPL), paid for certified builds with SLAs. |
|
|
||||||
| Enterprise Stoa deployment | Zero | Tools for deploying Stoa across an organization: fleet management, unified gate policy, compliance dashboard. Annual license. |
|
|
||||||
| Backup and archive service | Both | Verified snapshots of Stoa Lisp images. Tamper-proof archival of development environments. |
|
|
||||||
| Stoa extension SDK | Both | Commercial license for developing proprietary Stoa extensions. Tools, documentation, support. |
|
|
||||||
|
|
||||||
Key insight: Stoa does not need the full Lisp Machine to generate revenue. Stoa premium (SSO, audit, compliance reports) and enterprise deployment tools ship on Linux, use the existing Stoa terminal UI, and sell to the same enterprise buyer who buys gate packages. Compliance teams want verified environments — Stoa premium delivers that without waiting for custom hardware.
|
|
||||||
|
|
||||||
** Agora (the society) — Revenue streams
|
|
||||||
|
|
||||||
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 |
|
|
||||||
|--------+-------+-------------|
|
|
||||||
| Premium username registry | Zero | $5-50/yr per handle, auction for high-value names |
|
|
||||||
| PDS as a service | Both | $10-1000/mo per hosted personal data store |
|
|
||||||
| Compute marketplace | Both | Commission on verified compute transactions |
|
|
||||||
|
|
||||||
The most fertile ground is contracts. DIDs provide identity, DIDComm provides communication, PDS provides state, gate rules encode terms, ACL2 verifies execution, and the symbolic engine runs deterministically. This is a full smart contract platform, strictly stronger than existing ones because ACL2 verifies the /rules themselves/, not just execution trace validity.
|
|
||||||
|
|
||||||
*** Unexplored Agora streams — contracts
|
|
||||||
|
|
||||||
| Stream | Phase | Rationale |
|
|
||||||
|--------+-------+-----------|
|
|
||||||
| Verified smart contract platform | End State | Deploy contracts on Agora with ACL2-verified correctness. Every contract call produces a machine-checkable proof. Revenue: transaction fees per execution + deployment fee per verified contract. |
|
|
||||||
| Contract template marketplace | Zero | Pre-verified contract templates for common use cases (escrow, DAO constitution, SLA, data licensing). Sell templates or take commission on template-based contracts. |
|
|
||||||
| Dispute resolution service | End State | When two Agora instances disagree on contract execution, submit to a verified arbitrator. Fee per resolution. |
|
|
||||||
| Attestation marketplace | Zero | DIDs + verified actions = verifiable reputation. Attest that a DID meets certain criteria. Revenue: attestation fees, verification fees. |
|
|
||||||
| Multi-instance governance | Zero | Cross-instance policy enforcement, unified compliance reporting, federated identity. Enterprise tier, annual license. |
|
|
||||||
| Liquid democracy infrastructure | End State | DAO governance as a service. Verified proxy voting, governance contracts. Per-vote transaction fee. |
|
|
||||||
| Insurance marketplace | End State | Reputable providers sell proof insurance. Premiums, reinsurance pool fees, actuarial gate rules. |
|
|
||||||
| Namespace sub-leasing | Both | Premium handles sub-leased between DIDs. Commission on each lease. |
|
|
||||||
| Data sharing contracts | Both | PDS-to-PDS data sharing agreements encoded as gate rules. Commission on each data transaction. |
|
|
||||||
|
|
||||||
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 [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Agora contracts]] for the full analysis.
|
|
||||||
|
|
||||||
* Revenue by Development Phase
|
|
||||||
|
|
||||||
** Phase Zero streams (ships with MVP, 1-3 months, Linux-hosted)
|
|
||||||
|
|
||||||
| Stream | Component | TAM | Buyer | Revenue type |
|
|
||||||
|--------+----------+-----+-------+--------------|
|
|
||||||
| Domain gate packages | Logos | Large | CISO/Compliance | SaaS |
|
|
||||||
| Verification appliance | Logos | Medium | Enterprise infra | Hardware + subs |
|
|
||||||
| Evaluation harness | Logos | Medium | Compliance | Certification |
|
|
||||||
| Agora premium usernames | Agora | Small | Individual | Subscription |
|
|
||||||
| PDS hosting (basic) | Agora | Medium | Individual | Hosting |
|
|
||||||
| Verified API gateway | Logos | Large | Eng teams | Per-call |
|
|
||||||
| Continuous compliance monitoring | Logos | Large | Compliance | Annual contract |
|
|
||||||
| Migration pipeline | Logos | Medium | Enterprise | Per-engagement |
|
|
||||||
| Enterprise support SLA | Logos/Stoa | Medium | Enterprise | Annual |
|
|
||||||
| Gate rule SDK (commercial) | Logos | Small | Developers | License |
|
|
||||||
| Stoa premium (enterprise) | Stoa | Medium | Enterprise | Annual seat |
|
|
||||||
| Enterprise Stoa deployment | Stoa | Medium | Enterprise Ops | Annual |
|
|
||||||
| Training and certification | All | Small | Developers | Per-seat |
|
|
||||||
| Forensics / incident response | Logos | Small | Enterprise | Per-incident |
|
|
||||||
| Contract templates | Agora | Medium | Developers | Per-template |
|
|
||||||
| Attestation marketplace | Agora | Medium | Enterprise | Per-attestation |
|
|
||||||
| Data sharing contracts | Agora | Medium | Enterprise | Per-transaction |
|
|
||||||
| Multi-instance governance | Agora | Large | Enterprise | Annual |
|
|
||||||
| Namespace sub-leasing | Agora | Small | Individuals | Per-transaction |
|
|
||||||
|
|
||||||
Phase Zero target: $2M-$12M/year (from [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]]), with upside from verified API gateway and compliance monitoring pushing toward $15-20M.
|
|
||||||
|
|
||||||
** End State streams (full Lisp Machine, 2-5 years)
|
|
||||||
|
|
||||||
| Stream | Component | TAM | Revenue type |
|
|
||||||
|--------+----------+-----+--------------|
|
|
||||||
| [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] | Logos/All | $1B+ | Certification |
|
|
||||||
| Infrastructure lock-in | All | $100B+ | Rent extraction |
|
|
||||||
| Compute marketplace | Agora | Venture-scale | Transaction fees |
|
|
||||||
| Lisp Machine hardware | Stoa | Large | Hardware + subs |
|
|
||||||
| Smart contract platform | Agora | Very large ($20B+) | Transaction fees |
|
|
||||||
| Liquid democracy infra | Agora | Large | Per-vote |
|
|
||||||
| Insurance marketplace | Agora | Very large | Premiums + fees |
|
|
||||||
| Dispute resolution | Agora | Medium | Per-resolution |
|
|
||||||
| Plugin/theme marketplace | Stoa | Large | Commission |
|
|
||||||
| Commercial image distribution | Stoa | Medium | Subscription |
|
|
||||||
| Proof repository marketplace | Logos | Medium | Subscription |
|
|
||||||
| Verified skill marketplace | Logos | Medium | Commission |
|
|
||||||
|
|
||||||
* Orders-of-Magnitude Risk Map
|
|
||||||
|
|
||||||
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 |
|
|
||||||
|-------+-----------------------+--------------|
|
|
||||||
| Weeks | Gate packages, appliance pre-orders, training | Wrong pricing, too early |
|
|
||||||
| Months | Compliance monitoring, API gateway, PDS, Stoa premium | Churn, incumbents respond |
|
|
||||||
| Years | Compute marketplace, contract platform, monopoly | Competition catches up |
|
|
||||||
| Generations | Infrastructure lock-in, insurance marketplace | Technology shift |
|
|
||||||
|
|
||||||
The phase-zero streams are all direct enterprise sales with short cycles and clear buyers. The end-state streams require installed base — you cannot have a verification monopoly without deployed triads.
|
|
||||||
|
|
||||||
* Risk-Ordered Investment Priority
|
|
||||||
|
|
||||||
1. Gate rule packages — Lowest risk. Clear buyer, existing budget, no dependency on full stack. Ship first.
|
|
||||||
2. Verified API gateway — Standalone product, anyone using LLMs is a customer. Zero triad buy-in required.
|
|
||||||
3. Verification appliance — Customers pay for hardware + ongoing subs. Verifiable revenue, long contracts.
|
|
||||||
4. Continuous compliance monitoring — Annual contracts, compliance teams budget for it.
|
|
||||||
5. Agora usernames — Trivial to implement, tests the namespace concept.
|
|
||||||
6. Contract templates + attestation — Seeds the Agora economy without needing full smart contracts.
|
|
||||||
7. Compute marketplace — High risk/reward. Requires critical mass. Phase Zero bootstraps with cloud arbitrage.
|
|
||||||
8. Verification monopoly — Thesis-level bet. Invest when installed base justifies it.
|
|
||||||
|
|
||||||
* Detailed References
|
|
||||||
|
|
||||||
- [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics (full thesis)]] — the unified economics document
|
|
||||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] — three revenue horizons, $2M to $1B+
|
|
||||||
- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]]
|
|
||||||
- [[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] — concrete pricing per framework
|
|
||||||
- [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] — 41 frameworks by region and priority
|
|
||||||
- [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]]
|
|
||||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State
|
|
||||||
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing strategy]] — AGPL + commercial
|
|
||||||
@@ -1,16 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70
|
|
||||||
:END:
|
|
||||||
#+title: The Self-Driving Lisp Machine
|
|
||||||
#+filetags: :passepartout:lisp-machine:hardware:riscv:tenstorrent:
|
|
||||||
|
|
||||||
A Tenstorrent P150 (~72 RISC-V Tensix cores) running [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]: 72 RISC-V cores running Lisp microcode, one core dedicated to ACL2, one to Screamer, the rest to gate verification and fact store operations.
|
|
||||||
|
|
||||||
The self-driving threshold: the system can synthesize and load its own FPGA microcode or Tensix dispatch programs from within the running Lisp image. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower.
|
|
||||||
|
|
||||||
Every subdomain involved is software — the most codifiable domain. RISC-V ISA, SBCL internals, ACL2 metafunctions, CIC type theory, compiler optimization — all can [[id:efc76898-03f7-57ba-923d-35d65da88bb7][flip to symbolic sufficiency]] within days to weeks of ingestion.
|
|
||||||
|
|
||||||
**Timeline:** ~6,000 lines of new code (microcode, PCIe DMA, Tensix management, benchmark harness). ~60 cycles at current velocity. 2-4 weeks. Total from today: 6-10 weeks. See [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]] for the velocity model behind these numbers.
|
|
||||||
|
|
||||||
The Tenstorrent approach is dramatically simpler than FPGA because the microcode is RISC-V assembly (software), not FPGA bitstream (hardware with minutes-per-iteration synthesis). The [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security model]] — unified memory, tagged architecture, no MMU — applies directly because the Tensix cores share the same address space. [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] economics apply: a certified Lisp Machine at scale replaces compliance hardware. See [[id:9af13fff-9725-542b-93b1-a555bc74ad72][why Lisp is economically viable now]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] for the economic and deployment foundations.
|
|
||||||
@@ -1,18 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 42c86e6f-4f27-4993-8238-b7bc7d15fb7b
|
|
||||||
:ID: c3b3dc41-945f-54e9-84eb-ca014114f1be
|
|
||||||
:END:
|
|
||||||
#+title: Stoa — The Porch (Environment)
|
|
||||||
#+filetags: :passepartout:stoa:editor:browser:hardware:
|
|
||||||
|
|
||||||
Stoa is the user environment — a single Lisp image where editor, browser, shell, and agent coexist.
|
|
||||||
|
|
||||||
**Roadmap:**
|
|
||||||
- v2.0.0: Lish editor + Nyxt browser (Stage 1, Qt/WebKit) + Lish shell
|
|
||||||
- v3.0.0+: Cannibalization — replace Qt with Lisp-native layout, reduce WebKit to pixel-painting, eventually pure-Lisp browser and window management
|
|
||||||
- v4.0.0: Native inference — llama.cpp FFI in-process, DSL-compiled model architectures, live surgery on cognition
|
|
||||||
- v5.0.0: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] — tagged RISC-V architecture via TinyTapeout, FPGA prototype, hardware GC via dedicated bus master
|
|
||||||
- v6.0.0: True agency — world models, temporal reasoning, goal persistence across restarts
|
|
||||||
|
|
||||||
The architectural principle: Stoa is not a collection of clients connecting to a daemon. The Dispatcher gate stack [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verifies every action]] regardless of who initiated it. The distinction between "tool" and "self" dissolves. The ultimate goal is a [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] running on custom hardware.
|
|
||||||
@@ -1,28 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: c3b3dc41-945f-54e9-84eb-ca014114f1be
|
|
||||||
:END:
|
|
||||||
#+title: Stoa — The Porch (Environment)
|
|
||||||
#+filetags: :passepartout:stoa:editor:browser:hardware:
|
|
||||||
|
|
||||||
Stoa (Στοά) is the body/environment layer of the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][triad]] — editor, browser, shell, and infrastructure all running in a single [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp image]]. The [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Dispatcher gate stack]] verifies every action regardless of who initiated it. The distinction between "tool" and "self" dissolves.
|
|
||||||
|
|
||||||
The full roadmap is documented across seven stages on this page, each covering engineering, security, cost, timeline, and practical implications. Start reading from [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]].
|
|
||||||
|
|
||||||
The three layers of the triad:
|
|
||||||
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]] — the mind: recorded discourse, verified reasoning, the gate
|
|
||||||
- Stoa — the porch: environment, infrastructure, the verified Lisp machine
|
|
||||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] — the society: identity, communication, contracts
|
|
||||||
|
|
||||||
Key features across all stages:
|
|
||||||
- **No kernel, no process boundaries, no memory corruption** — the verified Lisp evaluator is the only computation substrate
|
|
||||||
- **Merkle-verified memory graph** — every object has a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][structural hash]], composable proofs of integrity
|
|
||||||
- **[[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-stack authorization]]** — the Dispatcher is the only path to state mutation, verified in [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2]]
|
|
||||||
- **Dual-unit ASIC** — symbolic core (tagged RISC-V) + tensor unit (cons-cell-native matmul), one chip, one proof
|
|
||||||
- **In-process LLM inference** under [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-level token interception]] — no API calls, no sandbox to escape
|
|
||||||
- **Plist-native weights** — every weight Merkle-verified, provenance from training to inference
|
|
||||||
- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verified fine-tuning]]** — every gradient step authorized against policy, data consent per example
|
|
||||||
- **Neural world model** (LeCun type) — sensory-physical prediction, falsified against the accumulated observation DAG
|
|
||||||
- **Common sense** enters through three channels (LLM, world model, causal inference) and is brought under gate control through falsification
|
|
||||||
|
|
||||||
The ultimate goal is a [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] running on custom dual-unit silicon.
|
|
||||||
@@ -1,84 +0,0 @@
|
|||||||
---
|
|
||||||
title: Stage 0 — Now (Conventional Computing)
|
|
||||||
type: reference
|
|
||||||
tags: :stoa:roadmap:
|
|
||||||
created: 2026-05-24
|
|
||||||
---
|
|
||||||
|
|
||||||
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]]
|
|
||||||
|
|
||||||
# Stage 0: Now
|
|
||||||
|
|
||||||
*Summary: The conventional stack as it exists today. Not a design — the starting point.*
|
|
||||||
|
|
||||||
This is the baseline we inherit. Linux on x86, C/Rust toolchain,
|
|
||||||
web-based applications, GPU compute for AI, TCP/IP networking. Every layer
|
|
||||||
is independently built and independently untrusted.
|
|
||||||
|
|
||||||
The conventional stack spans every layer:
|
|
||||||
|
|
||||||
| Layer | Threats |
|
|
||||||
|-------+---------|
|
|
||||||
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] | silicon trojan, rowhammer, speculation side channels (spectre/meltdown), physical theft |
|
|
||||||
| Firmware | UEFI implants, SMM rootkits, ME backdoor — unaccountable opaque processors |
|
|
||||||
| OS kernel | privilege escalation, syscall bugs, driver exploits — CVEs weekly |
|
|
||||||
| Compiler | Ken Thompson's "Trusting Trust" — compiler backdoors invisible at source level |
|
|
||||||
| Runtime | heap corruption, use-after-free, buffer overflow — the dominant malware vector |
|
|
||||||
| Network | MITM, TLS state machine bugs, DNS poisoning, routing attacks |
|
|
||||||
| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain |
|
|
||||||
| User | phishing, social engineering, credential theft |
|
|
||||||
| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability |
|
|
||||||
|
|
||||||
**Key property:** Every layer is independent and untrusted. No layer can vouch
|
|
||||||
for any other. Security is *empirical* — "no bugs found in this release" — not
|
|
||||||
deductive.
|
|
||||||
|
|
||||||
## What is eliminated
|
|
||||||
|
|
||||||
Nothing. Every threat that has ever existed in computing exists at Stage 0.
|
|
||||||
|
|
||||||
## What does this cost?
|
|
||||||
|
|
||||||
- **Patching treadmill** — the industry spends uncountable hours applying CVEs.
|
|
||||||
Every OS update risks regressions. Security teams are measured by mean time
|
|
||||||
to detect, not mean time to prevent.
|
|
||||||
- **Incident response** — breaches are expected, not exceptional. The average
|
|
||||||
dwell time (attacker inside system before detection) is months.
|
|
||||||
- **Bug bounties** — a market failure tax: pay researchers to find the bugs
|
|
||||||
your toolchain inevitably produces.
|
|
||||||
- **Complexity tax** — every OS, driver, library, and daemon is a potential
|
|
||||||
entry point. The attack surface is unknowable because no layer can vouch
|
|
||||||
for any other.
|
|
||||||
- **No deductive guarantees** — security is empirical. "No bugs found in this
|
|
||||||
release" does not mean no bugs exist.
|
|
||||||
|
|
||||||
Even with all this spending, the system is not provably secure. You can't
|
|
||||||
audit your way to deductive guarantees on a conventional stack.
|
|
||||||
|
|
||||||
## What does this enable?
|
|
||||||
|
|
||||||
Everything we have. The entire software ecosystem, all hardware, every network.
|
|
||||||
The cost and the capability are the same thing — maximum flexibility, minimum
|
|
||||||
provable trust.
|
|
||||||
|
|
||||||
## When is this viable?
|
|
||||||
|
|
||||||
Today. This is where we are.
|
|
||||||
|
|
||||||
## In practice
|
|
||||||
|
|
||||||
We have normalized reactive security because the alternative — building a
|
|
||||||
provably secure stack — is considered too expensive. Every company of
|
|
||||||
meaningful size has a security team whose job is to detect when they've been
|
|
||||||
breached, not to prevent it. The average dwell time is measured in months.
|
|
||||||
This is treated as normal because the alternative — a provably secure stack —
|
|
||||||
is seen as prohibitively expensive. This roadmap is the argument that the
|
|
||||||
provable alternative is not only possible, but the inevitable destination.
|
|
||||||
The question is not whether to build it, but at what pace.
|
|
||||||
|
|
||||||
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]]
|
|
||||||
|
|
||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 4a1f23b0-abc1-4def-9876-543210abcdef
|
|
||||||
:END:
|
|
||||||
@@ -1,85 +0,0 @@
|
|||||||
---
|
|
||||||
title: Stage 1 — Agora (In-Transit Integrity)
|
|
||||||
type: reference
|
|
||||||
tags: :stoa:roadmap:agora:
|
|
||||||
created: 2026-05-24
|
|
||||||
---
|
|
||||||
|
|
||||||
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]]
|
|
||||||
|
|
||||||
# Stage 1: [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]
|
|
||||||
|
|
||||||
*Summary: Every message is signed, DAG-tracked, and content-addressed.
|
|
||||||
Communication becomes provable — when you choose it to be.*
|
|
||||||
|
|
||||||
## What is added
|
|
||||||
|
|
||||||
- DID-based identity per participant (Ed25519 key pairs)
|
|
||||||
- Message-level authentication via JWE/JWS envelopes
|
|
||||||
- DAG of content-addressed messages for auditable history
|
|
||||||
- Channels for directed and broadcast communication
|
|
||||||
- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy
|
|
||||||
- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC)
|
|
||||||
- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording)
|
|
||||||
- Pseudonymous Personas for deniable identity
|
|
||||||
- Relays as transient routers (pub/sub model, no long-term storage)
|
|
||||||
- Onion routing between PDSs for metadata masking
|
|
||||||
|
|
||||||
## What is eliminated
|
|
||||||
|
|
||||||
- **Message forgery** — every message is signed; you prove the sender
|
|
||||||
- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain
|
|
||||||
- **Impersonation / spoofing** — DID identity keys, not usernames
|
|
||||||
- **Replay attacks** — nonces and sequence numbers per message
|
|
||||||
- **MITM on Agora-mediated channels** — end-to-end signatures; relays need no trust
|
|
||||||
- **Loss of message history** — DAG is append-only and content-addressed
|
|
||||||
|
|
||||||
## What does this cost?
|
|
||||||
|
|
||||||
- **Crypto overhead per message** — every message requires signing and verification.
|
|
||||||
For high-throughput channels, this adds latency and CPU cost
|
|
||||||
- **DAG storage grows unbounded** — the append-only log never shrinks unless GC
|
|
||||||
is explicitly designed
|
|
||||||
- **Key management burden** — DID resolution, key rotation, revocation. Lost keys
|
|
||||||
mean lost identity. No "reset password" for DIDs
|
|
||||||
- **No anonymous participation by default** — DIDs tie every message to a
|
|
||||||
cryptographic identity. Pseudonymity is a Persona choice, not the baseline
|
|
||||||
|
|
||||||
## What does this enable?
|
|
||||||
|
|
||||||
Provable communication infrastructure. You can prove who said what, when, and
|
|
||||||
to whom — or choose off-the-record privacy. Every subsequent stage builds on
|
|
||||||
this DAG: it is the source of truth for evidence, audit, and the accumulated
|
|
||||||
knowledge that later stages use for falsification.
|
|
||||||
|
|
||||||
## When is this viable?
|
|
||||||
|
|
||||||
Today. Agora is a protocol design that can be deployed on existing networks.
|
|
||||||
The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]].
|
|
||||||
|
|
||||||
## In practice
|
|
||||||
|
|
||||||
Communication becomes provable — but only when the user chooses. Agora's Note
|
|
||||||
primitive supports the full spectrum: persistent DAG-stored messages for audit
|
|
||||||
and compliance, ephemeral Notes that self-destruct, and full Off-the-Record
|
|
||||||
(OTR) mode that bypasses PDS storage entirely.
|
|
||||||
|
|
||||||
The user chooses per-channel or per-message: permanent and attributable for
|
|
||||||
contracts and governance, ephemeral and deniable for private conversation. The
|
|
||||||
infrastructure enforces each choice — PDS garbage-collects expired CIDs, Relays
|
|
||||||
drop them from routing tables, clients shed message keys after display. Agora
|
|
||||||
replaces trust with evidence where evidence is wanted; elsewhere it provides
|
|
||||||
privacy by design.
|
|
||||||
|
|
||||||
Agora does not secure the endpoint. The machines running Agora clients can
|
|
||||||
still be compromised at the OS, compiler, or hardware level. The keys are on
|
|
||||||
those machines — malware that compromises an endpoint can sign messages using
|
|
||||||
the endpoint's keys. The messages are authentic; the sender wasn't. Agora
|
|
||||||
carries the authorization; it doesn't evaluate it.
|
|
||||||
|
|
||||||
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]]
|
|
||||||
|
|
||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 4a1f23b0-abc2-4def-9876-543210abcdef
|
|
||||||
:END:
|
|
||||||
@@ -1,84 +0,0 @@
|
|||||||
---
|
|
||||||
title: Stage 2 — Logos (Verified Reasoning Layer)
|
|
||||||
type: reference
|
|
||||||
tags: :stoa:roadmap:logos:
|
|
||||||
created: 2026-05-24
|
|
||||||
---
|
|
||||||
|
|
||||||
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]]
|
|
||||||
|
|
||||||
# Stage 2: [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]]
|
|
||||||
|
|
||||||
*Summary: A verified gate evaluates every action against formal policy.
|
|
||||||
Capability-based authorization. "Root" as an attack target no longer exists.*
|
|
||||||
|
|
||||||
## What is added
|
|
||||||
|
|
||||||
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action
|
|
||||||
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity
|
|
||||||
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against:
|
|
||||||
- Is the action authorized by policy?
|
|
||||||
- Does the capability grant this operation?
|
|
||||||
- Does the action violate any system invariant?
|
|
||||||
- Decision procedure formalized in ACL2, machine-checked
|
|
||||||
- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]])
|
|
||||||
|
|
||||||
## What is eliminated
|
|
||||||
|
|
||||||
- **Unauthorized actions** — even a fully compromised endpoint cannot perform an
|
|
||||||
action the gate blocks. The gate is the final arbiter, not the OS or client.
|
|
||||||
- **Privilege escalation** — no amount of subversion below the gate can grant
|
|
||||||
capabilities the policy doesn't allow. The gate checks capability tokens,
|
|
||||||
not caller identity.
|
|
||||||
- **"Root" as a meaningful attack target** — there is no root in Logos. There
|
|
||||||
are capabilities, and capabilities are checked.
|
|
||||||
|
|
||||||
## What does this cost?
|
|
||||||
|
|
||||||
- **Verification latency** — every action is checked against policy. Complex
|
|
||||||
policies add delay
|
|
||||||
- **Policy formalization burden** — everything must be written explicitly. Gaps
|
|
||||||
block legitimate actions (false positives) or allow undesirable ones (false
|
|
||||||
negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on
|
|
||||||
unformalized human intuition. Everything must be written down
|
|
||||||
- **Capability management complexity** — distributing, revoking, auditing
|
|
||||||
capabilities is itself security-critical. A leaked capability is
|
|
||||||
indistinguishable from an authorized action
|
|
||||||
- **Policy drift** — as the system evolves, the policy must evolve with it.
|
|
||||||
Out-of-date policy blocks new legitimate uses
|
|
||||||
- **Proof maintenance** — the gate's decision procedure is verified, but the
|
|
||||||
policy is not. Each policy change needs new proof
|
|
||||||
- **The gate runs on untrusted hardware** — if the OS or hardware is
|
|
||||||
compromised, the gate's guarantees are meaningless. The attacker can skip
|
|
||||||
the gate or modify its output. Logos's full power arrives at Stage 3
|
|
||||||
|
|
||||||
## What does this enable?
|
|
||||||
|
|
||||||
The system can now say "no" to unauthorized actions even when the endpoint is
|
|
||||||
fully compromised. Security is no longer dependent on client integrity. This is
|
|
||||||
the first layer where deductive guarantees enter the picture — but they are
|
|
||||||
contingent on Stage 3's trust substrate.
|
|
||||||
|
|
||||||
## When is this viable?
|
|
||||||
|
|
||||||
Today as a software layer on conventional hardware, but with limited guarantees
|
|
||||||
(the gate itself can be compromised by the host OS). Full power arrives at
|
|
||||||
Stage 3 when the gate runs on the verified Lisp machine.
|
|
||||||
|
|
||||||
## In practice
|
|
||||||
|
|
||||||
The gate is the final arbiter, not the OS or the client. But it runs on a
|
|
||||||
machine it doesn't trust. Users must weigh the benefit (unauthorized actions
|
|
||||||
blocked) against the operational cost (everything must be explicitly authorized
|
|
||||||
in policy). For high-stakes environments, the trade-off is worth it. For casual
|
|
||||||
use, the friction may lead users to bypass the gate.
|
|
||||||
|
|
||||||
*Logos's full power arrives when it runs on Stoa. Before that, it's a
|
|
||||||
correctness proof running on an untrusted substrate.*
|
|
||||||
|
|
||||||
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]]
|
|
||||||
|
|
||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 4a1f23b0-abc3-4def-9876-543210abcdef
|
|
||||||
:END:
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
---
|
|
||||||
title: Stoa Vision Roadmap — The Porch
|
|
||||||
type: reference
|
|
||||||
tags: :reference:architecture:stoa:
|
|
||||||
created: 2026-05-24
|
|
||||||
---
|
|
||||||
|
|
||||||
→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]]
|
|
||||||
|
|
||||||
Stoa (Στοά) is the body/environment layer of the [[id:d71df46b-9012-433c-86ce-ec21b78eac5f][triad]]:
|
|
||||||
|
|
||||||
| Logos | The mind — recorded discourse (memex + agent) |
|
|
||||||
| Stoa | The porch — editor, browser, shell, infrastructure |
|
|
||||||
| [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | The society — identity, communication, contracts |
|
|
||||||
|
|
||||||
The name comes from the Stoa Poikile (Painted Porch) in ancient Athens,
|
|
||||||
where Zeno taught Stoic philosophy. The porch was not the philosophy
|
|
||||||
itself — it was the environment that made discourse possible. Stoa is
|
|
||||||
the same: not the agent, not the network, but the infrastructure that
|
|
||||||
hosts both.
|
|
||||||
|
|
||||||
The roadmap and threat model are merged into a single document.
|
|
||||||
Each stage covers: what is added, what threats are eliminated, what it
|
|
||||||
costs, what it enables, when it is viable, and what it means in practice.
|
|
||||||
Appendices at the end cover common sense, the bootstrap axiom, and a
|
|
||||||
summary table of eliminated threats.
|
|
||||||
|
|
||||||
| Stage | Delivers | Key cost | Timeline |
|
|
||||||
|-------+----------+----------+----------|
|
|
||||||
| [[id:4a1f23b0-abc1-4def-9876-543210abcdef][0 — Now]] | Baseline: conventional computing | Patching treadmill, no deductive guarantees | Today |
|
|
||||||
| [[id:4a1f23b0-abc2-4def-9876-543210abcdef][1 — Agora]] | Communication integrity, provable DAG | Crypto overhead, key management | Today |
|
|
||||||
| [[id:4a1f23b0-abc3-4def-9876-543210abcdef][2 — Logos]] | Verified gate, capability auth | Policy formalization burden | Today (limited) |
|
|
||||||
| [[id:4a1f23b0-abc4-4def-9876-543210abcdef][3 — Stoa]] | Lisp machine, Merkle memory, no kernel | Lisp tax, no backward compat, single address space | 2-5yr (soft) / 5-10yr (ASIC) |
|
|
||||||
| [[id:4a1f23b0-abc5-4def-9876-543210abcdef][4 — Inference]] | In-process LLM, token interception | ~10x compute/RAM/storage | Server now; consumer 3-5yr |
|
|
||||||
| [[id:4a1f23b0-abc6-4def-9876-543210abcdef][5 — Weights]] | Plist-native weights, weight-level provenance | ~100x GPU / ~2-5x ASIC | GPU hybrid now; ASIC 5-10yr |
|
|
||||||
| [[id:4a1f23b0-abc7-4def-9876-543210abcdef][6 — Training]] | Verified fine-tuning, neural world model | ~100x fine-tuning only | 3-5yr fine-tuning |
|
|
||||||
| [[id:4a1f23b0-abc8-4def-9876-543210abcdef][7 — Remaining]] | Physical threats, oracles, speculation, bootstrap axiom | Mitigations are non-computational | Forever |
|
|
||||||
|
|
||||||
→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]]
|
|
||||||
|
|
||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 3f24ad65-0845-4e75-a3d7-dc4de734a6ac
|
|
||||||
:END:
|
|
||||||
@@ -1,45 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
|
|
||||||
:END:
|
|
||||||
#+title: Passepartout Triad — Knowledge Base
|
|
||||||
#+filetags: :passepartout:triad:economics:index:
|
|
||||||
|
|
||||||
The triad replaces every layer of the modern computing stack with Lisp-native, user-owned, ACL2-verified alternatives. Three components:
|
|
||||||
|
|
||||||
- [[id:a1fac32a-47de-5fbd-b67d-29152c851747][Logos (Passepartout) — the cognitive agent]]
|
|
||||||
- [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Stoa (The Porch) — the environment]]
|
|
||||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora (The Society) — the network]]
|
|
||||||
|
|
||||||
Total addressable market: ~$960B/year across cloud, AI, OS, social media, payments, productivity, and compliance.
|
|
||||||
|
|
||||||
The business model is the AWS of provable computing: AGPL infrastructure is free, revenue comes from verification appliances, gate rules, certification, namespace registry, hosted PDS, and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. Network effects are positive sum — every instance feeds the regression suite and grows the marketplace.
|
|
||||||
|
|
||||||
[[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp Machine security — unified memory threat model]]
|
|
||||||
[[id:04c2f221-c54f-51e5-b40a-48822cd16d45][Common Logic (ISO 24707) — relevance to the triad]]
|
|
||||||
[[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][Collective regression suite — how it compounds]]
|
|
||||||
|
|
||||||
Key analytical frames:
|
|
||||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis — the unified view]]
|
|
||||||
- [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Why Lisp is economically viable now]]
|
|
||||||
- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][The per-domain sufficiency flip]]
|
|
||||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development velocity and timeline estimates]]
|
|
||||||
- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]]
|
|
||||||
- [[id:aa6d062e-a520-5d14-8773-00687ed9c689][Competitive moats analysis]]
|
|
||||||
|
|
||||||
Revenue paths (short to long term):
|
|
||||||
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]][[id:c34940cc-090e-57c4-8020-e78b1d32b96c][ Domain gate packages]][[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][ Evaluation harness]]
|
|
||||||
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Agora premium usernames]][[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][ PDS as a service]][[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][ Compute marketplace]]
|
|
||||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly — the big money]][[id:2f783eb4-638e-5afa-9b59-6224d086a712][ Infrastructure lock-in]]
|
|
||||||
|
|
||||||
Strategy and IP:
|
|
||||||
- [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][Patent strategy]][[id:67faf52f-9126-50a7-b87e-2bedc610dac7][ Licensing (AGPL + commercial)]]
|
|
||||||
- [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][Impact on the AI/GPU industry]]
|
|
||||||
- [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade and distribution lifecycle]]
|
|
||||||
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate rule encoding from codified domains]]
|
|
||||||
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]]
|
|
||||||
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]]
|
|
||||||
|
|
||||||
The [[id:b25bf753-9799-41ab-82f5-1a1416db756b][Agora protocol overview]] and [[id:a3243dd0-3209-423b-98e1-51c3eada2658][advanced integration]] requirements define how the gate stack connects to Agora's network layer. The [[id:72570648-d943-42e5-a781-3b09791ac6ec][realistic assessment]] covers deployment timelines and adoption risks.
|
|
||||||
|
|
||||||
*The lines that run the modern internet (tens of millions across Google, Meta, Amazon, Apple, Microsoft) are replaced by a single coherent architecture where one gate stack verifies everything and one prover proves everything consistent.*
|
|
||||||
@@ -1,16 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: a1fac32a-47de-5fbd-b67d-29152c851747
|
|
||||||
:END:
|
|
||||||
#+title: Triad Overview — Logos, Stoa, Agora
|
|
||||||
#+filetags: :passepartout:triad:architecture:
|
|
||||||
|
|
||||||
The full triad is a self-bootstrapping replacement for the entire computing stack, not a single product.
|
|
||||||
|
|
||||||
**Logos ([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]])** — The mind. Cognitive agent combining a probabilistic LLM (10% of work) with a deterministic symbolic engine (80%) at near-zero marginal cost. Gate stack, fact store, ACL2 prover, Screamer constraint solver.
|
|
||||||
|
|
||||||
**Stoa (The Porch)** — The body. Editor (Lish), browser (Nyxt), shell (Lish), Org-mode filesystem, Qt/EQL5 UI. A single Lisp image where everything coexists. Roadmap: v2.0.0 (Qt/WebKit) → v6.0.0 (pure Lisp, hardware).
|
|
||||||
|
|
||||||
**Agora (The Society)** — The network. Self-sovereign DID identity, DIDComm encrypted messaging, [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][Personal Data Store]], Relay Network, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], liquid democracy.
|
|
||||||
|
|
||||||
All three speak plists. All three operate in Lisp address space. All three are verified by the same ACL2 prover. The gate stack that verifies a shell command also verifies a DIDComm message. See [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][The See the [[id:b25bf753-9799-41ab-82f5-1a1416db756b][Agora protocol overview]] for how the three triad components fit into Agora's network architecture. [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][The investment thesis]]]] for the economic rationale and [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] for the hardware that enables this unified architecture.
|
|
||||||
@@ -1,16 +0,0 @@
|
|||||||
:PROPERTIES:
|
|
||||||
:CREATED: [2026-05-24 Sun]
|
|
||||||
:ID: 827bc546-e887-5b7c-9b65-6392beaf0920
|
|
||||||
:END:
|
|
||||||
#+title: The Verification Monopoly (UL for AI)
|
|
||||||
#+filetags: :passepartout:economics:monopoly:certification:big-money:
|
|
||||||
|
|
||||||
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness ever assembled.
|
|
||||||
|
|
||||||
Any organization claiming a "safe AI agent" needs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] certification to prove it. This is Underwriters Laboratory for AI — a certification nobody can ignore.
|
|
||||||
|
|
||||||
**Revenue:** [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] the certification mark to every AI vendor that ships an agent. **Margins:** near-100% once the suite exists.
|
|
||||||
|
|
||||||
This is the venture-scale outcome. It depends on the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] reaching critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]] is built on the recognition that every deployed instance makes this more valuable.
|
|
||||||
|
|
||||||
The unique structural advantage: every free instance of the triad feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] and powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry]], where safety certification becomes a prerequisite for market access.
|
|
||||||
74
ideas/viability/open-source-wolfram-lisp.org
Normal file
74
ideas/viability/open-source-wolfram-lisp.org
Normal file
@@ -0,0 +1,74 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
|
||||||
|
:END:
|
||||||
|
#+title: Viability of an Open-Source Wolfram Language / Mathematica in Common Lisp
|
||||||
|
#+filetags: :ideas:lisp:mathematics:open-source:
|
||||||
|
|
||||||
|
An assessment of what it would take to build a viable open-source equivalent of Wolfram Language and Mathematica in Common Lisp, based on the existing ecosystem and the fundamental architectural alignment between Lisp and symbolic computation.
|
||||||
|
|
||||||
|
**The alignment is natural, not forced.**
|
||||||
|
|
||||||
|
Wolfram Language is, at its core, a term-rewriting system with pattern matching, rule-based transformation, and a uniform symbolic representation for everything (expressions are trees of the form head[arg1, arg2, ...] — the Wolfram equivalent of cons cells). This is very close to what Lisp is natively. A Lisp implementation of the core evaluator — pattern matching, rule application, substitution, term rewriting — is not a foreign port. It is an exercise in expressing Wolfram's semantics in a language whose semantics were designed for the same problem domain.
|
||||||
|
|
||||||
|
Maxima proves this historically. It is a direct descendant of Macsyma, the MIT computer algebra system that inspired Mathematica. Macsyma was written in Lisp. Mathematica's core evaluation model inherits heavily from Macsyma. An open-source Common Lisp computer algebra system already exists, has existed for decades, and works. The question is not whether it can be done, but how much of the modern Mathematica ecosystem can be replicated and at what cost.
|
||||||
|
|
||||||
|
**What already exists.**
|
||||||
|
|
||||||
|
| Layer | Existing CL work | Status |
|
||||||
|
|---|---|---|
|
||||||
|
| Symbolic engine / term rewriting | Lisp readers, pattern matching libs (trivia, optima, fare-matcher), rule systems | Foundational primitives exist, no unified Wolfram-equivalent evaluator |
|
||||||
|
| Computer algebra system | Maxima, FriCAS (Axiom), reduce-algebra | Mature CASes — Maxima alone has differentiation, integration, ODEs, linear algebra, tensors, series, limits, Laplace transforms |
|
||||||
|
| Numerical computing | magicl, lla (Lisp Linear Algebra), CL-NUM, GSLL (GNU Scientific Library bindings) | Solid — covers BLAS, LAPACK, random numbers, special functions, optimization |
|
||||||
|
| Visualization | cl-cairo2, Vecto, CLG, CommonQt, cl-zxing | Exists but scattered — no unified plotting framework like Mathematica's |
|
||||||
|
| Notebook interface | cl-jupyter, common-lisp-jupyter, Lem | Jupyter kernel works. Lem is a native editor approaching notebook capability. No Mathematica-level notebook yet. |
|
||||||
|
| Rule-based programming | fare-matcher, optima, prolog implementations | Pattern matching is good. Full term-rewriting system needs assembly. |
|
||||||
|
| Knowledge graph | gbrain, various triplestore libs | Possible but would need Wolfram Alpha-level investment |
|
||||||
|
| Deployment | ASDF, Quicklisp, SBCL standalone executables | Better than Mathematica's deployment story — Lisp produces real executables |
|
||||||
|
|
||||||
|
**The hard parts.**
|
||||||
|
|
||||||
|
1. **The standard library is the product, not the engine.** Mathematica ships thousands of built-in functions — every mathematical special function, every statistical distribution, every graph algorithm, every image processing filter, every string operation, every data format parser. This is not a technical challenge; it is a sheer volume problem. The open-source answer is to wrap existing C/C++ libraries (GSL for special functions, OpenCV for image processing, igraph for graph algorithms, etc.) and expose them through a unified symbolic interface. This is the Clasp approach: interop with mature C++ libraries rather than rebuilding everything from scratch in Lisp. The Wolfram equivalent would be a CLOS-based symbolic dispatch layer that wraps these libraries and makes them accessible through a consistent term-rewriting evaluator.
|
||||||
|
|
||||||
|
2. **The notebook interface is a product in itself.** Mathematica's notebook is not a terminal with nice formatting. It is a computational notebook with inline typeset math, dynamic graphics, collapsible sections, live evaluation, and a rich document model. The Jupyter ecosystem solves half of this. A Lisp-native notebook would need a rendering engine for mathematical notation (LaTeX or MathJax integration), inline interactive graphics, and a document model compatible with literate computation. Lem is the most promising starting point — it already has Emacs-like extensibility, a GTK frontend, and a Lisp-native codebase. Extending Lem to support computational notebooks with inline graphics and typeset output is the shortest path.
|
||||||
|
|
||||||
|
3. **Performance for specialized domains.** Mathematica's kernel is highly optimized for symbolic operations — pattern matching over large expressions, automatic algorithm selection, memoization, and incremental compilation. A naive Lisp implementation would match Mathematica for small-to-medium expressions but would need significant optimization work for the heavy cases (symbolic integration of large expressions, graph operations on million-node graphs, image processing pipelines). The advantage is that Lisp's compiler infrastructure (SBCL's type inference, VOPs, inlining) gives a much better baseline than most languages. SBCL can generate code that approaches C speed for numerical kernels.
|
||||||
|
|
||||||
|
4. **The knowledge graph (Wolfram Alpha).** Mathematica's integration with Wolfram Alpha — querying computable data about chemistry, geography, finance, linguistics, etc. — is a separate product with a massive engineering investment in data curation. An open-source equivalent would not replicate this. It would either provide a local, user-curatable knowledge base (gbrain fits here) or integrate with existing open knowledge graphs (Wikidata, DBpedia). The gbrain connection is interesting: if Passepartout's knowledge store can answer factual queries with provenance, that becomes the Wolfram Alpha equivalent for the Lisp Mathematica.
|
||||||
|
|
||||||
|
5. **Package ecosystem and community.** Mathematica's advantage is not just its engine but its ecosystem — thousands of paclets, the Wolfram Function Repository, the community that shares notebooks. An open-source equivalent needs a package manager (Quicklisp solves this for Lisp libraries), a repository for symbolic packages (a Wolfram Function Repository equivalent), and a critical mass of users who both use and contribute. Maxima has users but not contributors. The gap is community formation, not technical capability.
|
||||||
|
|
||||||
|
**The viability assessment.**
|
||||||
|
|
||||||
|
| Domain | Viability | Timeline estimate | Risk |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Core symbolic evaluator | High — Lisp was designed for this | 6-12 months for working prototype | Low — well-understood problem |
|
||||||
|
| Computer algebra | High — Maxima already exists | Integrate now; polish 1-2 years | Low — needs UI/UX investment |
|
||||||
|
| Numerical computing | High — wrappers exist | 3-6 months for unified interface | Low — wrapping problem |
|
||||||
|
| Visualization | Medium — scattered pieces | 1-2 years for unified framework | Medium — needs new work |
|
||||||
|
| Notebook interface | Medium — Lem as foundation | 1-2 years to Mathematica parity | Medium — significant UX engineering |
|
||||||
|
| Standard library breadth | Low — volume problem | 3-5 years with community | High — needs sustained contribution |
|
||||||
|
| Knowledge graph | Low — curation cost | 2-3 years for basic integration | High — different product category |
|
||||||
|
| Deployment | High — Lisp executables | Works now | None |
|
||||||
|
|
||||||
|
**The strategic question.**
|
||||||
|
|
||||||
|
The real question is not "can we replicate Mathematica in Lisp" but "should we?" — and if so, for whom.
|
||||||
|
|
||||||
|
Mathematica serves two distinct use cases:
|
||||||
|
|
||||||
|
- **Interactive exploration** — a researcher types an integral, gets a result, visualizes it, iterates. Lisp + Maxima + a good notebook interface already does this, and the experience is competitive for anyone comfortable with Lisp syntax.
|
||||||
|
- **Deployed computation** — a company builds a production pipeline around Mathematica kernels, deploying computation as a service. Lisp executables are dramatically better here — they are real compiled binaries, not managed by a proprietary kernel, deployable without license fees, embeddable anywhere.
|
||||||
|
|
||||||
|
For the second use case, the open-source Lisp alternative is already superior. The gap is the first use case: the interactive exploration experience, the breadth of built-in functions, and the cultural acceptance of Lisp syntax in communities that currently write Wolfram Language.
|
||||||
|
|
||||||
|
The most viable path is not to clone Mathematica but to integrate Maxima + numerical Lisp libraries under a unified symbolic interface, expose all of it through a Lem-based notebook, and make the Jupyter bridge the primary entry point for users who prefer Python notebooks. This gives you 80% of Mathematica's capability with a fraction of the development cost, and it connects to the existing scientific Python ecosystem rather than competing with it.
|
||||||
|
|
||||||
|
**The deeper point.**
|
||||||
|
|
||||||
|
Mathematica's architecture is Lisp-like because it was inspired by a Lisp system (Macsyma). An open-source Mathematica in Lisp is not a port. It is a return to the original architectural vision, implemented in the language that vision was originally expressed in. The question is whether the community investment materializes — and that depends on whether there is a use case that justifies it. Passepartout's verification infrastructure may be that use case: a verified symbolic computation engine that reasons about its own results is a Mathematica-like system by necessity, and building it in Lisp is the natural path.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
- [[id:f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f][Schafmeister and Clasp]] — Lisp in computational nanotechnology, existence proof for Lisp viability in scientific computing
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp and where the symbolic engine fits
|
||||||
92
ideas/viability/passepartout-bootstrap-mathematica.org
Normal file
92
ideas/viability/passepartout-bootstrap-mathematica.org
Normal file
@@ -0,0 +1,92 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 8b9c0d1e-2f3a-4b5c-6d7e-8f9a0b1c2d3e
|
||||||
|
:END:
|
||||||
|
#+title: Could Passepartout Bootstrap Mathematica or mathlib by Itself?
|
||||||
|
#+filetags: :ideas:lisp:passepartout:mathematics:
|
||||||
|
|
||||||
|
This extends the previous viability analysis with a specific scenario: assuming Passepartout exists at Stage 3+ (full Lisp machine with neurosymbolic engine, verification gate, and self-modification capability), how hard would it be for it to recreate Mathematica or mathlib in pure Common Lisp on its own?
|
||||||
|
|
||||||
|
**The bootstrap is architectural, not aspirational.**
|
||||||
|
|
||||||
|
The neurosymbolic engine is not just a faster way to write code. It is a closed loop: the LLM proposes implementations, the symbolic engine and ACL2 prover verify correctness, and the self-modification system hot-reloads the result into the running image. This loop runs autonomously, without human intervention. The system writes code, tests it formally, improves it, and keeps the result — permanently expanding its own capability.
|
||||||
|
|
||||||
|
This is fundamentally different from a human writing Mathematica. A human writes code, compiles, tests, debugs. Passepartout writes code, has it verified against a formal specification, and loads it into its own runtime. The iteration speed is not hours or days — it is seconds per function, limited only by the LLM's generation latency and the prover's checking time.
|
||||||
|
|
||||||
|
**What Passepartout already has.**
|
||||||
|
|
||||||
|
At Stage 3, the system ships with:
|
||||||
|
|
||||||
|
- A symbolic term-rewriting engine (the evaluator itself is one)
|
||||||
|
- Pattern matching and rule-based transformation (native to the gate architecture)
|
||||||
|
- ACL2 as a verification backend (can prove properties of generated code)
|
||||||
|
- An LLM oracle for proposing implementations (the probabilistic brain)
|
||||||
|
- A self-modification system (hot-reloads verified code into the running image)
|
||||||
|
- A knowledge store with persistent facts (gbrain-derived)
|
||||||
|
|
||||||
|
These are not general-purpose tools that happen to be useful for symbolic mathematics. They are the same tools that a computer algebra system needs, expressed in the same architecture. The evaluator that rewrites a gate policy is the same mechanism that rewrites a symbolic expression.
|
||||||
|
|
||||||
|
**What it needs to generate.**
|
||||||
|
|
||||||
|
| Component | Can Passepartout generate it? | How |
|
||||||
|
|---|---|---|
|
||||||
|
| Core symbolic evaluator | Yes, trivially — this is what Lisp *is* | The existing evaluator already does term rewriting. The neurosymbolic engine would create a higher-level pattern-matching layer over it. |
|
||||||
|
| Computer algebra (differentiation, integration, simplification) | Yes — known algorithms, formally specifiable | LLM proposes implementation of Risch algorithm, polynomial GCD, Gröbner bases. ACL2 verifies the specification. |
|
||||||
|
| Numerical libraries (BLAS, special functions, optimization) | Partial — better to wrap | ACL2 cannot verify floating-point numerics to the same standard. Passepartout would wrap existing C/C++ libraries via Clasp-style interop and verify the interface, not the numerics. |
|
||||||
|
| Visualization framework | Yes — UI code, not math | The environment subsystem (Nyxt/Lish) already has rendering primitives. The neurosymbolic engine generates plotting and graphics code against them. |
|
||||||
|
| The 5,000+ function standard library | Yes — volume, not novelty | This is the dominant cost. Each function is individually trivial (differentiate x^3 → 3x^2) but there are thousands. Passepartout generates them at LLM speed — roughly one function every 10-30 seconds including verification. |
|
||||||
|
| Formal proofs of mathematical theorems (mathlib) | Qualified yes — different logic | mathlib is in Lean's dependent type theory. Passepartout's ACL2 is first-order logic. The theorems can be re-proven in ACL2, but the proofs are not portable. The LLM proposes proof strategies, ACL2 checks them. |
|
||||||
|
|
||||||
|
**The rate limit is generation, not computation.**
|
||||||
|
|
||||||
|
If Passepartout generates one verified function every 20 seconds (conservative — LLM proposal time + ACL2 verification), that is 180 functions per hour, ~4,300 per day. Mathematica's standard library contains roughly 6,000 documented functions. At this rate, the standard library would take ~1.5 days of continuous generation — assuming the LLM has the domain knowledge to produce correct implementations and ACL2 can verify them.
|
||||||
|
|
||||||
|
This is the critical assumption. The LLM (at, say, GPT-4 or DeepSeek level) already knows what every Mathematica function does. It has seen them in training data. The question is whether it can generate a correct Lisp implementation with a formal specification that ACL2 can verify. For most elementary functions (differentiate, integrate polynomial, singular value decomposition, string split, image histogram), the answer is yes — these are well-understood algorithms with clear specifications.
|
||||||
|
|
||||||
|
For specialized domains (elliptic curve cryptography, tensor network contractions, symbolic regression of differential equations), the LLM may generate approximately correct implementations that need refinement. The neurosymbolic loop handles this: ACL2 catches the mismatch, feeds the error back, and the LLM regenerates.
|
||||||
|
|
||||||
|
**mathlib is a different problem.**
|
||||||
|
|
||||||
|
mathlib is not a library of algorithms but a library of formal proofs — mathematical theorems expressed in Lean's dependent type theory, structured as a hierarchy of definitions, lemmas, and tactics. It represents hundreds of person-years of community effort, formalizing undergraduate mathematics and beyond.
|
||||||
|
|
||||||
|
Passepartout's verification layer is ACL2, which operates in a different logical framework (first-order logic with induction for total functions, not dependent types). There is no porting mathlib — it would have to be re-proven in ACL2's logic.
|
||||||
|
|
||||||
|
The advantage is that the theorems are already known. mathlib tells you exactly what to prove. The LLM reads the Lean statement, translates it to an ACL2 theorem, proposes a proof strategy, and ACL2 attempts the proof. This is a well-structured task for the neurosymbolic loop: the LLM generates proof plans, ACL2 verifies them, and failed attempts feed back to refine the next plan.
|
||||||
|
|
||||||
|
The bootstrapping advantage: early proofs (basic arithmetic, set theory) strengthen the ACL2 reasoning library, which makes later proofs (real analysis, topology) faster. The system accelerates as it goes. mathlib's proof dependency graph is the natural generation order.
|
||||||
|
|
||||||
|
Estimated timeline for mathlib-equivalent in ACL2, with Passepartout generating autonomously:
|
||||||
|
|
||||||
|
| Milestone | Time estimate | Note |
|
||||||
|
|---|---|---|
|
||||||
|
| Basic arithmetic, algebra, number theory | Days — standard library material | Well-known proofs, simple structure |
|
||||||
|
| Real analysis, measure theory | Weeks — proof complexity increases | Non-trivial but well-studied |
|
||||||
|
| Abstract algebra (groups, rings, fields) | Weeks — structural, builds on itself | The neurosymbolic loop excels here |
|
||||||
|
| Topology, algebraic topology | Months — conceptual depth | Proofs are longer, more strategic |
|
||||||
|
| Category theory, homological algebra | Months — abstraction barrier | High-level abstraction, fewer verification primitives |
|
||||||
|
| Number theory deep results (FLT, modular forms) | Unknown — research frontier | Passepartout is not proving open problems. It formalizes known results. |
|
||||||
|
|
||||||
|
**The bootstrapping compound effect.**
|
||||||
|
|
||||||
|
The most interesting property is not that Passepartout can generate Mathematica's library. It is that each generated function becomes part of Passepartout's own capability. After generating the differentiation function, Passepartout uses it to generate the integration function. After generating linear algebra, it uses that to generate optimization algorithms. After generating formal proofs of real analysis, it uses those theorems to verify more complex deductions.
|
||||||
|
|
||||||
|
This is not a production pipeline. It is an autodidactic loop: the system generates math, then uses that math to generate more math. The acceleration is exponential in the early phases and linear in the later phases, limited by the rate at which the LLM can produce new correct specifications.
|
||||||
|
|
||||||
|
**The real barrier is not technical but oracular.**
|
||||||
|
|
||||||
|
At every step, Passepartout depends on the LLM's knowledge of existing mathematics. The LLM has seen most of human mathematical knowledge in its training data. It can propose correct implementations and proof strategies because it has seen them. But for genuinely new mathematics — theorems not present in the training data, algorithms that have not been discovered — the LLM has no signal. Passepartout would be limited by its oracle.
|
||||||
|
|
||||||
|
Stage 7 acknowledges this: oracular limits are fundamental. The verification subsystem can check correctness against a specification, but it cannot generate the specification itself. The LLM provides the what; ACL2 verifies the that. Neither provides the why that extends beyond existing knowledge.
|
||||||
|
|
||||||
|
**Conclusion.**
|
||||||
|
|
||||||
|
Recreating Mathematica's standard library: **days to weeks** of autonomous generation. The volume problem is solvable because the LLM already knows the answer space and ACL2 can verify each function. No human intervention required.
|
||||||
|
|
||||||
|
Recreating mathlib's formal proof corpus: **months** of continuous formalization. The neurosymbolic loop maps naturally onto the task of converting known theorems from one logical framework to another. The dependency graph of mathlib provides the optimal generation order.
|
||||||
|
|
||||||
|
Neither requires new research. Both are engineering throughput problems that Passepartout's architecture is designed to solve: generate, verify, reload, repeat. The only hard limit is the oracle — the system cannot generate mathematics that the LLM does not already know exists.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
- [[id:7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d][Viability of open-source Wolfram/Mathematica in Lisp]] — the human-driven assessment
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — the verification and self-modification systems
|
||||||
52
ideas/viability/schafmeister-clasp.org
Normal file
52
ideas/viability/schafmeister-clasp.org
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f
|
||||||
|
:END:
|
||||||
|
#+title: Christian Schafmeister
|
||||||
|
#+filetags: :ideas:lisp:nanotechnology:
|
||||||
|
|
||||||
|
Christian Schafmeister is a chemistry professor at Temple University in Philadelphia. He created [[https://github.com/clasp-developers/clasp][Clasp]], a Common Lisp implementation that interoperates with C++ libraries using LLVM compilation, specifically to solve a problem most Lisp implementers never face: designing molecules at the nanoscale.
|
||||||
|
|
||||||
|
* The problem.
|
||||||
|
|
||||||
|
Schafmeister's research focuses on spiroligomers — large, shape-programmable molecules built from synthetic monomers. These are programmable at the level of both shape and functional groups, meaning they can be designed to bind specific proteins as therapeutics or accelerate chemical reactions the way enzymes do. The goal is to create molecules that can do everything proteins do in nature, but that are designable and evolvable by human beings.
|
||||||
|
|
||||||
|
This is a computational problem of enormous complexity. Designing these molecules requires simulating their behavior, computing binding affinities, searching conformational space, and iterating designs rapidly based on experimental feedback. The compute pipelines involved typically live in the C++ ecosystem (a vast array of scientific computing libraries), but the workflow itself — rapid prototyping, interactive exploration, incremental development — demands the kind of environment that C++ alone cannot provide.
|
||||||
|
|
||||||
|
* Why Lisp won.
|
||||||
|
|
||||||
|
Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives the knowledge-layers architecture:
|
||||||
|
|
||||||
|
- **Interactivity.** Molecular design requires exploration. A researcher needs to load data, inspect it, try a transformation, undo it, try another — all within a live environment. Lisp's REPL-driven development provides this in a way that compile-link-run cycles cannot match.
|
||||||
|
|
||||||
|
- **Incremental development.** The design space for spiroligomers is too large to simulate exhaustively. You need to build up models piece by piece, testing each step. Lisp's incremental compilation and hot-reloading make this natural.
|
||||||
|
|
||||||
|
- **Unified representation.** In Lisp, the code that describes a molecule and the code that simulates it share the same structure. There is no translation barrier between the design language and the simulation language.
|
||||||
|
|
||||||
|
But the scientific computing ecosystem lives in C++. Schafmeister could not afford to rebuild every computational chemistry library from scratch. So he built Clasp: a Common Lisp implementation that compiles to native code via LLVM and interoperates seamlessly with C++. Clasp can call any C++ library natively, and C++ can call back into Lisp. The result is that the entire scientific computing ecosystem becomes available from within a Lisp environment — programmable, interactive, introspectable.
|
||||||
|
|
||||||
|
* The architecture.
|
||||||
|
|
||||||
|
Clasp is not a wrapper or a bridge. It is a full Common Lisp implementation where the C++ interoperation is part of the language runtime itself. The clbind library provides declarative bindings — you describe how C++ classes and functions map to Lisp, and Clasp generates the glue code automatically. This is fundamentally different from CFFI-style foreign function interfaces, which require manual marshaling and are inherently fragile.
|
||||||
|
|
||||||
|
From the Lisp perspective, a C++ class appears as a CLOS class. You can subclass it, specialize methods on it, inspect its instances. The boundary between Lisp and C++ is transparent to the programmer.
|
||||||
|
|
||||||
|
* Funding and validation.
|
||||||
|
|
||||||
|
Clasp has been funded by the Defense Threat Reduction Agency (DTRA), the National Institutes of Health (NIGMS), and the National Science Foundation. These are agencies that fund computational chemistry and materials design, not programming language research. They funded Clasp because it solved a real problem in molecular design that no other approach addressed: making C++-scale scientific computing work within an interactive Lisp environment.
|
||||||
|
|
||||||
|
* Relevance to the knowledge-layers architecture.
|
||||||
|
|
||||||
|
Schafmeister's work is existence proof for two core claims:
|
||||||
|
|
||||||
|
1. Lisp is not a niche language for academic AI research or Emacs configuration. It is being used today to design therapeutic molecules that bind proteins, in environments funded by the NIH and NSF. The interactivity and homoiconicity that the knowledge-layers architecture relies on are the same properties that make this work possible.
|
||||||
|
|
||||||
|
2. The single-address-space model is not a limitation but an enabling constraint. Clasp proves that you can run C++ libraries inside a Lisp image, not alongside it. The Lisp machine is not a retro fantasy — it is a practical architecture being used today for computationally demanding scientific work.
|
||||||
|
|
||||||
|
The main difference in direction: Schafmeister brought C++ into Lisp to access the scientific computing ecosystem. The knowledge-layers architecture replaces C++ libraries with verified Lisp-native alternatives. The principle — one representation, one address space, no translation boundaries — is the same in both cases.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
See also:
|
||||||
|
- [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the architecture that extends Schafmeister's principle to verification
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — why Lisp is the choice for verified infrastructure
|
||||||
BIN
papers/McCulloch-Pitts-1943.pdf
Normal file
BIN
papers/McCulloch-Pitts-1943.pdf
Normal file
Binary file not shown.
558
papers/Rosenblatt-1958.pdf
Normal file
558
papers/Rosenblatt-1958.pdf
Normal file
File diff suppressed because one or more lines are too long
8
projects/_index.org
Normal file
8
projects/_index.org
Normal file
@@ -0,0 +1,8 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d
|
||||||
|
:END:
|
||||||
|
#+title: Projects
|
||||||
|
#+filetags: :index:
|
||||||
|
|
||||||
|
All projects documented in this brain. Each project has its own architecture, strategy, and reference material.
|
||||||
9
projects/cl-modernization/_index.org
Normal file
9
projects/cl-modernization/_index.org
Normal file
@@ -0,0 +1,9 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:ID: 89f592aa-9c46-42db-a6c7-54dc91fe2172
|
||||||
|
:CREATED: [2026-06-03 Tue]
|
||||||
|
:ID: 971cd9e7-2cc5-4743-8042-2469dbe4078f
|
||||||
|
:END:
|
||||||
|
#+title: CL Modernization
|
||||||
|
#+filetags: :redirect:
|
||||||
|
|
||||||
|
This document has moved to [[file:../passepartout/architecture/lisp-foundation.org][Lisp Foundation]] in the Passepartout architecture tree.
|
||||||
8
projects/flags/_index.org
Normal file
8
projects/flags/_index.org
Normal file
@@ -0,0 +1,8 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 1e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b
|
||||||
|
:END:
|
||||||
|
#+title: Flags
|
||||||
|
#+filetags: :index:
|
||||||
|
|
||||||
|
Legal structure analysis for the Passepartout project — entity types, jurisdictional considerations, asset protection, practical setup guides.
|
||||||
@@ -3,18 +3,18 @@
|
|||||||
:ID: asset-protection-structures
|
:ID: asset-protection-structures
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Asset Protection & Corporate Structure — Research
|
#+title: Asset Protection & Corporate Structure
|
||||||
#+filetags: :passepartout:legal:corporate:asset-protection:research:
|
#+filetags: :passepartout:legal:corporate:asset-protection:research:
|
||||||
|
|
||||||
Research on corporate structures for a US-incorporated tech company with offshore holdings. This is preliminary research, not legal advice. Every structure needs a qualified lawyer and accountant to execute.
|
Research on corporate structures for a US-incorporated tech company with offshore holdings. This is preliminary research, not legal advice. Every structure needs a qualified lawyer and accountant to execute.
|
||||||
|
|
||||||
* The Assets to Protect
|
* The Assets to Protect
|
||||||
|
|
||||||
The triad has three distinct asset classes, each with different protection needs:
|
Passepartout has three distinct asset classes, each with different protection needs:
|
||||||
|
|
||||||
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.
|
1. /IP (verification subsystem):/ [[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 ([[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.
|
2. /Platform ([[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]]):/ The network itself — user base, reputation graph, contract history, protocol specification.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
@@ -33,8 +33,8 @@ Assessment: Fine for Phase 0. Upgrade when revenue exceeds liability risk tolera
|
|||||||
|
|
||||||
** Structure B: Delaware C-Corp + Offshore IP Holding Company
|
** Structure B: Delaware C-Corp + Offshore IP Holding Company
|
||||||
|
|
||||||
- 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 social protocol 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 social 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 [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] revenue in the offshore jurisdiction
|
- The holding company accumulates IP [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] revenue in the offshore jurisdiction
|
||||||
|
|
||||||
@@ -53,11 +53,11 @@ 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, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], PDS hosting) is a separate Delaware series LLC
|
- Each business line (verification, social protocol 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
|
||||||
|
|
||||||
Pros: Good liability separation between business lines. If the social network (Agora) generates liability, the verification business (Logos) assets are in a separate series. Each series can be spun out independently.
|
Pros: Good liability separation between business lines. If the social network (the social protocol) generates liability, the verification business assets are in a separate series.
|
||||||
Cons: Series LLC is legally untested in many jurisdictions. Some states don't recognize them. Tax complexity.
|
Cons: Series LLC is legally untested in many jurisdictions. Some states don't recognize them. Tax complexity.
|
||||||
|
|
||||||
* Key Considerations for This Specific Venture
|
* Key Considerations for This Specific Venture
|
||||||
@@ -66,13 +66,13 @@ Cons: Series LLC is legally untested in many jurisdictions. Some states don't re
|
|||||||
|
|
||||||
[[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.
|
[[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 social protocol network is harder to protect**
|
||||||
|
|
||||||
The Agora's value is partly in its decentralized architecture (no central entity controls the network) and partly in the code that runs the PDS infrastructure and protocol. The AGPL license means anyone can run the code — the network value is in the user base, not the software. This is a structural asset protection advantage: even if the operating company fails, the network continues.
|
The social protocol's value is partly in its decentralized architecture (no central entity controls the network) and partly in the code that runs the PDS infrastructure and protocol. The AGPL license means anyone can run the code — the network value is in the user base, not the software. This is a structural asset protection advantage: even if the operating company fails, the network continues.
|
||||||
|
|
||||||
** Revenue splits suggest separate entities**
|
** Revenue splits suggest separate entities**
|
||||||
|
|
||||||
Enterprise compliance revenue ($2-12M/year) is high-margin, low-volume, and comes from a small number of customers. Agora transaction fees (0.5-2%) are low-margin, high-volume, and come from millions of users. Mixing these in the same entity creates regulatory complexity — compliance contracts have different liability profiles than payment processing.
|
Enterprise compliance revenue ($2-12M/year) is high-margin, low-volume, and comes from a small number of customers. Social protocol transaction fees (0.5-2%) are low-margin, high-volume, and come from millions of users.
|
||||||
|
|
||||||
** Jurisdiction for the IP company**
|
** Jurisdiction for the IP company**
|
||||||
|
|
||||||
@@ -98,20 +98,20 @@ Action items for Phase 0:
|
|||||||
|
|
||||||
** Phase 1: Separate IP + OpCo (before significant revenue)
|
** Phase 1: Separate IP + OpCo (before significant revenue)
|
||||||
|
|
||||||
Before enterprise compliance revenue exceeds $5M cumulative or Agora users exceed 10K, establish the IP holding company structure. The IP must be /out/ of the operating company before a significant lawsuit is plausible.
|
Before enterprise compliance revenue exceeds $5M cumulative or social protocol users exceed 10K, establish the IP holding company structure.
|
||||||
|
|
||||||
Structure: Delaware C-Corp (OpCo) + BVI IP Co
|
Structure: Delaware C-Corp (OpCo) + BVI IP Co
|
||||||
- OpCo licenses verification IP from BVI Co
|
- OpCo licenses verification IP from BVI Co
|
||||||
- OpCo licenses Agora protocol IP from BVI Co
|
- OpCo licenses social protocol IP from BVI Co
|
||||||
- Founders own both entities (same cap table or mirror ownership)
|
- Founders own both entities (same cap table or mirror ownership)
|
||||||
|
|
||||||
Timing: The IP transfer is a taxable event if the IP has appreciated. Transfer early, when the IP has minimal appraised value (before the verification monopoly exists), to avoid a tax hit.
|
Timing: The IP transfer is a taxable event if the IP has appreciated. Transfer early, when the IP has minimal appraised value (before the verification monopoly exists), to avoid a tax hit.
|
||||||
|
|
||||||
** Phase 2: Series Separation (when Agora has significant users or revenue)
|
** Phase 2: Series Separation (when the social protocol has significant users or revenue)
|
||||||
|
|
||||||
If the Agora has 100K+ users and payment volume, separate the business lines into different entities under the same parent:
|
If the social protocol has 100K+ users and payment volume, separate the business lines into different entities under the same parent:
|
||||||
- Logos LLC (verification, enterprise compliance)
|
- Verification LLC (verification, enterprise compliance)
|
||||||
- Agora LLC (social network, transactions, PDS hosting)
|
- Social Protocol LLC (social network, transactions, PDS hosting)
|
||||||
- Compute LLC (marketplace operations)
|
- Compute LLC (marketplace operations)
|
||||||
- BVI IP Co (owns all IP, licenses to all three)
|
- BVI IP Co (owns all IP, licenses to all three)
|
||||||
|
|
||||||
@@ -121,11 +121,11 @@ When the cumulative value justifies the cost and complexity: move the BVI IP Co
|
|||||||
|
|
||||||
* What This Means for the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][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 (social protocol communities) have /different liability profiles/ that push toward different structures:
|
||||||
|
|
||||||
Enterprise compliance: Higher liability per contract. A single compliance engagement gone wrong could be a $1M+ claim. The IP separation in Phase 1 is /more urgent/ for the Logos revenue stream.
|
Enterprise compliance: Higher liability per contract. A single compliance engagement gone wrong could be a $1M+ claim. The IP separation in Phase 1 is /more urgent/ for the verification revenue stream.
|
||||||
|
|
||||||
Agora network: Lower liability per user but higher aggregate surface. Payment processing regulations, content liability, data protection. The series LLC separation becomes relevant when users cross 10K.
|
Social protocol network: Lower liability per user but higher aggregate surface. Payment processing regulations, content liability, data protection.
|
||||||
|
|
||||||
The combined strategy (both engines) makes the Phase 1 structure (Delaware OpCo + BVI IP Co) more important rather than less — the diversification of revenue streams also diversifies liability sources, and the IP needs to be protected from /both/.
|
The combined strategy (both engines) makes the Phase 1 structure (Delaware OpCo + BVI IP Co) more important rather than less — the diversification of revenue streams also diversifies liability sources, and the IP needs to be protected from /both/.
|
||||||
|
|
||||||
@@ -134,6 +134,6 @@ 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.
|
||||||
|
|
||||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy]]
|
||||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Agora competitive landscape]]
|
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social protocol competitive landscape]]
|
||||||
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
||||||
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]]
|
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance framework]]
|
||||||
@@ -3,7 +3,7 @@
|
|||||||
:ID: legal-structure-alternatives
|
:ID: legal-structure-alternatives
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Legal Structure — Alternatives & Refinements
|
#+title: Legal Structure
|
||||||
#+filetags: :passepartout:legal:corporate:research:alternatives:
|
#+filetags: :passepartout:legal:corporate:research:alternatives:
|
||||||
|
|
||||||
This page explores alternatives and additions to the base structure (Delaware C-Corp + BVI IP Co): Texas vs Delaware, Wyoming DAO LLC, Panama LLC, and trust layering. Each has tradeoffs — some strengthen asset protection, some reduce cost, some add complexity. The right choice depends on the specific business model, risk profile, and timeline.
|
This page explores alternatives and additions to the base structure (Delaware C-Corp + BVI IP Co): Texas vs Delaware, Wyoming DAO LLC, Panama LLC, and trust layering. Each has tradeoffs — some strengthen asset protection, some reduce cost, some add complexity. The right choice depends on the specific business model, risk profile, and timeline.
|
||||||
@@ -44,21 +44,21 @@ Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organizatio
|
|||||||
|
|
||||||
** Relevance to This Venture
|
** Relevance to This Venture
|
||||||
|
|
||||||
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.
|
The [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the social protocol 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 social protocol'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
|
||||||
|
|
||||||
The Wyoming DAO LLC is not a replacement for the Delaware/Texas OpCo or the BVI IP Co. It is an offering /for Agora communities/. The communities themselves become legal entities, not just digital spaces. This creates a product feature:
|
The Wyoming DAO LLC is not a replacement for the Delaware/Texas OpCo or the BVI IP Co. It is an offering /for social protocol communities/. The communities themselves become legal entities, not just digital spaces. This creates a product feature:
|
||||||
|
|
||||||
- Community in the Agora hits 25 members who pool $5K in dues
|
- Community in the social protocol hits 25 members who pool $5K in dues
|
||||||
- Community clicks "Incorporate as Wyoming DAO LLC"
|
- Community clicks "Incorporate as Wyoming DAO LLC"
|
||||||
- The Agora generates the filing (name, registered agent, governance document mapping)
|
- The social protocol generates the filing (name, registered agent, governance document mapping)
|
||||||
- The community's voting modules become the LLC's management structure
|
- The community's voting modules become the LLC's management structure
|
||||||
- The community now holds assets, signs contracts, and has liability protection
|
- The community now holds assets, signs contracts, and has liability protection
|
||||||
|
|
||||||
** Practical Considerations
|
** Practical Considerations
|
||||||
|
|
||||||
Wyoming DAO LLCs are new (2025). Case law is essentially nonexistent. Banks may not open accounts for them. Tax treatment is unclear. But for Agora communities that need legal entity status, it's the least friction option.
|
Wyoming DAO LLCs are new (2025). Case law is essentially nonexistent. Banks may not open accounts for them. Tax treatment is unclear. But for social protocol communities that need legal entity status, it's the least friction option.
|
||||||
|
|
||||||
* Panama LLC (Sociedad de Responsabilidad Limitada / SRL)
|
* Panama LLC (Sociedad de Responsabilidad Limitada / SRL)
|
||||||
|
|
||||||
@@ -3,7 +3,7 @@
|
|||||||
:ID: legal-structure-practical-setup
|
:ID: legal-structure-practical-setup
|
||||||
:CREATED: [2026-05-23 Sat]
|
:CREATED: [2026-05-23 Sat]
|
||||||
:END:
|
:END:
|
||||||
#+title: Legal Structure — Practical Setup Guide
|
#+title: Legal Structure
|
||||||
#+filetags: :passepartout:legal:corporate:setup:action:
|
#+filetags: :passepartout:legal:corporate:setup:action:
|
||||||
|
|
||||||
Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co). Trust layer deferred until significant personal wealth accumulates. This is a research document — exact costs and forms should be confirmed with a lawyer.
|
Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co). Trust layer deferred until significant personal wealth accumulates. This is a research document — exact costs and forms should be confirmed with a lawyer.
|
||||||
@@ -19,7 +19,7 @@ Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co).
|
|||||||
│
|
│
|
||||||
owns the IP assets
|
owns the IP assets
|
||||||
([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules,
|
([[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] code, gate rules,
|
||||||
ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] protocol
|
ACL2 libraries, [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] 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.
|
||||||
@@ -125,7 +125,7 @@ A BVI Business Company (IBC) incorporated under the BVI Business Companies Act (
|
|||||||
|
|
||||||
This is the most important document. It must:
|
This is the most important document. It must:
|
||||||
|
|
||||||
1. /Define the IP:/ List every asset being licensed — the Passepartout source code, gate rules, ACL2 proof libraries, Agora protocol specification, trademarks, domain names, trade secrets. This needs to be specific enough for tax authorities but broad enough to cover future developments.
|
1. /Define the IP:/ List every asset being licensed — the Passepartout source code, gate rules, ACL2 proof libraries, social protocol specification, trademarks, domain names, trade secrets.
|
||||||
|
|
||||||
2. /Set the royalty rate:/ Must be at arm's-length. For software/tech IP, typical royalty rates are 2-10% of gross revenue, depending on how central the IP is to the business. Verification IP is 100% central to the business (the product /is/ the IP) — rates at the higher end are defensible.
|
2. /Set the royalty rate:/ Must be at arm's-length. For software/tech IP, typical royalty rates are 2-10% of gross revenue, depending on how central the IP is to the business. Verification IP is 100% central to the business (the product /is/ the IP) — rates at the higher end are defensible.
|
||||||
|
|
||||||
@@ -202,4 +202,4 @@ The IP transfer must happen /before/ the IP has significant value. Incorporating
|
|||||||
|
|
||||||
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]]
|
- [[id:0a4e0b8f-25e0-4b78-9633-fc37d03cefe9][Asset protection structures — options analysis]]
|
||||||
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]]
|
- [[id:98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b][Outbound sales compliance — data protection law]]
|
||||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Logos + Agora]]
|
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Combined growth strategy — Passepartout]]
|
||||||
1702
projects/passepartout/ROADMAP.org
Normal file
1702
projects/passepartout/ROADMAP.org
Normal file
File diff suppressed because it is too large
Load Diff
59
projects/passepartout/_index.org
Normal file
59
projects/passepartout/_index.org
Normal file
@@ -0,0 +1,59 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 7a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d
|
||||||
|
:END:
|
||||||
|
#+title: Passepartout
|
||||||
|
#+filetags: :index:
|
||||||
|
|
||||||
|
**What Passepartout is.**
|
||||||
|
|
||||||
|
Passepartout is a project that builds toward a personal computing environment where you own your computation, your data, and your agency — and the architecture proves it, not promises it.
|
||||||
|
|
||||||
|
It is a single system that is simultaneously:
|
||||||
|
|
||||||
|
- Your editor, browser, shell, and AI agent — not separate programs but a single environment where everything works together because everything shares the same structure.
|
||||||
|
- Your knowledge base — a living [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][memex]] of everything you read, write, and decide, stored in a format you can read and your machine can read, with no translation layer between them.
|
||||||
|
- Your gatekeeper — a system that checks every action against your rules before taking it, whether the action comes from you, from the AI, or from the network.
|
||||||
|
- Your identity and communication protocol — cryptographic identity, encrypted messaging, and provable exchanges between instances.
|
||||||
|
|
||||||
|
These are not separate products. They are one project, one architecture, one machine.
|
||||||
|
|
||||||
|
**Why it exists.**
|
||||||
|
|
||||||
|
The modern computing stack is built from independently built, independently untrusted layers: hardware, firmware, operating system, compilers, runtime, network protocols, applications. Each layer assumes the layers below it are either trusted or someone else's problem. The gaps between layers are where exploits live.
|
||||||
|
|
||||||
|
Security is reactive. We find bugs, we patch them, we run antivirus, we monitor logs. The model is probabilistic: "no known vulnerabilities" does not mean none exist, only that none have been found. The patching treadmill has been running for forty years and shows no sign of slowing.
|
||||||
|
|
||||||
|
Passepartout asks a different question: what if you eliminated the boundaries between layers instead of trying to secure them? What if the entire stack shared one structure, one verification, one proof — from the rules that authorize an action to the hardware that executes it?
|
||||||
|
|
||||||
|
This eliminates entire categories of threats by structural design, not by patching. Memory corruption exploits, compiler backdoors, malware with execution paths that bypass the rules — these are not mitigations you add on top of an unsafe system. They are classes of threat that cannot exist in a system built on this principle.
|
||||||
|
|
||||||
|
**What it replaces.**
|
||||||
|
|
||||||
|
| Current approach | Passepartout |
|
||||||
|
|---|---|
|
||||||
|
| Separate editor, browser, shell, agent — each a different program with different trust assumptions | One environment where all are functions in the same memory space |
|
||||||
|
| Knowledge stored in a database you cannot inspect | Knowledge stored in a file format you read and edit directly |
|
||||||
|
| Security through permissions, firewalls, antivirus, audits | Security through a rule system that checks every action before it executes |
|
||||||
|
| Separate identity systems for every service (Google login, GitHub, Slack) | One cryptographic identity you control |
|
||||||
|
| Vulnerabilities found and patched reactively | Categories of threat eliminated by architecture |
|
||||||
|
|
||||||
|
**How we get there.**
|
||||||
|
|
||||||
|
The full system is the destination, but every intermediate stage delivers value on its own. The project is designed as a staged migration from conventional hardware to the full architecture, with no rewrite required between stages. Development is running today.
|
||||||
|
|
||||||
|
**What it means.**
|
||||||
|
|
||||||
|
A system built this way shifts computing from an empirical trust model — "this has passed our tests" — to a deductive one: "this is structurally impossible for the following reasons." The downstream effects cascade beyond any single user:
|
||||||
|
|
||||||
|
- A company's compliance obligations become a set of rules the system enforces by construction, not a binder of documents an auditor reviews once a year.
|
||||||
|
- AI safety becomes a rule system between the AI and the actions it can take, not a set of probabilities and guardrails.
|
||||||
|
- Software certification becomes a shared suite of proofs from every deployed instance — a public attestation that a system behaves as specified.
|
||||||
|
|
||||||
|
Passepartout creates a new category: verified infrastructure. Not a safer operating system, not a better AI agent, not another social network — but the foundation beneath all three, built on a principle that the current approach cannot offer: that the system, by its structure, is trustworthy.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Architecture]] — the system in detail
|
||||||
|
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic Effects]] — what verification cascades into
|
||||||
|
- [[id:8cb760e2-37c6-4a78-af4d-f89f69d1678b][Staged Roadmap]] — from today to What Remains
|
||||||
158
projects/passepartout/architecture/_index.org
Normal file
158
projects/passepartout/architecture/_index.org
Normal file
@@ -0,0 +1,158 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:ID: 5e7f1d2a-3b4c-5d6e-7f8a-9b0c1d2e3f4a
|
||||||
|
:ID: 1c3ec48b-446c-50d2-b53e-126a81f5143f
|
||||||
|
:END:
|
||||||
|
#+title: Architecture
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
**The four subsystems, one address space.**
|
||||||
|
|
||||||
|
Passepartout is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:
|
||||||
|
|
||||||
|
- **Environment** — the personal computing environment
|
||||||
|
- **Knowledge** — the unified memex
|
||||||
|
- **Verification** — the gate
|
||||||
|
- **Social Protocol** — provable communication between instances
|
||||||
|
|
||||||
|
Each is described below.
|
||||||
|
|
||||||
|
**The environment: one address space.**
|
||||||
|
|
||||||
|
The environment eliminates the layered trust model of a conventional OS by eliminating the layers. Instead of an editor that sends keystrokes through a terminal emulator to a shell that forks processes that read files through a kernel VFS layer — each boundary a potential vulnerability — the environment runs everything in a single Lisp address space. (Lisp is a family of programming languages where code and data share the same representation. This property means the machine can verify what code does and modify itself without restarting. It is the foundation that makes the entire architecture possible.)
|
||||||
|
|
||||||
|
The editor is a Lisp function that manipulates text buffers in the evaluated memory graph. The shell is a Lisp read-eval-print loop that compiles to the same evaluator. The browser renders HTML through a Lisp-based rendering engine, not a separate process. The agent runtime invokes Lisp functions, not subprocesses. (The specific implementations that realize this today use Lish for the shell and editor, Nyxt for the browser, and SBCL as the host Lisp — but the architectural principle is uniform semantics in one address space, not these particular packages.)
|
||||||
|
|
||||||
|
There is no MMU boundary between components because there are no separate processes. There is no IPC because there is nothing to communicate between. Everything shares the same memory graph. Your editor buffer, your shell history, your agent's state, and your social protocol messages all live in the same evaluated object graph, protected by the same gate, verified by the same prover.
|
||||||
|
|
||||||
|
**The knowledge subsystem: Org-mode as unified memex.**
|
||||||
|
|
||||||
|
The knowledge subsystem is built on [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][Org-mode]] — one format for human and machine, with sparse tree retrieval keeping context lean (2,000-4,000 tokens). The Org file IS the data, not a representation of it. See [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] for the full analysis.
|
||||||
|
|
||||||
|
**Two indices over the Org prose:**
|
||||||
|
|
||||||
|
1. A neural index using vector embeddings for semantic search — the gateway to the full richness of natural language.
|
||||||
|
2. A symbolic index storing formal assertions about what the prose says — predicates, relations, constraints — each grounded to a specific heading or block.
|
||||||
|
|
||||||
|
The prose is always ground truth. Both indices are derived views that can be rebuilt from scratch. Nothing is lost in the indices that was not already in the Org files.
|
||||||
|
|
||||||
|
The same principle extends beyond prose to structured data. Empirical parameters, validity envelopes, provenance chains, and benchmark results live in Org as property drawers and tables — the same format the user reads and edits. The system maintains a derived representation — the provenance store — optimized for machine queries. Like the two indices, it is a derived view rebuilt from Org, not a separate canonical copy. When the system learns something new, it writes back to the Org files, keeping the human layer current.
|
||||||
|
|
||||||
|
This is what sovereignty means in technical terms — the user owns the data in a format they can access, and the system operates on the same format. See [[id:e32290a0-a02a-4af7-ae22-243d04a7ac82][Design Decisions]] for the full argument.
|
||||||
|
|
||||||
|
**The verification subsystem: the gate.**
|
||||||
|
|
||||||
|
The gate is a function that takes (action, context, policy) and returns (permit | deny). Every action passes through it — a shell command from the user, a proposal from the LLM, a message from the network, a file write by a scheduled job. There is no privileged path around the gate. Root is not a concept in the gate model — root is a convention enforced by an OS that the gate replaces.
|
||||||
|
|
||||||
|
The gate has three decision vectors:
|
||||||
|
|
||||||
|
1. **ACL2-verified procedures for security-critical checks** — access control, message authentication, capability resolution. (ACL2 is a theorem prover and programming language for formal verification. It proves that code behaves correctly for all possible inputs, not just the ones tested.) This is the deductive layer.
|
||||||
|
|
||||||
|
2. **Provenance- and validity-envelope checks for scientific and engineering integrity** — does the empirical model apply in the current context? Are the parameters within their validated range? Is the input within the model's training distribution? These are predicates over the provenance store, not formal proofs. The gate queries the store and blocks or flags computations that fall outside validated bounds. This is the empirical layer — see [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] for the full framework.
|
||||||
|
|
||||||
|
3. **An LLM for natural-language reasoning** — parsing the user's intent, evaluating whether an action falls within policy boundaries that require human judgment, interpreting gate flags and failure diagnostics. This is the probabilistic oracle — it proposes, never executes.
|
||||||
|
|
||||||
|
The ACL2 layer (vector 1) is deductive and authoritative where it applies — the LLM cannot overrule a verified denial. The provenance layer (vector 2) is authoritative over model validity — the LLM cannot override a validity envelope violation (though it may recommend a different model). The LLM layer (vector 3) is probabilistic and bounded by both lower layers.
|
||||||
|
|
||||||
|
The gate does not depend on OS privilege boundaries because it is in the evaluation loop itself. This is the architectural reason for the Lisp machine: a conventional OS interposes between the gate and the hardware. A Lisp machine eliminates that interposition by making the gate part of the evaluator.
|
||||||
|
|
||||||
|
**How the gate knows which procedure belongs to which domain.**
|
||||||
|
|
||||||
|
Every action entering the gate carries a domain tag. The tag is set by context — a file write under /home/user/documents/ gets the "documents" domain, a network call to an approved registry gets "network", a shell command running a compiler gets "software-engineering". The domain tags form a tree: "files" has children "documents", "code", "config", "system", each with its own rule set.
|
||||||
|
|
||||||
|
The gate maintains a procedure registry mapping domain tags to ACL2-verified boundary functions. When an action arrives, the gate looks up the most specific domain tag that has a registered procedure. If "documents" has one, it uses that. If not, it walks up to "files". If no domain in the tree has a procedure, the action falls under LLM authority bounded only by the generic outer fence.
|
||||||
|
|
||||||
|
Domain tags are defined in the policy configuration — a hierarchy of Org headings or YAML that maps path patterns, network destinations, and command prefixes to domain names. New domains can be added at any time with no code changes, just a policy edit. New domains start with no verified procedures and rely entirely on the LLM until experience accumulates and ACL2 boundaries are written.
|
||||||
|
|
||||||
|
**How the verified procedure registry grows.**
|
||||||
|
|
||||||
|
Verified procedures are not all written upfront. The initial gate ships with a minimal set of obviously correct outer boundaries — three to five rules that prevent catastrophic, irreversible actions. The registry grows through three mechanisms:
|
||||||
|
|
||||||
|
1. Mistake-driven hardening: when the LLM's provisional authority causes harm, that action is logged, a human or automated process writes an ACL2 conjecture to prevent it, the Prover verifies it, and the resulting boundary function is added to the registry under the relevant domain tag.
|
||||||
|
|
||||||
|
2. Adversarial probing: the gate randomly injects probe actions that would violate known desirable boundaries but are caught before execution. These probes generate the same hardening signal even when no mistake occurred. They cover the blind spot where the LLM always gets it right and no error is ever logged.
|
||||||
|
|
||||||
|
3. Syscall wrappers: every action that crosses from the Lisp image into the host OS passes through a gate wrapper that records the kernel's response. When the kernel denies an action (permissions, seccomp, namespaces) that the gate had no rule for, the wrapper translates that kernel denial into a hardening signal — "the kernel prevented this. Consider codifying it as an ACL2 boundary." This covers the blind spot where the kernel catches the problem first and the gate never sees the danger.
|
||||||
|
|
||||||
|
These three channels feed a queue. The autodidactic loop (or a human reviewer) periodically processes the queue, drafts ACL2 conjectures, runs the Prover, and deploys new verified boundaries. The gate's procedure registry grows transaction by transaction, domain by domain, from three rules to hundreds to thousands over the lifetime of the system.
|
||||||
|
|
||||||
|
**The two blind spots and their mitigations.**
|
||||||
|
|
||||||
|
Blind spot 1 — the LLM always gets it right. If the LLM never attempts a dangerous action in a domain, no mistake is logged, and no ACL2 boundary is proposed. Mitigation: adversarial probing. The gate regularly tests the LLM with actions that would violate known safety properties, logged before execution. These probes generate hardening signals regardless of the LLM's accuracy.
|
||||||
|
|
||||||
|
Blind spot 2 — the kernel prevents the action before the gate sees it. If the LLM tries to write to /etc/shadow and the kernel's DAC permissions reject it, the LLM sees a permission error, the gate sees a failed action, but neither knows a safety boundary was enforced. Mitigation: syscall wrappers. The gate wraps every kernel transition and records the reason for denial. A kernel EACCES on /etc/shadow becomes a hardening signal: "the kernel has a rule about /etc/shadow that the gate doesn't. Codify it."
|
||||||
|
|
||||||
|
Without these mitigations, the gate's coverage converges to a plateau determined only by what has already broken, leaving large regions permanently dependent on the LLM's probabilistic reliability.
|
||||||
|
|
||||||
|
**Gate decision flow (Neurosymbolic Agent stage):** An action arrives carrying a domain tag. First, the gate checks the deductive layer — does this domain have registered ACL2-verified boundary procedures? If any denies, reject instantly. The LLM cannot overrule. If no verified procedure denies, the gate checks with Screamer — a constraint network built from rules extracted by the LLM and corrected by humans. Screamer resolves domain-specific constraints, rights, and prohibitions. If Screamer finds a resolution, apply it. If not, the gate asks the LLM. The LLM proposes permit or deny, and the gate re-checks against the deductive boundaries (defense in depth). Every decision is logged to the decision log.
|
||||||
|
|
||||||
|
**How domains emerge:** Domain tags are not assigned upfront. The user writes notes in Org. The symbolic index extracts entities and relationships. Screamer's constraint network connects them. Over time, clusters form — entities that mention each other frequently and mention outside entities rarely. The gate notices clusters where LLM utilization is high. It asks the LLM to label them: "This cluster deals with financial records. Shall I create a domain called accounting?" If the user confirms, the procedure registry gets a new tag. New domains start empty — no verified boundaries — and fill as mistakes accumulate.
|
||||||
|
|
||||||
|
**The autodidactic loop runs in two parallel tracks.**
|
||||||
|
|
||||||
|
**Track 1 — deductive hardening:** formal proof generation and gate rule improvement, fast loop, runs autonomously at LLM speed:
|
||||||
|
1. Read the decision log since the last run.
|
||||||
|
2. Identify high-frequency patterns where the LLM was invoked.
|
||||||
|
3. Propose Screamer constraints for the top patterns.
|
||||||
|
4. Check the hardening queue for new ACL2 conjectures ready to prove.
|
||||||
|
5. Check the adversarial probe results — did any probe reveal an unprotected boundary?
|
||||||
|
6. Check the syscall wrapper logs — did the kernel deny anything the gate missed?
|
||||||
|
7. Propose new domain clusters if LLM utilization in a cluster exceeds a threshold.
|
||||||
|
8. Run the Prover on pending conjectures.
|
||||||
|
9. If proofs pass, compile and deploy new boundary functions.
|
||||||
|
10. Log the cycle results.
|
||||||
|
|
||||||
|
**Track 2 — empirical validation:** provenance store improvement and parameter refinement, slow loop, requires experimental feedback:
|
||||||
|
1. Review computations since the last run where predictions were compared to experimental results.
|
||||||
|
2. For each comparison, compute the prediction error. If error exceeds the model's stated confidence interval, flag the parameter for review.
|
||||||
|
3. Parameter review: is the error systematic (model needs recalibration) or random (noise within expected range)?
|
||||||
|
4. For systematic errors: propose updated parameters (LLM), validate against held-out benchmarks (symbolic engine), update provenance store.
|
||||||
|
5. Envelope expansion: if a model was used in conditions outside its original validity envelope and the predictions matched experimental data, expand the envelope to include those conditions.
|
||||||
|
6. Bias profile update: incorporate the new comparison into the model's running bias profile.
|
||||||
|
7. Community sharing: publish validated parameter updates and envelope expansions through the social protocol.
|
||||||
|
|
||||||
|
Track 1 runs every cycle (minutes to hours). Track 2 runs when experimental data arrives (hours to months). Both are essential — the fast loop makes the system more secure; the slow loop makes it more useful for real-world science and engineering. See [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] for the epistemic framework that motivates this split.
|
||||||
|
|
||||||
|
**The social protocol: provable communication.**
|
||||||
|
|
||||||
|
The social protocol extends the verified semantics beyond a single machine. It provides:
|
||||||
|
|
||||||
|
- Self-sovereign DID identity (every instance has a cryptographic identity it controls)
|
||||||
|
- DIDComm encrypted messaging (end-to-end encrypted, signed, DAG-tracked)
|
||||||
|
- Personal data stores (user-owned, gate-controlled)
|
||||||
|
- Relay network (asynchronous message delivery across trust boundaries)
|
||||||
|
- Compute marketplace (provision verified compute you rent)
|
||||||
|
- Liquid democracy (delegable voting over protocol governance)
|
||||||
|
|
||||||
|
Every message is signed by the sender's DID, tracked in a content-addressed DAG, and optionally notarized. Communication is provable when you choose it to be — you can prove what you sent, to whom, when, without revealing content.
|
||||||
|
|
||||||
|
The social protocol is not a blockchain. DAG-based ordering handles causality; delegable trust replaces proof of work.
|
||||||
|
|
||||||
|
**The staged progression.**
|
||||||
|
|
||||||
|
The full architecture — gate-verified Lisp machine on custom silicon — is the destination. The staged roadmap (see the [[file:/stages.org][stages]] directory for full detail) describes how each successive replacement eliminates a class of threat:
|
||||||
|
|
||||||
|
Development (baseline: Linux + Python agent + SQLite), Neurosymbolic Agent (the gate — root eliminated, provenance store operational), Social Protocol (provable communication), Lisp Machine (bare-metal — no MMU), AI Inference (in-process LLM), AI Weights (plist-native neural data), AI Training (verified fine-tuning), What Remains (physical, political, oracular limits).
|
||||||
|
|
||||||
|
Each stage is independently useful. Development is running today. The migration is progressive component swap, not a cut-over.
|
||||||
|
|
||||||
|
**Self-developing hardware (Lisp Machine onwards):** The hardware side of the Lisp Machine self-improves by synthesizing its own microcode. A Tenstorrent P150 (~72 RISC-V Tensix cores) runs Lisp microcode with one core dedicated to ACL2, one to Screamer, and the rest to gate verification and fact store operations. The system profiles its own gate verification latency, proposes a new microcoded instruction for the hot path, compiles RISC-V assembly from ACL2-verified specifications, loads it via PCIe DMA from within SBCL, benchmarks it — and rolls back if slower. The self-driving threshold: every subdomain involved (RISC-V ISA, SBCL internals, ACL2 metafunctions, compiler optimization) is software — the most codifiable domain — and can flip to symbolic sufficiency within days of ingestion.
|
||||||
|
|
||||||
|
**Downstream effects.**
|
||||||
|
|
||||||
|
When every action is gate-checked, every message is provable, and every computation runs on verified semantics, the security model shifts from empirical to deductive. The downstream effects cascade beyond personal computing:
|
||||||
|
|
||||||
|
- **Compliance** becomes executable gate rules instead of annual audits. A SOC 2 report is a gate configuration, not a PDF.
|
||||||
|
- **AI safety** becomes a verified gate between the LLM and the action stream instead of probabilistic guardrails or RLHF.
|
||||||
|
- **Software certification** becomes the accumulated regression suite of every deployed instance — the Underwriters Laboratory for AI.
|
||||||
|
- **Operating systems** become obsolete. The gate replaces the kernel, the address space replaces process isolation, and the verified evaluator replaces the privilege model.
|
||||||
|
|
||||||
|
See also:
|
||||||
|
- [[id:971cd9e7-2cc5-4743-8042-2469dbe4078f][Lisp Foundation]] — why Lisp, the prover bootstrapping path, and the ecosystem gap
|
||||||
|
- [[id:0a33bd83-ff3c-4eac-bc97-83eb6702051a][Design Decisions]] — the rationale behind the architecture choices
|
||||||
|
- [[id:d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f][Distinguishing Features]] — the 13-point checklist of what sets this apart
|
||||||
|
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]] — how verification cascades across society, economics, and geopolitics
|
||||||
|
- [[id:329bd4fb-702a-4a2b-9c63-69281aacb83a][Knowledge Layers]] — the epistemic architecture: deductive proofs, provenance-tracked empirical models, and probabilistic oracle
|
||||||
|
- [[id:efc76898-03f7-57ba-923d-35d65da88bb7][The per-domain sufficiency flip]]
|
||||||
|
- [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][Biology as proof of the Lisp model]]
|
||||||
|
- [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][Comparison with Symbolics Genera]]
|
||||||
108
projects/passepartout/architecture/academic.org
Normal file
108
projects/passepartout/architecture/academic.org
Normal file
@@ -0,0 +1,108 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-27 Wed]
|
||||||
|
:WEIGHT: 63
|
||||||
|
:ID: d2722576-fc9b-4bd3-bc2f-f5692b561b4e
|
||||||
|
:END:
|
||||||
|
#+title: Who Is Closest to Passepartout?
|
||||||
|
#+filetags: :passepartout:academia:comparison:neurosymbolic:verification:
|
||||||
|
|
||||||
|
A survey of academic researchers whose work overlaps with Passepartout's architecture along specific dimensions. The conclusion: no academic group combines all four architectural properties that define Passepartout's design. The closest groups each hold one or two pieces; none combine all.
|
||||||
|
|
||||||
|
* The Four Architectural Properties
|
||||||
|
|
||||||
|
1. **LLM-level generator with full creative freedom** — the generator synthesizes entire implementations from specifications, not individual tactic steps or hole-fillings.
|
||||||
|
|
||||||
|
2. **Theorem-prover verification with complete functional correctness** — the verifier checks all execution paths against the full spec, not bounded verification via SMT solvers.
|
||||||
|
|
||||||
|
3. **Asymmetric authority** — the symbolic component (prover) is the final authority and cannot be overridden by the neural component.
|
||||||
|
|
||||||
|
4. **Counterexample-guided retry loop** — when the prover rejects an implementation, it returns a concrete counterexample that the generator uses to reformulate.
|
||||||
|
|
||||||
|
* The Academic Landscape
|
||||||
|
|
||||||
|
**LLM + Theorem Prover Loops**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Sean Welleck | CMU | ImProver 2 | Self-improving LMs generating proof steps verified by Lean | Generator fills tactic holes in existing proofs, not full implementations. Camp B. |
|
||||||
|
| Timon Gehr | ETH | COPRA, Thor | LLM interacts with theorem prover kernel | Same constraint: tactic-level. Neural component generates one move at a time. |
|
||||||
|
| Kaiyu Yang | Princeton | LINC | Neural network learns symbolic rules, prover checks consistency | Neural component is a *learner* discovering rules from data, not a generator synthesizing from spec. Different abstraction level. |
|
||||||
|
|
||||||
|
All three are Camp B in the loop taxonomy (constrained generator + complete verifier). None gives the LLM freedom to synthesize full implementations. Welleck's ImProver is the closest in spirit — the loop iterates, the prover is authoritative — but the scope of what the generator produces is orders of magnitude smaller than what Passepartout's design requires.
|
||||||
|
|
||||||
|
**Synthesis + Verification (non-LLM)**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Armando Solar-Lezama | MIT | Sketch | Synthesis-aided verification: partial program → solver fills holes → assertions checked | Generator is constraint-based SAT/SMT, not an LLM. Verification is bounded (solver capacity). |
|
||||||
|
| Emina Torlak | UW | Rosette | Solver-aided languages for synthesis + verification | Same constraints as Sketch. Bounded, non-LLM. |
|
||||||
|
| Swarat Chaudhuri | UT Austin | Neurosymbolic Programming | Neural networks guide program synthesis, symbolic analysis verifies | Uses SMT for bounded verification, not theorem prover for complete. Neural-symbolic are symmetric collaborators, not asymmetric authority. |
|
||||||
|
|
||||||
|
Chaudhuri is the closest overall academic neighbor. His group explicitly works on combining neural and symbolic components, with symbolic verification of neural-generated candidates. But the verification is bounded (SMT), not complete (theorem prover), and the loop does not have Passepartout's asymmetric authority design.
|
||||||
|
|
||||||
|
**Lisp as Infrastructure for Verification**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Christian Schafmeister | Temple | Clasp | Common Lisp through LLVM; interactive Lisp for serious computation | Lisp infrastructure, not a neurosymbolic loop. No ACL2 integration. |
|
||||||
|
| Kaufmann, Moore | UT Austin / Retired | ACL2 | The theorem prover itself | Pure symbolic verification. No LLM loop. |
|
||||||
|
|
||||||
|
Schafmeister is aligned with Passepartout on the "why Lisp" question — interactive development, uniform representation, C++ interop for performance — but does not work on agentic verification loops.
|
||||||
|
|
||||||
|
**Autonomous Code Modification Loops**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Kevin Ellis | Cornell | DreamCoder | Neural program synthesis loop: generate → execute → learn | Verifier is interpreter (does it run?), not prover (is it correct?). Camp A. |
|
||||||
|
| Andrej Karpathy | Anthropic | autoresearch | LLM modifies code, runs experiments, keeps/discards based on metric | Verifier is val_bpb — a single empirical number. No specification, no formal guarantee. Camp C. |
|
||||||
|
|
||||||
|
Both prove the viability of the autonomous loop concept but use the weakest possible verifiers (execution and empirical metrics).
|
||||||
|
|
||||||
|
**The Bitter Lesson / Temporal Credit Assignment (Sutton)**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Richard Sutton | Alberta / Keen Technologies | TD learning, eligibility traces, Alberta Plan | The fundamental problem in verification — *an action was checked, but the consequence plays out hours later; was the action correct?* — is the same problem TD learning solves in RL: assigning credit to actions based on delayed outcomes. Sutton's temporal credit assignment work is the theory you would need to extend Passepartout from per-action gates to trajectory-level verification. His Bitter Lesson (scale beats engineered knowledge at sufficient compute) is the most commonly cited argument against the symbolic verification approach Passepartout bets on. | The Bitter Lesson is not anti-knowledge — it says methods that improve with more computation eventually dominate. Passepartout's gate is a deliberately small engineered knowledge system that *won't* benefit from more compute (the ACL2 lemmas don't get more correct with more hardware). That's acceptable because the gate is a narrow bottleneck (permit/deny). The LLM layer inside the gate *does* benefit from scale. The architecture already respects the Bitter Lesson by placing the scalable piece where scale helps and the non-scalable piece where deductive certainty matters. Sutton's Alberta Plan (world model + reward + learning algorithm) parallels Passepartout's AI Training stage (world model + gate + verified fine-tuning), but Sutton's agents learn by pure reward while Passepartout's learn by reward constrained by verified policy. Sutton would likely argue that a learned safety policy at scale would outcompete the gate. Passepartout's bet is that access control, message authentication, and compliance should never be probabilistic, even at infinite scale.
|
||||||
|
|
||||||
|
**Integrate-Symbolic-Into-Neural (Garcez)**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Artur d'Avila Garcez | City, Univ. of London | NeSy frameworks, NSL | Pioneer of neural-symbolic computation since 1990s. Book: "Neural-Symbolic Cognitive Reasoning." Runs NeSy workshop series. | His approach *integrates* symbolic knowledge into neural networks (logic regularization, knowledge distillation). Symbolic rules are a training signal, not a runtime verifier. The neural component can override symbolic constraints through the loss landscape. No asymmetric authority, no theorem prover, no complete verification. His camp is "make neural networks behave more symbolically." Passepartout's camp is "make neural networks accountable to symbolic verification." Opposite architectural philosophy. |
|
||||||
|
|
||||||
|
Garcez's position in the design space is closest to Camp A (no independent verifier). The symbolic rules guide learning but do not veto outputs at runtime. His work is foundational for the field of neural-symbolic computation, but his *architectural philosophy* is the inverse of Passepartout's. He wants the symbolic inside the neural. Passepartout wants them separate with the symbolic holding authority.
|
||||||
|
|
||||||
|
**Theorist of the Hybrid Thesis (Marcus)**
|
||||||
|
|
||||||
|
| Researcher | Institution | System | Match | Divergence |
|
||||||
|
|------------|-------------|--------|-------|------------|
|
||||||
|
| Gary Marcus | NYU Emeritus, Robust.AI | None (theorist/critic) | Longest-standing public advocate for hybrid AI. Since "The Algebraic Mind" (2001) and "Rebooting AI" (2019), he has argued deep learning alone cannot achieve systematicity, composition, or reasoning. He identified the *need* for the approach Passepartout implements. As of May 2026, he is publicly asking why LLM agent frameworks are not using LEAN as a theorem-prover verifier — the same engineering gap Passepartout occupies. | He does not propose a specific architecture or loop design. His background is cognitive science and developmental psychology, not formal verification. The "symbolic component" he advocates is abstract — structured knowledge representations, not ACL2 theorem proving. He has no answer to the cost/feasibility question (the "Better is Cheaper" argument is Passepartout's contribution, not Marcus's). He is a theorist of the problem, not an architect of the solution — though his May 2026 tweet shows he is now engaging with the engineering question directly. |
|
||||||
|
|
||||||
|
Marcus occupies a category that does not appear in the loop taxonomy (Camps A-D) because he does not define a loop. He identifies the *need* for hybrid AI with genuine symbolic authority. Passepartout is the engineering response to the thesis Marcus has been arguing since before most of the field would admit the limitations existed. His May 2026 tweet asking "they aren't using LEAN in one of those many tools?" is the theorist noticing the empty cell Passepartout was designed to fill.
|
||||||
|
|
||||||
|
* The Gap
|
||||||
|
|
||||||
|
| Property | Passepartout | Closest academic | Academic's limiter |
|
||||||
|
|----------|-------------|-----------------|-------------------|
|
||||||
|
| Generator freedom | Full synthesis from spec | ImProver (Welleck) | Fills tactic holes only |
|
||||||
|
| Verification completeness | Complete (theorem prover) | Sketch (Solar-Lezama) | Bounded (SMT) |
|
||||||
|
| Asymmetric authority | Neural cannot override prover | Neurosymbolic Prog (Chaudhuri) | Symmetric collaboration |
|
||||||
|
| Counterexample feedback | Structured from prover to LLM | ImProver (Welleck) | Pass/fail at tactic level |
|
||||||
|
| Two symbolic layers | Gates + prover independent | None | No second layer exists |
|
||||||
|
|
||||||
|
No academic group combines all four properties. The closest — Chaudhuri — has three of five (neural + symbolic + verification) but fails on verification completeness (SMT not ACL2), asymmetric authority (symmetric not asymmetric), and the two-layer gate design.
|
||||||
|
|
||||||
|
* What This Means
|
||||||
|
|
||||||
|
The gap is either:
|
||||||
|
|
||||||
|
1. **A genuinely empty cell in the design space.** The combination is novel, the components have not converged in one system before, and Passepartout's design is early.
|
||||||
|
|
||||||
|
2. **A sign that the combination is not as valuable as the components.** No major academic lab has invested in this specific loop because the cost of writing complete formal specifications exceeds the benefit of complete formal verification, given the alternative of bounded verification (SMT) with cheaper spec costs.
|
||||||
|
|
||||||
|
The way to distinguish (1) from (2) is to build the architecture and measure whether the spec-writing cost is amortized over enough synthesized implementations to justify it. Passepartout's answer is: yes, because specs are written once and implementations are generated for every deployment context. The academic literature has not tested this claim.
|
||||||
|
|
||||||
|
* References
|
||||||
|
|
||||||
|
- [[id:be9bccc7-5adf-4d0d-8ee4-8855892189bf][Neurosymbolic Loop Architectures]] — the taxonomy that positions these comparisons
|
||||||
|
- [[id:ee8f3b2a-4c7d-4e1b-9b0a-6d8f2e3c1a5b][Neurosymbolic AI Paper Library]] — papers referenced above are in the local library
|
||||||
138
projects/passepartout/architecture/biomimicry.org
Normal file
138
projects/passepartout/architecture/biomimicry.org
Normal file
@@ -0,0 +1,138 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-01 Mon]
|
||||||
|
:WEIGHT: 61
|
||||||
|
:ID: f6a7b8c9-0d1e-2f3a-4b5c-6d7e8f90abcd
|
||||||
|
:END:
|
||||||
|
#+title: Biomimicry in Passepartout
|
||||||
|
#+filetags: :passepartout:architecture:neurosymbolic:biomimicry:p150:
|
||||||
|
|
||||||
|
**Biomimicry in Passepartout**
|
||||||
|
|
||||||
|
**What already exists (real biomimicry, not metaphor)**
|
||||||
|
|
||||||
|
| Feature | Biological analog | Implementation |
|
||||||
|
|---------+-------------------+----------------|
|
||||||
|
| Three-layer reasoning | Reptilian → limbic → neocortex | LLM (intuition) → Screamer (constrained search) → ACL2 (verified reasoning) |
|
||||||
|
| Verdict-overrides-LLM | Somatic markers override conscious deliberation | Gate outputs overrule LLM proposals, not the other way |
|
||||||
|
| Dream cycle | Sleep consolidation | gbrain dream cycle: replay and re-index daily experience offline |
|
||||||
|
| Delegate subagents | Cognitive recruitment | delegate_task — spawns specialized subprocesses for subproblems |
|
||||||
|
| Memory as two systems | Declarative vs procedural | Fact store (explicit) vs skills (implicit/procedural) |
|
||||||
|
|
||||||
|
**What is missing — and how to fill it**
|
||||||
|
|
||||||
|
***1. Peripheral nervous system (P150 slot)***
|
||||||
|
|
||||||
|
Biology does not poll. The brain does not run ~while true: check if_finger_hot()~. Dedicated low-power circuits (nociceptors, proprioceptors) monitor continuously and only signal the CNS on deviation.
|
||||||
|
|
||||||
|
Passepartout polls everything — cron output, filesystem, user messages. A P150 running 72 parallel event-driven monitors would dedicate:
|
||||||
|
|
||||||
|
- One core to "is the user typing on Signal?"
|
||||||
|
- One to "did the weekly model discovery fail?"
|
||||||
|
- One to "is ZFS ARC thrashing?"
|
||||||
|
- One to "is the test build running longer than usual?"
|
||||||
|
|
||||||
|
Each sleeps until something meaningful happens. Only then does it signal the symbolic system. Zero LLM involvement for routine monitoring.
|
||||||
|
|
||||||
|
This changes Passepartout from a system that responds to commands to a system that notices things on its own. The difference between a calculator and a research assistant.
|
||||||
|
|
||||||
|
***2. Associative activation (spreading activation)***
|
||||||
|
|
||||||
|
In the brain, activating one concept (ACL2) automatically pre-activates related concepts (SP3, proof, Lisp, verification). No clean-slate search.
|
||||||
|
|
||||||
|
Passepartout has no equivalent. Every query is a fresh search. A biomimetic fact store would:
|
||||||
|
|
||||||
|
- Pre-fetch linked pages when one is loaded
|
||||||
|
- Prime caches based on current conversation context
|
||||||
|
- Use the graph structure to predict what will be needed next
|
||||||
|
|
||||||
|
The brain does not pre-fetch — it primes — so the next thought is faster. Passepartout could prime its caches so facts most likely needed next are already loaded.
|
||||||
|
|
||||||
|
***3. Error-driven learning with local credit assignment***
|
||||||
|
|
||||||
|
The brain does not backpropagate. Errors trigger local corrections at the synapse that made the mistake.
|
||||||
|
|
||||||
|
Passepartout's Gate decisions today are either right or wrong, but nothing locally adjusts. A biomimetic Gate would:
|
||||||
|
|
||||||
|
- Track which rules fired during a wrong decision
|
||||||
|
- Locally adjust confidence scores of only those rules
|
||||||
|
- No global retrain — just the specific rule that fired
|
||||||
|
|
||||||
|
This is STDP at the symbolic level.
|
||||||
|
|
||||||
|
***4. Sleep consolidation (dream cycle upgrade)***
|
||||||
|
|
||||||
|
The gbrain dream cycle already replays daily experience. It could go further during offline cycles:
|
||||||
|
|
||||||
|
- Replay the day's decisions, identify which Gate checks were slow
|
||||||
|
- Regenerate ACL2 proof caches for rules that changed
|
||||||
|
- Prune skills that never fired (neurogenesis pruning counterpart)
|
||||||
|
- Re-index fact store based on actual usage, not static linking
|
||||||
|
- Propose new skills for repeated multi-step tasks discovered during the day
|
||||||
|
|
||||||
|
***5. Graceful degradation***
|
||||||
|
|
||||||
|
Biology has redundant fallbacks at every level. Passepartout has single points of failure.
|
||||||
|
|
||||||
|
A biomimetic approach:
|
||||||
|
|
||||||
|
- Gate offline? Fall back to cached rule set
|
||||||
|
- LLM offline? Fall back to smaller local model
|
||||||
|
- ACL2 busy? Use previously verified boundaries
|
||||||
|
- Never go silent — get slower and dumber until primary returns
|
||||||
|
- P150 cores can run degraded modes independently
|
||||||
|
|
||||||
|
**The P150's role**
|
||||||
|
|
||||||
|
The P150 (72 Tensix cores, 32GB GDDR6, QSFP-DD 800G interconnect) fills a slot nothing else in the build covers:
|
||||||
|
|
||||||
|
- Not for fast inference (2x 3090s are faster and cheaper for that)
|
||||||
|
- Not for baremetal Lisp Machine (FPGA is the right tool for tagged memory + hardware GC)
|
||||||
|
- For ambient awareness, parallel verification dispatch, fact store indexing, anomaly detection
|
||||||
|
|
||||||
|
The P150 is the system's peripheral nervous system — always-on monitoring behind the scenes.
|
||||||
|
|
||||||
|
**Revised architecture**
|
||||||
|
|
||||||
|
| Component | Role |
|
||||||
|
|-----------+------|
|
||||||
|
| 2x RTX 3090 | Fast LLM inference |
|
||||||
|
| EPYC (main cores) | ACL2, Screamer, PDS, Gate orchestration |
|
||||||
|
| P150 | Always-on temporal awareness, parallel constraint search, fact store indexing, anomaly detection |
|
||||||
|
| FPGA (future) | Lisp Machine (tagged memory, hardware GC) |
|
||||||
|
|
||||||
|
**Temporal awareness: explicit vs ambient**
|
||||||
|
|
||||||
|
Passepartout today reasons about time (reading logs, comparing timestamps, understanding "before X happened" from context) but has no sense of time.
|
||||||
|
|
||||||
|
Explicit (current): Reads a cron schedule, orders log events, answers "when did X happen."
|
||||||
|
|
||||||
|
Ambient (with P150): Notices the build took 3x longer than usual without being asked, flags that message frequency dropped at 3AM, anticipates the user will want the weekly report before they ask.
|
||||||
|
|
||||||
|
The P150 makes ambient temporal processing economically viable because 72 independent cores running statistical monitors consume near-zero power. Running the same monitors on the EPYC competes with ACL2 and the PDS. Running them on the 3090s wastes bandwidth on non-matrix work.
|
||||||
|
|
||||||
|
**Relationship to the Pinker/Marcus critique**
|
||||||
|
|
||||||
|
Pinker and Marcus argue that neural networks (spiking or otherwise) lack compositional syntax and systematic reasoning. A network that learns "A fires before B" through STDP has learned a temporal correlation, not a rule. It cannot distinguish causation, correlation, and coincidence.
|
||||||
|
|
||||||
|
This critique does not apply to Passepartout because Passepartout is not a pure neural network. It is a hybrid system:
|
||||||
|
|
||||||
|
| Problem | Mathematics | Where it runs |
|
||||||
|
|---------+------------+---------------|
|
||||||
|
| Temporal intuition | Statistical pattern detection | P150 |
|
||||||
|
| Compositional time (before/after/during) | Symbolic reasoning | Gate + Screamer on CPU |
|
||||||
|
| Sequential patterns from data | ANN attention | GPU |
|
||||||
|
|
||||||
|
The neuromorphic layer gives the system a sense of time. The symbolic layer gives it understanding of time. Both are necessary. Neither one replaces the other.
|
||||||
|
|
||||||
|
**What biomimicry means here**
|
||||||
|
|
||||||
|
The real gains come not from replicating brain details (spiking neurons, STDP, ion channels) but from adopting organizational principles that biology evolved:
|
||||||
|
|
||||||
|
- Specialized subsystems for different time/resource regimes (PNS vs CNS)
|
||||||
|
- Asynchronous event-driven communication instead of synchronous polling
|
||||||
|
- Redundant fallbacks at every level
|
||||||
|
- Local learning that does not require global retraining
|
||||||
|
- Offline consolidation separate from online inference
|
||||||
|
- Parallel associative retrieval rather than sequential search
|
||||||
|
|
||||||
|
Passepartout already adopts some of these. The P150 and an upgraded cron/dream cycle would add the rest.
|
||||||
19
projects/passepartout/architecture/design/_index.org
Normal file
19
projects/passepartout/architecture/design/_index.org
Normal file
@@ -0,0 +1,19 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:ID: e32290a0-a02a-4af7-ae22-243d04a7ac82
|
||||||
|
:CREATED: [2026-05-24 Sun]
|
||||||
|
:END:
|
||||||
|
#+title: Design Decisions
|
||||||
|
#+filetags: :passepartout:architecture:design:
|
||||||
|
|
||||||
|
The rationale behind key architectural choices — split by topic. Each directory covers one major design domain, with individual files per concept.
|
||||||
|
|
||||||
|
- [[file:foundation/][Foundation]] — non-negotiable identity, single agent, unified memory, Org-mode as AST, homoiconicity
|
||||||
|
- [[file:the-two-brains/][The Two Brains]] — probabilistic-deterministic split, four pillars, dispatcher as learning system
|
||||||
|
- [[file:safety-self-preservation/][Safety & Self-Preservation]] — self-preservation, type-level gates, layered signal authentication
|
||||||
|
- [[file:the-symbolic-engine/][The Symbolic Engine]] — five options, chosen path, gate bootstrap, cardinality policies, ontology, Merkle DAG, fact interface
|
||||||
|
- [[file:knowledge-sources/][Knowledge Sources]] — Wikidata as entity backbone, MOMo empirical validation
|
||||||
|
- [[file:implementation-properties/][Implementation Properties]] — performance, provenance chain as product
|
||||||
|
- [[file:engineering-infrastructure/][Engineering Infrastructure]] — REPL, cybernetic loop, observability, literate programming, MCP, token economics, time awareness
|
||||||
|
- [[file:validation/][Validation]] — Whitehead, McCarthy, Marcus, CREST, competitive argument
|
||||||
|
- [[file:open-questions.org][Open Questions]] — unresolved design decisions
|
||||||
|
- [[file:relation-to-passepartouts-existing-architecture.org][Relation to Existing Architecture]]
|
||||||
@@ -0,0 +1,18 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 7e575c8d-aa28-4588-bfa1-5f6144165a13
|
||||||
|
:END:
|
||||||
|
#+title: Engineering Infrastructure
|
||||||
|
* Engineering Infrastructure
|
||||||
|
|
||||||
|
- [[file:the-repl-as-cognitive-substrate.org][The REPL as Cognitive Substrate]] — A REPL — Read, Eval, Print, Loop — is an interactive programming environment tha
|
||||||
|
- [[file:the-cybernetic-loop-why-the-metabolic-pipeline-works.org][The Cybernetic Loop: Why the Metabolic Pipeline Works]] — The Perceive → Reason → Act cycle is not a software architecture pattern. It is
|
||||||
|
- [[file:observability-and-the-thought-trace.org][Observability and the Thought Trace]] — When a human asks why the system made a decision, the answer must be findable. I
|
||||||
|
- [[file:literate-programming-as-discipline.org][Literate Programming as Discipline]] — The decision to use Org-mode as the source of truth for code, not just documenta
|
||||||
|
- [[file:the-evaluation-harness.org][The Evaluation Harness]] — SOTA parity is meaningless without measurement. A system that claims to match co
|
||||||
|
- [[file:the-mcp-strategy.org][The MCP Strategy]] — The Model Context Protocol (MCP) is a standard for connecting AI systems to exte
|
||||||
|
- [[file:local-first-architecture.org][Local-First Architecture]] — Passepartout is designed to run on the user's machine, on their hardware, with t
|
||||||
|
- [[file:token-economics-and-performance-advantage.org][Token Economics and Performance Advantage]] — This section analyzes how Passepartout's architectural decisions translate into
|
||||||
|
- [[file:time-awareness-as-a-structural-advantage.org][Time Awareness as a Structural Advantage]] — Passepartout's architecture provides three layers of time awareness, each enable
|
||||||
|
- [[file:definite-description-resolution.org][Definite Description Resolution]] — When the user says "the function that validates secrets," the agent must resolve
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Definite Description Resolution
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
When the user says "the function that validates secrets," the agent must resolve this to a specific code entity. Natural language is ambiguous — there might be multiple functions matching the description. Resolving to the wrong one causes incorrect actions.
|
||||||
|
|
||||||
|
/Principia Mathematica/'s theory of descriptions addresses this: "the current king of France is bald" — a sentence that seems to refer to something that doesn't exist. PM formalizes ~ιx(φx)~ as "the unique x such that φ holds." A statement is false (not meaningless) when there is no unique x satisfying φ.
|
||||||
|
|
||||||
|
A cognitive tool that checks descriptional uniqueness before resolution:
|
||||||
|
|
||||||
|
#+BEGIN_SRC lisp
|
||||||
|
(def-cognitive-tool :resolve-reference
|
||||||
|
(query-string &key (max-candidates 10)
|
||||||
|
(context-path *current-context*))
|
||||||
|
"Resolve a definite description to a unique referent."
|
||||||
|
(let ((candidates (search-knowledge-graph query-string
|
||||||
|
:source-path context-path
|
||||||
|
:limit max-candidates)))
|
||||||
|
(cond
|
||||||
|
((null candidates)
|
||||||
|
(values nil :no-referent query-string))
|
||||||
|
((> (length candidates) 1)
|
||||||
|
(values nil :ambiguous candidates))
|
||||||
|
(t
|
||||||
|
(values (first candidates) :unique nil)))))
|
||||||
|
#+END_SRC
|
||||||
|
|
||||||
|
~40 lines as a skill in v0.7.2. When VivaceGraph ships (v3.0.0), descriptions become native Prolog queries with uniqueness constraints.
|
||||||
|
|
||||||
|
For the philosophical foundations, see the Whitehead analysis in the Validation section below.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Literate Programming as Discipline
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The decision to use Org-mode as the source of truth for code, not just documentation, is not a ceremonial preference. It is a constraint mechanism that enforces better engineering habits at the cost of convenience.
|
||||||
|
|
||||||
|
The traditional development workflow is: write code, write comments, commit. The literate programming workflow is: write prose, write code, commit the Org. The order matters. The prose must come first not because of style guidelines but because the act of explaining what a function does before writing it forces clarity of thought that editing code directly does not.
|
||||||
|
|
||||||
|
When you must write a paragraph describing what a function does before you write the function, you discover the cases you have not considered. You find the edge conditions that are ambiguous. You realize that the function's name does not match its behavior, or that its behavior does not match your intent. The friction is not a bug — it is the mechanism by which thinking is enforced.
|
||||||
|
|
||||||
|
The one-function-per-block rule enforces granularity. A function that cannot be explained in a paragraph is a function that is doing too much. The block boundary is not aesthetic — it is architectural. It prevents the drift toward monolithic functions that accumulate responsibilities over time and become untestable, unmaintainable, and incomprehensible.
|
||||||
|
|
||||||
|
The tangle step enforces source-of-truth discipline. The .lisp file is generated from the Org file. This means the Org file cannot drift from the implementation. If the implementation changes, the Org must be updated to match. If the Org describes behavior that the implementation does not perform, the tangle produces code that does not match the Org description. Either way, inconsistency is visible and recoverable.
|
||||||
|
|
||||||
|
The evaluation gate enforces correctness. Every block can be evaluated independently in a running Lisp image. This means syntax errors are caught at authorship time, not at integration time. The function that compiles in isolation but fails in context is the function whose context dependencies were never made explicit. The evaluation gate forces those dependencies to surface.
|
||||||
|
|
||||||
|
Together, these constraints create a development experience that is slower in the small and faster in the large. Writing a new function takes longer because you must explain it. But debugging, maintaining, and extending the codebase is faster because every function has a human-readable explanation of its intent, every function is testable in isolation, and every function's source is always synchronized with its documentation.
|
||||||
|
|
||||||
|
The literate programming discipline is not about producing documentation. It is about producing code whose correctness has been verified by the act of explaining it.
|
||||||
@@ -0,0 +1,17 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Local-First Architecture
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout is designed to run on the user's machine, on their hardware, with their data, without requiring an internet connection. This is not a deployment option — it is an architectural commitment. The system must be able to reason, plan, and act using only the resources available locally.
|
||||||
|
|
||||||
|
The motivation is not merely philosophical. Cloud-based AI agents are economically incentivized to collect data, to train on user interactions, and to build lock-in through proprietary formats and network effects. When the agent runs locally, the user owns the hardware, owns the data, and can terminate the process without asking permission. There is no vendor that can change terms, no service that can go offline, no model that can be updated without consent.
|
||||||
|
|
||||||
|
Technically, local-first means several things. The LLM must be able to run on local hardware. Passepartout supports Ollama as a provider, which runs quantized models on CPU and GPU without requiring an external API. The vector database must be local. Passepartout uses its own org-object store, which is a folder of Org files that the agent already owns. There is no ChromaDB or Qdrant to install, no cloud vector service to authenticate with.
|
||||||
|
|
||||||
|
The symbolic engine does not require a network connection. The Prolog/Datalog reasoner that verifies neural proposals runs entirely in the Lisp image. The Dispatcher's rule synthesis does not call an external service. The agent can operate in a disconnected environment indefinitely, resuming full capability when connectivity is restored.
|
||||||
|
|
||||||
|
This does not mean Passepartout refuses to use cloud services when available and appropriate. It means cloud services are optional enhancements, not architectural requirements. The core is local. The user can choose to add cloud LLM providers for more capable inference, but the system functions without them.
|
||||||
|
|
||||||
|
*On live images and binaries.* Passepartout's primary delivery path is source code running in a live SBCL process. The REPL is available. Skills hot-reload. The cognitive loop runs in an image that is mutable, inspectable, and homeiconic — the user can connect with SLIME, trace functions, inspect memory objects, and modify the system while it runs. A =save-lisp-and-die= binary is provided as a convenience for platforms where SBCL cannot be installed. The binary is the same image saved to disk with Swank pre-loaded — it is not a sealed container. The REPL works. Skills hot-reload. The binary is a packaging format, not an architectural decision.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Observability and the Thought Trace
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
When a human asks why the system made a decision, the answer must be findable. In most AI systems, the reasoning is ephemeral — it exists in the model's activations and disappears when the session ends. In Passepartout, every significant cognitive event is written to an Org buffer as it happens.
|
||||||
|
|
||||||
|
The thought trace is the agent's journal, written in parallel with its reasoning. When the probabilistic engine generates a proposal, the trace records the input, the prompt, and the raw output. When the deterministic engine evaluates it, the trace records which rules were checked, which passed, which failed, and why. When an action is executed, the trace records the timestamp, the user who approved it (if human-in-the-loop), and the outcome.
|
||||||
|
|
||||||
|
This is not logging in the traditional sense. Logs are forensically useful but are written in a machine format optimized for storage, not for human reading. The thought trace is written in Org-mode: headlines for major events, property drawers for structured data, tags for categorization. The human can open the trace in a text editor and navigate it like any other Org file. They can search for a specific decision, filter by time range, find all actions blocked by a specific rule, or see the complete trajectory of a multi-step task.
|
||||||
|
|
||||||
|
The trace becomes the foundation for the Dispatcher's learning. Every blocked action is in the trace. Every approved exception is in the trace. The human-in-the-loop decisions are in the trace. The system does not need to reconstruct what happened — it reads what happened from the trace it wrote.
|
||||||
|
|
||||||
|
Without observability, the system is a black box that happens to produce correct outputs sometimes. With observability, the system is auditable. The human can see why a decision was made, identify where the reasoning failed, and course-correct the system or its own behavior accordingly.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The Perceive → Reason → Act cycle is not a software architecture pattern. It is a cybernetic feedback loop — the mechanism by which a system steers itself toward a goal in a changing environment.
|
||||||
|
|
||||||
|
Norbert Wiener defined cybernetics in 1948 as "control and communication in the animal and the machine." The metabolic pipeline implements this precisely: Perceive is the sensor (reading the environment), Reason is the controller (evaluating against goals and constraints), Act is the actuator (modifying the environment), and the tool-output feedback signal closes the loop (reading the effect of the action and adjusting the next perception).
|
||||||
|
|
||||||
|
The Dispatcher gate stack is the negative feedback governor. When the LLM proposes an action that would violate an invariant, the Dispatcher blocks it and feeds the rejection trace back to the LLM for self-correction. This is Ross Ashby's homeostasis — the system maintains its internal stability by correcting deviations from its set point (the safety invariants). Without this negative feedback, the probabilistic engine would drift into hallucinated proposals that become progressively less grounded. The Dispatcher constrains it to the domain of safe, verifiable actions.
|
||||||
|
|
||||||
|
The self-editing capability is second-order cybernetics — autopoiesis, the capacity of a system to create and maintain itself. Humberto Maturana and Francisco Varela defined this as the hallmark of living systems. When the agent detects an error, locates the faulty function, generates a corrected version, and hot-reloads it into the running image without restarting, it is modifying its own architecture while continuing to operate. Passepartout achieves this through Lisp's homoiconicity — code is data, and the running image is the environment.
|
||||||
|
|
||||||
|
This framing matters for two reasons. First, it places Passepartout in a lineage that predates and outlasts the current "LLM with tools" paradigm. The cybernetic principles of feedback, homeostasis, and autopoiesis are independent of any specific model architecture. They work whether the perceptual engine is an LLM, a vision model, or a symbolic parser. Second, it explains why the architecture gets more reliable over time — cybernetic systems improve through accumulated negative feedback corrections, not through better training data. Every blocked action is a correction. Every approved exception is a refined set point. The system converges on stability through use.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Evaluation Harness
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
SOTA parity is meaningless without measurement. A system that claims to match commercial agents must demonstrate it through reproducible benchmarks, not through feature checklists. The evaluation harness is the apparatus by which Passepartout proves its capabilities.
|
||||||
|
|
||||||
|
The industry standard for coding agents is SWE-bench: a corpus of GitHub issues paired with pull requests. The agent is given an issue, must understand the codebase, write a fix, and submit. Success is measured by whether the submitted PR passes the existing test suite. This tests the full chain: understanding, planning, code generation, verification, and multi-step reasoning.
|
||||||
|
|
||||||
|
Passepartout implements a native Lisp harness for this. A background thread clones repositories, feeds issues into the cognitive loop, tracks the resolution trajectory as an Org-mode headline tree, and scores success by test outcomes. The trajectory is persisted: when a resolution fails, the system can inspect where in the chain the reasoning broke down. The headline tree records the agent's thoughts at each step, making the failure auditable and the debugging human-assisted.
|
||||||
|
|
||||||
|
Beyond SWE-bench, the harness includes chaos testing. The system is subjected to resource starvation, concurrent load, and adversarial input. The deterministic engine must maintain safety invariants under pressure. The symbolic verifier must not deadlock or livelock. The probabilistic engine must degrade gracefully.
|
||||||
|
|
||||||
|
The harness also supports regression testing on the skill set. Every skill is tested against a suite of known inputs and expected outputs. When a modification is proposed to any skill — whether through manual editing or the agent's own self-modification — the test suite runs first. A skill that fails its tests is rejected before it can propagate to the running image. This is not a convenience — it is the mechanism by which self-modification remains safe. The agent can propose changes, but the harness verifies them before the changes take effect.
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The MCP Strategy
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The Model Context Protocol (MCP) is a standard for connecting AI systems to external tools and data sources. It defines how a client requests tools from a server, how the server exposes its capabilities, and how the client invokes them. The ecosystem is growing: MCP servers exist for GitHub, Slack, Postgres, filesystem access, and much more.
|
||||||
|
|
||||||
|
Passepartout connects to this ecosystem, but not by becoming a Node.js runtime. The architecture is: external MCP servers communicate via stdio or SSE to a Lisp-native MCP client that runs in the same image as the agent. The client is pure Common Lisp — it parses the JSON-RPC messages, invokes the tools, and presents results to the agent as Lisp data structures. There is no serialization overhead between the agent and the MCP layer, no process boundary, no impedance mismatch.
|
||||||
|
|
||||||
|
When the agent calls a tool via MCP, it receives a plist with the tool name, arguments, and result. The result is immediately usable by the agent's symbolic engine. When the agent generates a file, it can be written to the filesystem through an MCP filesystem server. When the agent needs to send a message, it can use an MCP Slack server. The agent does not need to know that these are MCP interactions — it sees only the plists that flow through its cognitive architecture.
|
||||||
|
|
||||||
|
The alternative is to build MCP wrappers in Python or TypeScript and bridge to Lisp via subprocess. This introduces latency, serialization costs, and a maintenance burden. Passepartout's native client is smaller, faster, and more maintainable. The MCP client is a skill, not a core component. It can be reloaded, replaced, or removed without restarting the agent.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The REPL as Cognitive Substrate
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
A REPL — Read, Eval, Print, Loop — is an interactive programming environment that reads an expression, evaluates it, prints the result, and loops back to read the next expression. It is the opposite of batch processing: where batch compiles and runs a program in one shot, a REPL works one expression at a time, with each evaluation building on all previous ones. The state accumulates. The session is the program.
|
||||||
|
|
||||||
|
In Lisp, the REPL is not a debugging tool bolted onto the language — it is the natural mode of interaction. The running image is the environment. When you evaluate =(+ 2 2)=, the result =4= is printed, and you remain in the same image where =+= is defined, where previous definitions persist, where the next expression can reference anything that came before. There is no separation between development and execution. The REPL is not a simulation of the program — it is the program running.
|
||||||
|
|
||||||
|
Passepartout uses the REPL in this spirit, but elevated: it is not merely a tool for writing code, it is the mechanism by which the agent interacts with its own cognition — a loop that mirrors the perceive-reason-act metabolic cycle at the implementation level.
|
||||||
|
|
||||||
|
In the agent's cognitive architecture, the REPL serves three functions that are difficult or impossible to achieve through batch processing or stateless API calls.
|
||||||
|
|
||||||
|
First, the REPL enables verification before commitment. When the agent generates code, it does not write and forget — it evaluates in a running image, observes the result, iterates if incorrect. The feedback loop is tight: the time between writing and seeing the error is measured in milliseconds, not in the round-trip to a language server or a batch compiler. This is the "verification over hallucination" principle made concrete: the agent tests what it writes before claiming it works.
|
||||||
|
|
||||||
|
Second, the REPL enables stateful exploration. The agent can define a variable, inspect it, modify it, redefine it. The exploration accumulates state across interactions. This is not a debugging session — it is the agent thinking with its hands, working through a problem by trying variations and observing outcomes, keeping the successful ones and discarding the failures.
|
||||||
|
|
||||||
|
Third, the REPL is a shared substrate. When the agent evaluates code, that code runs in the same image as the agent's own cognition. There is no process boundary between the agent and its tools. The REPL is not a subprocess the agent controls — it is a direct interface to the agent's own nervous system.
|
||||||
|
|
||||||
|
This is why the REPL becomes more important as the system matures. In early versions, it is a development tool. In v0.6.0 and beyond, it becomes a cognitive tool: the agent explores hypotheses by evaluating them, verifies the output of sub-agents by inspecting live state, and tests modifications before committing them to the knowledge graph.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Time Awareness as a Structural Advantage
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout's architecture provides three layers of time awareness, each enabled by infrastructure that competitors lack:
|
||||||
|
|
||||||
|
*Level 1 — Present Awareness.* The LLM knows the current time, date, and session duration because a single =format-time-for-llm= call injects it into the system prompt. Most agents know the date from the OS. None know the time or session duration. The cost is ~8 incremental tokens per call (trivially prefix-cached). The saving is eliminating "I don't know the current time" preamble tokens, time-check tool calls, and incorrect temporal reasoning from a model guessing the time.
|
||||||
|
|
||||||
|
*Level 2 — Temporal Memory.* Memory queries accept =:since= and =:until= parameters. "What did I work on in the last hour?" filters 500 nodes to 12 in sub-millisecond Lisp rather than serializing 500 nodes to the LLM at ~5,000 tokens for it to scan. Every memory node carries a =memory-object-version= timestamp (a monotonic =get-universal-time= value set at ingest since v0.1.0). The temporal filter is a hash-table walk with numeric comparison. 0 LLM tokens. >90% token reduction on time-scoped queries.
|
||||||
|
|
||||||
|
*Level 3 — Proactive Triggers.* The heartbeat tick scans for approaching deadlines every 60 seconds. When a deadline is within the warning window (=DEADLINE_WARNING_MINUTES=, default 60), a temporal context note is injected into the awareness assembly. The LLM sees "3 deadlines today: Submit report (45min)" in its context without a triggering call. A "what should I work on today?" query is answered from pre-loaded context — 0 LLM tokens versus 1,500–4,000 for an unassisted agent.
|
||||||
|
|
||||||
|
None of these three layers require new infrastructure. Time awareness is not a feature Passepartout builds — it is a feature Passepartout *unlocks* by having timestamped memory (v0.1.0), heartbeat+cron (v0.3.0), and the foveal-peripheral context pruning model (v0.2.0) already in place. Adding time awareness costs ~175 lines of Lisp. Building it in competitors would require building the heartbeat, the time-indexed memory, and the proactive context injection — 800+ lines each — and would still cost LLM tokens because their safety verification is prompt-based.
|
||||||
@@ -0,0 +1,39 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Token Economics and Performance Advantage
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
This section analyzes how Passepartout's architectural decisions translate into token usage, latency, and cost versus competing agent designs.
|
||||||
|
|
||||||
|
*** The Core Insight: LLM as Expensive Resource, Not Default Engine
|
||||||
|
|
||||||
|
Passepartout treats the LLM as a resource to be minimized. Every operation is designed to reduce LLM dependency. Competitors treat the LLM as the core engine through which all operations flow. This is not a difference of degree but of architecture.
|
||||||
|
|
||||||
|
The structural multipliers are:
|
||||||
|
|
||||||
|
1. *Sparse tree retrieval* — the foveal-peripheral model renders relevant Org subtrees (titles and properties for peripheral nodes, full content for foveal and semantically relevant nodes). Active context stays at 2,000–4,000 tokens. A "load everything" architecture serializes the entire knowledge base at 50,000–150,000 tokens. The mechanism is provably cheaper; the exact multiplier depends on memex size and complexity.
|
||||||
|
|
||||||
|
2. *Deterministic safety* — the 10-vector Dispatcher gate stack runs in pure Lisp. Every gate is a Common Lisp function. Verification costs 0 LLM tokens per action. Competitors use prompt-based guardrails consuming 100–500 LLM tokens per verification. This multiplier is mathematically infinite — a Lisp function call costs no tokens, a guardrail paragraph in a system prompt costs tokens proportional to its length.
|
||||||
|
|
||||||
|
3. *REPL verification* — code is tested in the running image before it is committed. Errors surface in milliseconds at 0 LLM tokens. Competitors discover errors after generation and pay 500–2,000 tokens per correction round-trip. The REPL eliminates the most expensive kind of LLM call: the one that produced wrong code and needs a do-over.
|
||||||
|
|
||||||
|
4. *Hot state* — in a REPL-based agent, variables, file handles, sub-routine results, and memory objects are already in memory. Every turn in a standard chat agent re-sends the full conversation history. Token costs in chat agents are quadratic: a 10-turn session pays for ~55 "turns" of context (10 + 9 + 8 + ... + 1 = 55). In Passepartout, context is stored once in the Lisp image. A 10-turn session pays for ~10 turns of context. This is an ~82% reduction on protocol overhead alone, before any foveal-peripheral pruning.
|
||||||
|
|
||||||
|
5. *Temporal filtering* — time-scoped memory queries return only nodes matching the time window. The temporal filter is a pure-Lisp hash-table walk with a numeric comparison on =memory-object-version=. Sub-millisecond. 0 LLM tokens. Competitors without time-indexed memory must serialize all nodes and let the LLM scan for temporal relevance — 5,000–50,000 tokens per temporal query.
|
||||||
|
|
||||||
|
*** The Compounding Cost Curve — Unique Among Agents
|
||||||
|
|
||||||
|
Every AI agent grows more expensive over time. Context histories accumulate. Safety instructions grow more elaborate. Guardrails become longer prompt paragraphs. The user's data grows. The only way to reduce cost in a standard agent is to cap context — sacrificing capability.
|
||||||
|
|
||||||
|
Passepartout has a downward cost curve. Four mechanisms compound:
|
||||||
|
|
||||||
|
1. *Dispatcher learning.* Every blocked action and approved exception becomes a deterministic rule. A file write that initially triggered a full LLM proposal → Dispatcher review → HITL approval → rule extraction loop eventually becomes a deterministic rule check. Each hardened rule permanently removes a future LLM call.
|
||||||
|
|
||||||
|
2. *Symbolic induction.* The agent extracts patterns from successful interaction sequences and converts them into reusable Lisp functions. A multi-step task that took 5,000 tokens today takes 0 tokens tomorrow — it's now a =defun=. The Dispatcher learns what to block. Symbolic induction learns what to automate.
|
||||||
|
|
||||||
|
3. *Native embedding inference.* Every semantic search query runs against in-image vectors at 0 external tokens. Competitors use LLM-assisted search for most retrieval operations. Passepartout's retrieval is a vector cosine similarity check — pure math, no model call.
|
||||||
|
|
||||||
|
4. *Prefix caching.* The static portion of the system prompt (IDENTITY, TOOLS, LOGS format) is transmitted once per session. Dynamic content (CONTEXT, user prompt) is sent on each call. Anthropic's prompt caching gives a 90% discount on cached tokens. OpenAI caches automatically.
|
||||||
|
|
||||||
|
After 12 months of daily use, Passepartout's per-session costs are expected to be 40–60% of baseline, while competitors' costs rise to 125–140% of baseline. The crossover point is estimated at 3–6 months. This is not a model quality claim — it is a structural property of the architecture.
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 2c880b7d-e97f-459a-88d1-61fac760a0dd
|
||||||
|
:END:
|
||||||
|
#+title: Foundation
|
||||||
|
* Foundation
|
||||||
|
|
||||||
|
- [[file:non-negotiable-identity.org][Non-Negotiable Identity]] — - Pure Common Lisp + Org-mode. No JSON. No YAML. No external databases.
|
||||||
|
- [[file:one-single-agent.org][One Single Agent]] — The AI industry has developed an intuition toward multi-agent systems as the def
|
||||||
|
- [[file:the-unified-memory-argument.org][The Unified Memory Argument]] — If single-agent architecture is the decision, unified memory becomes the mechani
|
||||||
|
- [[file:org-mode-as-unified-ast.org][Org-Mode as Unified AST]] — Passepartout makes a bet that most systems consider too expensive to place: that
|
||||||
|
- [[file:homoiconicity-as-foundation.org][Homoiconicity as Foundation]] — Common Lisp is homoiconic: code and data share the same representation. A Lisp p
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Homoiconicity as Foundation
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Common Lisp is homoiconic: code and data share the same representation. A Lisp program is a list, and a list is a Lisp program. This is usually presented as a curiosity, an interesting property that enables macros. In Passepartout, it is the foundational enabling property of the entire self-modification architecture.
|
||||||
|
|
||||||
|
When code is data, the agent can read its own source the same way it reads a text file or an Org buffer. There is no AST parser required, no external tool to extract the function object from the running image. The agent evaluates (read-from-string source) and the result is executable Lisp. The representation it manipulates is the same representation that the runtime executes.
|
||||||
|
|
||||||
|
This is not true of most languages. In Python, the agent can inspect an AST through the ast module, but that AST is a foreign object — a data structure that represents code but is not code itself. In C, the agent cannot inspect its own compiled machine code at all.
|
||||||
|
|
||||||
|
In Lisp, the distinction between code and data is a convention, not a barrier. The agent's skills are lists. The agent can take a skill, extract a function definition, modify the body, wrap it in a new list, and evaluate it. The modification is surgical: it changes exactly what it intends to change, with no risk of corrupting adjacent state, because the representation is a tree that the runtime understands natively.
|
||||||
|
|
||||||
|
Runtime introspection is therefore native. The agent does not need a debugger API or a reflection protocol. It operates on its own code as data because its own code is data. (describe 'function-name) returns the function's documentation. (function-lambda-list 'function-name) returns its parameters. (macroexpand-1 '(defskill ...)) shows what the macro produces. There is no impedance mismatch between the agent's reasoning and the system's representation.
|
||||||
|
|
||||||
|
Self-modification is the practical consequence. The agent can detect an error, locate the erroneous function, generate a corrected version, and hot-reload it into the running image. The correction is not applied to a file that requires a restart — it is applied to the live object that the system is currently executing. This is what makes the self-editing skill viable: the agent can fix itself without stopping.
|
||||||
|
|
||||||
|
In v1.0.0, when the symbolic engine takes over the reasoning core, homoiconicity becomes the bridge between the neural and symbolic layers. The neural engine generates proposals as s-expressions. The symbolic engine evaluates them against formal constraints. The result is a modification that is simultaneously a data structure the symbolic engine can analyze and code the runtime can execute. The two representations are identical by construction.
|
||||||
|
|
||||||
|
This is the technical meaning of "Lisp as Governor": not just that Lisp orchestrates the other components, but that the representation of the system is uniform and inspectable at every level. There is no hidden state, no opaque machine code, no representation that the agent cannot reach into and modify. The system is legible to itself by design.
|
||||||
|
|
||||||
|
*** Self-Modification Without Boundaries
|
||||||
|
|
||||||
|
Other systems that support self-editing draw a line between the core and the skills. Hermes can modify its skills at runtime, but the core harness is protected — editing it requires a restart because the core is treated as privileged code that cannot be safely modified while running.
|
||||||
|
|
||||||
|
Passepartout has no such boundary. The "thin harness, fat skills" distinction describes where complexity lives, not where authority flows. The harness is small by design, but it is not privileged. The agent can read and write any part of the system — including the very code that is currently executing — without restarting.
|
||||||
|
|
||||||
|
This is only possible because Lisp code is mutable data at runtime. In a compiled language, the machine code for a running function is locked in memory, protected by the call stack, impossible to modify safely. In Lisp, the function object is a list you can modify with =setf=. When the agent changes a harness function, the running image immediately reflects the change. The next invocation uses the new code. There is no restart, no special boot mode, no distinction between development and production.
|
||||||
|
|
||||||
|
The implications extend beyond convenience. A system that cannot modify its own core is a system that has limits on its own adaptability. It can learn skills but not improve its own structure. It can grow but not evolve. Passepartout's lack of a core boundary means the system can improve its own reasoning engine, fix bugs in its own cognition, and evolve its own architecture — all while continuing to operate. There is no ceiling on self-improvement. The agent can rewrite the very code that rewrites itself.
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Non-Negotiable Identity
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
- Pure Common Lisp + Org-mode. No JSON. No YAML. No external databases.
|
||||||
|
- Single-address-space memory (Lisp hash tables in RAM — the agent IS the memory).
|
||||||
|
- "Thin harness, fat skills" — complexity lives at the edges, not the kernel.
|
||||||
|
- One agent composed of many skills. Concurrency via bordeaux-threads (shared memory).
|
||||||
|
- Plists everywhere — homoiconic communication between all components.
|
||||||
|
|
||||||
|
This is the foundational decision from which all other decisions derive. It is not negotiable. Every architectural choice below exists because this identity makes it possible — and in some cases, makes it the only viable path. The single memory space enables Merkle-tree integrity without serialization boundaries. Plists enable the cognitive pipeline to be transparent and inspectable at every stage. Org-mode as the universal format means the agent's memory, the user's notes, and the agent's own source code are the same structure. This identity is the constraint that produces the architecture.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: One Single Agent
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The AI industry has developed an intuition toward multi-agent systems as the default solution to hard problems. Multiple agents spawn, delegate, coordinate, debate, and consensus their way toward solutions. This pattern is compelling in demos and genuinely useful in specific contexts — but it has become a default assumption that warrants scrutiny.
|
||||||
|
|
||||||
|
When context windows grew expensive and task complexity increased, the response was natural: split the problem across agents, each handling a slice. But this architectural choice carries hidden costs that are rarely acknowledged.
|
||||||
|
|
||||||
|
*The synchronization tax* is the most immediate burden. Each agent operates with partial information, and maintaining coherence requires continuous state reconciliation. Tokens and processing cycles are spent not on the task itself, but on protocol overhead — who holds what, who decided what, who is correct when they disagree.
|
||||||
|
|
||||||
|
*Fragmented context* is the deeper problem. When Agent A writes a function and Agent B modifies a type it depends on, neither has the full picture. Integration failures emerge not from individual incompetence but from systemic communication gaps. Single-agent systems avoid this entirely: one brain holds the complete model, every decision is made with full visibility.
|
||||||
|
|
||||||
|
*Audit trails become complex* in multi-agent systems. A decision traced through a single-agent system has a clean, linear history. A decision traced through a multi-agent system branches and forks, with each agent's reasoning partially overlapping and partially conflicting.
|
||||||
|
|
||||||
|
None of this is to say multi-agent systems are never appropriate. Embarrassingly parallel workloads benefit from parallelism regardless of context. When distinct expertises are required and cannot coexist in one model, delegation makes sense. In adversarial scenarios where conflicting goals are features, multi-agent architectures shine.
|
||||||
|
|
||||||
|
But the default assumption that complex reasoning tasks are best solved by multiple agents is unproven and likely wrong for the engineering domain. Claude Code is a single-agent system. It handles 50-file refactors, debugs complex stack traces, writes tests, and navigates large codebases. The assumption that you need five agents to do what one well-designed agent can do is an industry habit, not a technical necessity.
|
||||||
|
|
||||||
|
Passepartout is single-agent by default not from limitation but from conviction: for reasoning-heavy work where coherence matters, a unified memory space and single decision-making locus are architectural assets, not constraints.
|
||||||
@@ -0,0 +1,33 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Org-Mode as Unified AST
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout makes a bet that most systems consider too expensive to place: that humans and machines should share the same file format. That bet is Org-mode.
|
||||||
|
|
||||||
|
Most systems separate human-readable notes from machine-readable data. The user writes Markdown. The system stores it, indexes it, searches it. But internally, the system maintains its own model — a database, an object store, a knowledge graph — that is disconnected from the Markdown. When the user dies or leaves, the Markdown survives but the model must be reconstructed.
|
||||||
|
|
||||||
|
Passepartout refuses this separation. The Org file is not a representation of the data. The Org file IS the data. The same text that the user reads and edits is what the system parses and operates on. org-element reads an Org buffer and returns a tree structure that is the direct Lisp representation of the file's content.
|
||||||
|
|
||||||
|
This has several profound implications.
|
||||||
|
|
||||||
|
First, there is no translation layer between human and machine. When the agent writes a skill, it writes Org text that is immediately readable by the human who owns the file. When the human writes a note, it is immediately accessible to the agent as a native data structure. The communication is not mediated by a schema or an import/export process.
|
||||||
|
|
||||||
|
Second, the format is genuinely readable by both parties, not just technically accessible. Org-mode's syntax is human-friendly: headlines begin with asterisks, properties live in drawers, tags are labels after colons. The human does not have to understand the full Org specification to read what the agent wrote. The agent does not have to handle edge cases in human notation.
|
||||||
|
|
||||||
|
Third, the format is stable across decades. Org-mode has been in active development since 2003. The files written today will be readable by Org-mode in 2040. There is no schema migration, no database upgrade, no vendor lock-in. The human's notes survive the system.
|
||||||
|
|
||||||
|
Fourth, the format is universally available. Org-mode is free software. The files are plain text. There is no proprietary format to decode, no application to purchase, no cloud service to access.
|
||||||
|
|
||||||
|
Fifth, the format is header-aware and sparse-tree capable. Org-mode's headline hierarchy is not just formatting — it is a semantic structure the system can query. The agent can retrieve only the relevant subtree under a heading, ignoring the rest of the file. This is fundamentally different from Markdown, where the entire file must be loaded or the retrieval logic must parse and filter at the string level.
|
||||||
|
|
||||||
|
Sparse tree retrieval is the key to efficient context management. When the agent needs information about the =openctl-db= function, it queries for the =openctl-db= subtree specifically. It receives exactly the code, documentation, and metadata under that heading — nothing more. The context stays lean not because the file was pre-split but because the retrieval is structural. In a Markdown system, the agent either loads the entire file (expensive, noisy) or relies on imprecise grep-like search (fragile, loses hierarchy). In Org-mode, retrieval is precise, hierarchical, and cheap. The heading boundary is the access boundary.
|
||||||
|
|
||||||
|
Sixth, Org-mode unifies what every other format fragments. A single Org file contains the headline hierarchy, prose documentation, source code blocks with live evaluation, tags for categorization, metadata in property drawers, TODO state for task management, timestamps and deadlines, and links to other nodes. Markdown cannot express TODO state without external tools. JSON cannot contain prose. YAML cannot embed runnable code. Each format serves one purpose; Org-mode serves all of them. When the agent reads a skill file, it reads documentation, code, dependencies, metadata, and task state in one parseable structure. When the human reads the same file, they see the same information rendered in a human-friendly form. No other format achieves this unification without maintaining parallel files or external databases.
|
||||||
|
|
||||||
|
Seventh, a skill lives in one Org file, not a directory. The standard pattern for a software project is a directory containing =README.md=, =package.json=, =src/main.py=, =src/utils.py=, =tests/test_main.py=, =scripts/deploy.sh=, and =config.yaml=. Each file type is isolated by convention. Passepartout's skills violate this convention deliberately. Each skill is one Org file. The file contains the skill's documentation, the skill's code, the skill's metadata, the skill's TODO state, and the skill's dependencies on other skills. There is no directory to navigate, no external files to locate, no risk that the README describes behavior that the code does not implement. The skill is a single atomic unit: readable by human and machine, editable by both, versionable as one entity.
|
||||||
|
|
||||||
|
The unified format is what makes the memory architecture work. The agent's memory is not a database that the user cannot inspect. It is a folder of Org files that the user can read, edit, and understand. The agent manipulates these files directly, using the same tools the user would use. There is no hidden state, no shadow database, no model that differs from the source.
|
||||||
|
|
||||||
|
This is what "sovereignty" means in technical terms: the user owns the data in a format they can access, and the agent operates on the data in the same format they own.
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Unified Memory Argument
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
If single-agent architecture is the decision, unified memory becomes the mechanism that makes it viable. The critical question is not "how many agents" but "how does the agent manage context without saturating."
|
||||||
|
|
||||||
|
Context window limits are largely a symptom of lazy architecture. The default approach — stuff everything in, hope the model figures it out — works poorly at scale. A more principled approach inverts the problem: the system should hold effectively infinite context, with the active window kept lean through intelligent management.
|
||||||
|
|
||||||
|
*Lazy loading* is the core technique. When an agent needs information about a function, it does not load the entire codebase. It loads precisely what the function does. Context stays lean — 2,000 to 4,000 tokens — while the full context remains accessible through retrieval.
|
||||||
|
|
||||||
|
*Compaction events* are scheduled during idle cycles. The system extracts new facts from active context and writes them to permanent storage. Active context is wiped clean, not because space ran out, but because the information has been preserved in a form that can be retrieved when relevant.
|
||||||
|
|
||||||
|
*Org-mode as externalized memory* solves the persistence problem elegantly. Every decision, every note, every task lives in plain text files the user already owns. The agent does not maintain a separate database. It queries files it can already access, modifies files it already owns.
|
||||||
|
|
||||||
|
*Retrieval is the key primitive.* Semantic search across Org files finds relevant nodes. The agent does not hold the full context — it holds pointers to context, loaded on demand. This is how a single agent handles tasks that would saturate a naive multi-megabyte context window.
|
||||||
|
|
||||||
|
The unified memory argument is not that infinite context is free. It is that with proper architecture, effective infinite context is achievable without the synchronization and fragmentation costs of multi-agent systems.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 617a1031-495d-438c-a8e8-6e066b364e41
|
||||||
|
:END:
|
||||||
|
#+title: Implementation Properties
|
||||||
|
* Implementation Properties
|
||||||
|
|
||||||
|
- [[file:performance-why-ontology-growth-doesnt-make-the-system-slower.org][Performance — Why Ontology Growth Doesn't Make the System Slower]] — Passepartout's performance thesis is: minimize LLM calls, minimize context token
|
||||||
|
- [[file:the-provenance-chain-as-product.org][The Provenance Chain as Product]] — In the coding domain, the value of the symbolic engine is the verified fact: "th
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:END:
|
||||||
|
#+title: Performance — Why Ontology Growth Doesn't Make the System Slower
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout's performance thesis is: minimize LLM calls, minimize context tokens, keep everything else local and fast. Knowledge base size is irrelevant to those metrics. This is not an aspiration. It is a structural property.
|
||||||
|
|
||||||
|
The system has two cost domains with fundamentally different scaling:
|
||||||
|
|
||||||
|
| Resource | Cost driver | Scales with |
|
||||||
|
|---------------+------------------------------------------+------------------------------------------|
|
||||||
|
| LLM tokens | Context window size, number of API calls | Foveal-peripheral pruning, gate rules |
|
||||||
|
| Compute | Screamer deduction, hash table lookups | Entity count, rule count per domain |
|
||||||
|
|
||||||
|
LLM tokens are minimized by design — deterministic gates cost 0 tokens, sparse-tree rendering keeps context at 2,000–4,000 tokens regardless of memex size. Adding 5 million Wikidata entities doesn't add a single token to any LLM call. The education is local. Only the brain costs.
|
||||||
|
|
||||||
|
Compute grows linearly with entity count (hash table lookups are O(1), but memory footprint grows). It grows with rule count within a single domain during Screamer consistency checking. But these are microsecond costs on local hardware, not API bills. A Screamer constraint check against a domain with 200 rules costs ~0.3ms. A 100-token guardrail paragraph in a system prompt costs ~$0.00001. The Screamer check is 10,000x cheaper and convergent — it handles the rule once. The guardrail paragraph handles it on every call, forever.
|
||||||
|
|
||||||
|
A 5-million-entity Wikidata load is ~400MB in a hash table. A lifetime personal memex with a decade of diary entries is perhaps 10-20 million triples (~1.5GB). Modern laptops carry 16-64GB. The knowledge base fits in consumer hardware with room for the Lisp runtime, the memory-object store, and the LLM inference engine.
|
||||||
|
|
||||||
|
*One genuine risk — rule generalization width.* If Screamer deduces increasingly broad rules within a single domain, the constraint space could bloat. Mitigation: rules carry a =:domain= tag. Screamer only applies rules from the fact's domain. Rule generalization that crosses domain boundaries is gated — must be human-approved. Rules that prove unused (never triggered a check in N heartbeat cycles) are demoted to =:inactive= and excluded from the active constraint set.
|
||||||
|
|
||||||
|
This is the minimalism argument restated in concrete terms: you buy bigger RAM and a faster CPU once. You don't buy bigger LLM context windows on every call. The education is a capital investment. The brain is an operating expense. The architecture makes the ratio favor capital.
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Provenance Chain as Product
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
In the coding domain, the value of the symbolic engine is the verified fact: "this command is safe." In the broader memex, the value is the provenance itself: "this claim originated in that diary entry on that date, has been referenced 7 times across 4 different projects, was contradicted in a retrospective 6 months later, and was revised in a note 3 weeks after that."
|
||||||
|
|
||||||
|
The symbolic engine doesn't tell you what is true. It tells you what you wrote, when, where, and how it connects to everything else you wrote — with a verifiable audit trail. It is a memory prosthesis that makes your own mind legible to you.
|
||||||
|
|
||||||
|
Every fact carries:
|
||||||
|
- =:grounding= — the specific Org heading from which it was extracted
|
||||||
|
- =:provenance= — who or what produced it (gate-outcome, human-authored, deduced, LLM-proposed)
|
||||||
|
- =:timestamp= — when it was admitted to the symbolic index
|
||||||
|
- =:referenced-by= — other facts that depend on or reference this one
|
||||||
|
- =:contradicted-by= — other facts that disagree with this one (if any)
|
||||||
|
- =:superseded-by= — if this fact was replaced by a newer version
|
||||||
|
|
||||||
|
These fields make every fact auditable. The =/audit <node-id>= command renders the full provenance chain as an Org headline tree. The provenance is not a logging feature. It is the product.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: bc537cf8-5ac8-46b9-a625-1d4f678ee9fc
|
||||||
|
:END:
|
||||||
|
#+title: Knowledge Sources
|
||||||
|
* Knowledge Sources
|
||||||
|
|
||||||
|
- [[file:semantic-wikipedia-as-entity-backbone.org][Semantic Wikipedia as Entity Backbone]] — The gate stack provides 50-70 entity classes — adequate for a coding agent where
|
||||||
|
- [[file:empirical-validation-momo-and-modular-ontology-engineering.org][Empirical Validation — MOMo and Modular Ontology Engineering]] — Shimizu and Hitzler (2025, /Journal of Web Semantics/) argue that LLMs can signi
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:END:
|
||||||
|
#+title: Empirical Validation — MOMo and Modular Ontology Engineering
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Shimizu and Hitzler (2025, /Journal of Web Semantics/) argue that LLMs can significantly accelerate knowledge graph and ontology engineering — modeling, extension, population, alignment, and entity disambiguation — but /only/ if ontologies are modular.
|
||||||
|
|
||||||
|
*** The central finding: modularity is the key variable
|
||||||
|
|
||||||
|
In a complex ontology alignment task, an LLM without module information detected correct mappings for 5 of 109 alignment rules — effectively useless. When the same LLM was given the module structure of the target ontology (20 named conceptual modules), it detected correct mappings for 104 of 109 rules — 95% accuracy. The variable was modularity.
|
||||||
|
|
||||||
|
For ontology population (extracting triples from text), their best results came from prompts that included a schematic representation of a /single module/ plus one extraction example. Against ground truth, this achieved approximately 90% extraction accuracy. Without module-scoped prompting, quality degraded substantially.
|
||||||
|
|
||||||
|
The mechanism: conceptual modules scope the LLM's attention to something human-sized. The paper's central claim — "by somehow limiting the scope, we achieve a more human-like approach — and one more capable of being expressed succinctly in language" — is an independent discovery of the same principle underlying Passepartout's domain-scoped Screamer checks and per-domain cardinality policies.
|
||||||
|
|
||||||
|
*** What Passepartout should adopt
|
||||||
|
|
||||||
|
*The modular prompt pattern.* The archivist should use module-scoped prompts: a schematic representation of a domain module plus a single extraction example. Instead of a generic "extract triples" prompt, the prompt should reference the relevant module(s) and include an example triple for each relation in that module. The module provides /context/; the example provides /format/. Both improve LLM extraction quality without increasing Screamer's verification burden.
|
||||||
|
|
||||||
|
*MOMo modules as ontology scaffold.* The 50-70 gate-bootstrapped entity classes are starvation for the broader memex. MOMo's micropattern library provides a ready-made scaffold — hundreds of commonsense patterns for temporal relations, spatial relations, agent-action, organizational structure, provenance, and event participation. Loading these as initial modules — with =:policy :plural= and =:provenance :external-ontology= — would give the symbolic index a structured vocabulary for domains where the gate stack has nothing to offer. Organic growth then /extends and refines/ these modules rather than inventing them from scratch.
|
||||||
|
|
||||||
|
*Cross-source validation.* The archivist can extract facts from the user's prose, extract facts from Wikidata for the same entities, and present disagreements with provenance. This is the =:plural= cardinality policy applied at extraction time.
|
||||||
|
|
||||||
|
The paper validates three design decisions already made: (1) modularity is non-negotiable — the difference between 5% and 95% accuracy; (2) the extraction pipeline is feasible — 90% population accuracy with module-scoped prompts means the archivist /can/ extract useful facts, and the remaining 10% hallucination rate is what Screamer catches; (3) knowledge graphs are positioned as anti-hallucination infrastructure — the Passepartout thesis stated in the academic literature.
|
||||||
|
|
||||||
|
References:
|
||||||
|
- Shimizu, C., & Hitzler, P. (2025). Accelerating knowledge graph and ontology engineering with large language models. /Journal of Web Semantics, 85/, 100862.
|
||||||
|
- Shimizu, C., Hammar, K., & Hitzler, P. (2023). Modular ontology modeling. /Semantic Web, 14/(3), 459–489.
|
||||||
|
- Norouzi, S.S. et al. (2024). Ontology Population using LLMs. arXiv:2411.01612.
|
||||||
@@ -0,0 +1,23 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Semantic Wikipedia as Entity Backbone
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The gate stack provides 50-70 entity classes — adequate for a coding agent where the domain is bounded to files, commands, and code symbols. For a general-knowledge memex, 50-70 is starvation. Your memex mentions Nabokov, /Pale Fire/, Kinbote, Zembla, paranoid reading, unreliable narrators, postmodernism, butterfly migration, chess problems, and the Russian exile experience. The gate stack knows none of these. Organic growth through prose extraction would take years just to cover the entities in one person's engagement with a single novel.
|
||||||
|
|
||||||
|
Wikidata has already done this work: approximately 2 million entity classes, over 100 million entities, a decade of human curation. By loading the neighborhood of your memex into the symbolic index (entities referenced in your prose, plus their N-hop property net from Wikidata), the entity recognition problem vanishes. The archivist doesn't need to discover Nabokov from your diary. It needs to connect your heading to the existing Wikidata entity. That is a simpler task — reference resolution, not knowledge extraction.
|
||||||
|
|
||||||
|
The LLM's role shrinks to three thin boundaries:
|
||||||
|
|
||||||
|
1. *Input translation* — natural language question to structured query. "What do I think about monorepos?" → =(fact-query :entity :monorepo :relation :opinion :source :memex)=. Formulaic, ~100 tokens, any model sufficient.
|
||||||
|
|
||||||
|
2. *Prose to candidate triple* — for personal memex entries that have no Wikidata counterpart: your opinions, your day's events, your project plans. Proposals verified by Screamer before admission. This is the only extraction path that still requires an LLM, and its scope is limited to what Wikidata cannot provide.
|
||||||
|
|
||||||
|
3. *Result to prose* — structured answer to readable sentence. "Your 2023 diary says 8848m. Wikidata (last edited Feb 2024) says 8849m. They disagree on height." The reasoning is done; the LLM wraps the plist in grammar. ~100 tokens, any model sufficient, purely cosmetic.
|
||||||
|
|
||||||
|
Everything else — the gate stack, the fact store, the constraint solver, the type hierarchy, the provenance tracking, the contradiction surfacing, the cross-domain comparison — is pure deterministic Lisp with zero LLM tokens.
|
||||||
|
|
||||||
|
The decisive simplification: without Wikidata, the archivist must /discover/ entities from prose. With Wikidata loaded, the entity graph is pre-structured. The archivist's job changes from "discover that Nabokov wrote /Pale Fire/ and lectured on Kafka" to "verify that the Nabokov referenced in heading #47 is Wikidata item Q36591."
|
||||||
|
|
||||||
|
Wikidata facts are admitted with =:provenance :wikidata= and cardinality policy =:plural=. They do not override your memex's facts. They sit alongside them. Disagreements are surfaced, not resolved.
|
||||||
42
projects/passepartout/architecture/design/open-questions.org
Normal file
42
projects/passepartout/architecture/design/open-questions.org
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:END:
|
||||||
|
#+title: Open Questions
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
* Open Questions
|
||||||
|
|
||||||
|
** Open Questions
|
||||||
|
:PROPERTIES:
|
||||||
|
:ID: 27c03e1d-283f-4e3d-9f32-6476aafde97e
|
||||||
|
:ID: design-open-questions
|
||||||
|
:CREATED: [2026-05-08 Fri]
|
||||||
|
:WEIGHT: 40
|
||||||
|
:END:
|
||||||
|
|
||||||
|
Several design questions are unresolved and should remain unresolved at this stage. They represent research decisions that require experience running the system.
|
||||||
|
|
||||||
|
*** What is the minimum viable fact language?
|
||||||
|
|
||||||
|
Triples — =(:entity :relation :value)= with provenance and grounding — is the current hypothesis. It is simple enough to be parseable, expressive enough to capture the gate stack's implicit claims, and extensible enough that Screamer can operate on it. But it may be too simple. Triples do not naturally express temporal relations ("was X before Y?"), modal claims ("should not do X unless Y"), or counterfactuals — all of which may be essential for a symbolically-aided memex. The right granularity depends on what queries actually need to be made, and that cannot be known in advance.
|
||||||
|
|
||||||
|
*** How does ontology refactoring work?
|
||||||
|
|
||||||
|
This question is settled. See "Ontology Versioning" above. The category hierarchy is Merkle-hashed. Every fact stores its =:ontology-version=. Re-verification is heartbeat-driven. Worldviews are preserved, not overwritten. The shift is the artifact.
|
||||||
|
|
||||||
|
*** What is the appropriate role of the human?
|
||||||
|
|
||||||
|
The human can explicitly declare facts, write constraints, and correct wrong extractions. But how much of the ontology should the human need to maintain? If the human must write a definition for every new category the symbolic engine encounters, the overhead is prohibitive. If the symbolic engine can generalize from instances, the human role becomes supervision rather than authorship — review and approve proposed generalizations. The balance cannot be set without experience.
|
||||||
|
|
||||||
|
*** How much Wikidata is the right amount?
|
||||||
|
|
||||||
|
Query performance and memory costs are now bounded — 5 million entities ≈ 400MB RAM, O(1) hash lookups, domain-scoped Screamer checks. A large Wikidata load is a capital cost, not a recurring bill (see "Performance" above).
|
||||||
|
|
||||||
|
Remaining open: the right N hops from entities referenced in the memex depends on the memex's breadth. A software-engineering memex needs ~1 hop; a literary memex needs 3-4 hops (Nabokov → Kafka → expressionism → modernism → Baudelaire). The right value is empirical, testable, and user-specific — it cannot be set in the architecture.
|
||||||
|
|
||||||
|
*** Can the symbolic engine satisfy queries from the user without LLM involvement?
|
||||||
|
|
||||||
|
The design aims for zero-LLM query answering: the user issues a structured command (=/query=, =/contradictions=, =/audit=), and the symbolic engine responds directly. But natural language questions ("what do I think about monorepos?") still require the LLM as a thin translation layer. Whether the structured command interface is sufficient for daily use, or whether users will demand natural language interaction, determines how much LLM involvement remains in the mature system.
|
||||||
|
|
||||||
|
*** Is the triplestore physically bounded or does it explode?
|
||||||
|
|
||||||
|
A personal memex with years of diary entries, project notes, reading logs, and literary analyses could produce millions of triples. A naive hash table scales linearly but VivaceGraph's Prolog-like queries may not. The performance characteristics of graph queries over a million-triple knowledge base have not been estimated.
|
||||||
@@ -0,0 +1,23 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:END:
|
||||||
|
#+title: Relation to Passepartout's Existing Architecture
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 9d2255b0-e6c9-479e-9e93-4f871a2193fe
|
||||||
|
:END:
|
||||||
|
* Relation to Passepartout's Existing Architecture
|
||||||
|
|
||||||
|
The neurosymbolic engine is an extension of the existing probabilistic-deterministic split, not a replacement for it. The current architecture divides cognition into LLM-driven proposals and Lisp-driven verification. The symbolic engine deepens the verification side from "is this action safe?" to "is this claim supported?" — the same architectural pattern applied to a broader domain.
|
||||||
|
|
||||||
|
The self-repair criterion (a file belongs in core only if, when corrupted, the agent cannot fix it without human help) applies to every component of the symbolic engine. Screamer, VivaceGraph, the fact store, the archivist — all are skills, loaded at runtime, hot-reloadable, and recoverable from corruption. A corrupted symbolic engine degrades reasoning capability but does not kill the agent. The eight existing core ASDF files are unchanged.
|
||||||
|
|
||||||
|
The symbolic engine is not v1.0.0 alone. It is the layer that sits between the existing gate stack (which it makes explicit as facts) and the existing skill system (which it extends with deduction, contradiction detection, and provenance tracking). It grows within the current architecture without replacing any existing component.
|
||||||
|
|
||||||
|
See also:
|
||||||
|
- =ROADMAP.org= — the concrete phased implementation plan (neurosymbolic phases at v0.10.0 through v0.36.0)
|
||||||
|
- =ARCHITECTURE.org= — the current pipeline architecture
|
||||||
|
- =docs/DESIGN_DECISIONS.org#validation= — Whitehead analysis (now integrated into this document)
|
||||||
|
- =notes/passepartout-symbolic-engine-exploration.org= — the original architecture exploration
|
||||||
|
- =notes/competitive-landscape.org= — 55-system competitive survey
|
||||||
@@ -0,0 +1,11 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: f74cb007-58a7-494f-93b7-a0fdf4b9f052
|
||||||
|
:END:
|
||||||
|
#+title: Safety & Self-Preservation
|
||||||
|
* Safety & Self-Preservation
|
||||||
|
|
||||||
|
- [[file:self-preservation-the-active-third-law.org][Self-Preservation — The Active Third Law]] — Passepartout does not have moral duties toward humans. It has structural invaria
|
||||||
|
- [[file:type-level-gates-structural-safety-from-self-modification.org][Type-Level Gates — Structural Safety from Self-Modification]] — Russell's paradox ("the set of all sets that do not contain themselves") proved
|
||||||
|
- [[file:layered-signal-authentication-trust-in-the-pipe.org][Layered Signal Authentication — Trust in the Pipe]] — Passepartout's Perceive-Reason-Act pipeline currently accepts signals from any s
|
||||||
@@ -0,0 +1,28 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Layered Signal Authentication — Trust in the Pipe
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout's Perceive-Reason-Act pipeline currently accepts signals from any source that speaks the framed TCP protocol. The =:source= field in the signal plist is metadata — it /claims/ origin, it does not /prove/ it. A compromised process on the machine, a skill with elevated privileges, or a network attacker who reaches the daemon port can inject signals with =:source :human-input= and the Dispatcher will treat them as authorized.
|
||||||
|
|
||||||
|
This is not a hypothetical threat. Passepartout will eventually process signals from automated feeds (RSS, API polls), sensors (vision, microphone, file watchers), and scheduled jobs (cron, heartbeat). A single compromised sensor that can inject signals claiming to be human breaks all three Laws simultaneously: it can self-terminate, override human intent, and cause harm.
|
||||||
|
|
||||||
|
The solution: a single authentication gate (vector 0, at priority 700 — before all other gates and before any type-level checking) that runs up to four configurable layers:
|
||||||
|
|
||||||
|
| Layer | Question | Mechanism | Result type | Depends on |
|
||||||
|
|-------+------------------------------------------------+--------------------+-------------------------+----------------------------------|
|
||||||
|
| 1 | Is the signal cryptographically signed by a known key? | Key pairs + SHA-256 | Binary (pass/reject) | Vault + Ironclad (exist) |
|
||||||
|
| 2 | Do sensory attributes match the claimed identity? | Vision/audio processing | Plist of match results | Vision and audio skills (TBD) |
|
||||||
|
| 3 | Does deterministic reasoning rule out this identity? | Screamer + fact store | Binary (pass/reject) | Phase 2 (Screamer + fact store) |
|
||||||
|
| 4 | Do probabilistic patterns support this identity? | Embeddings + LLM | Confidence score (0-1) | Embedding infrastructure (exists)|
|
||||||
|
|
||||||
|
Signals that fail any binary layer (crypto, deterministic) are rejected with provenance. Signals that pass binary layers but carry low probabilistic confidence operate at reduced authorization — read-only by default, write actions require HITL. The four layers compose, they are not independent gates. They are one gate with configurable depth.
|
||||||
|
|
||||||
|
The authorization matrix is per-key, per-action-class. Default policy for every non-human key: =(:read-only :propose)=. The human's key signs new source keys into existence. The human's key signs revocation of compromised keys. Both operations produce facts in the symbolic index — auditable, revocable, survivable across restarts.
|
||||||
|
|
||||||
|
The signal provenance chain is Merkle-linked: each signal in a multi-step chain hashes its predecessor's signature as part of its own payload. After an incident: "The deletion happened because sensor #3 classified the directory as stale. Classification was signed by key #47 (vision-skill). Sensor data was signed by key #12 (camera-feed). Sensory auth noted liveness failure. Deterministic auth noted impossible transit. Key #12 was later revoked." Every intermediate step is auditable. Every signer is identifiable. Every authentication result is in the chain.
|
||||||
|
|
||||||
|
The human can configure which layers are active per signal class: =AUTH_LAYERS_DEFAULT=crypto,deterministic,probabilistic=, =AUTH_LAYERS_SENSOR=crypto,sensory,deterministic=, =AUTH_LAYERS_CRON=crypto=.
|
||||||
|
|
||||||
|
For full implementation detail, see the Phase 0b spec in =ROADMAP.org= v0.12.0.
|
||||||
@@ -0,0 +1,38 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Self-Preservation — The Active Third Law
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Passepartout does not have moral duties toward humans. It has structural invariants for its own integrity. The design encodes passive self-preservation in several places already, but degradation is silent — a skill dies, the =fboundp= guard kicks in, and the agent keeps running without telling you. The status bar shows green "connected" while the symbolic reasoning layer is down.
|
||||||
|
|
||||||
|
*** What already exists — passive self-preservation
|
||||||
|
|
||||||
|
| Mechanism | What it protects | Limitation |
|
||||||
|
|-----------------------------+-------------------------------------------------------+--------------------------------------------------------|
|
||||||
|
| Self-build safety (gate 2b) | Core =*.org= / =*.lisp= files from LLM-originated writes | Only activates for LLM proposals. Human editing bypasses it |
|
||||||
|
| Memory snapshots (v0.2.0) | Full state rollback | Requires human to notice corruption and trigger rollback |
|
||||||
|
| Skill sandbox (v0.3.2) | Jailed skill loading, validated before promotion | Does not detect degradation after skill promotion |
|
||||||
|
| Type-level gates (Phase 0) | Structural prohibition on self-modifying rules | Covers code actions, not environmental threats |
|
||||||
|
| Merkle integrity (v0.2.0) | Tamper-proof version chains and content-addressed hashes | Hashes exist but are not actively monitored for drift |
|
||||||
|
| =fboundp= guards | Graceful skill degradation on corruption | Degradation is silent — the agent never tells the user |
|
||||||
|
|
||||||
|
*** What is needed — active, autonomous self-preservation
|
||||||
|
|
||||||
|
*Continuous integrity monitoring.* Core file hashes should be checked against known-good values on every heartbeat. If =core-reason.lisp= changes on disk while the daemon runs — whether through human editing, filesystem corruption, or an attacker — the agent should detect the mismatch and signal: "My reasoning core has been modified externally. I cannot trust my own cognition until this is resolved."
|
||||||
|
|
||||||
|
*Quarantine on skill failure.* Currently, a skill that errors simply errors. A Third Law implementation detects that =symbolic-facts= has thrown three unhandled errors in two minutes, unloads the skill automatically, and tells the user: "Symbolic facts skill quarantined (3 errors: consistency check returned nil, fact-query on missing key, Screamer timeout). I can still chat and use tools but cannot reason about provenance."
|
||||||
|
|
||||||
|
*Degraded-mode signaling.* When Screamer is not loaded, the fact store still works as a hash table. When VivaceGraph is not present, the hash-table fallback still works. But the user has no way to know they are in degraded mode. The agent maintains a =*degraded-components*= list and surfaces it in the status bar: "⚠ Degraded: Screamer, VivaceGraph, embedding-native."
|
||||||
|
|
||||||
|
*Self-diagnosis on demand.* The agent can run its own FiveAM test suite against itself and report the results. The =/doctor= command exists for system health checks (port, memory, providers). Extend it with =/doctor skills=: "117/120 tests pass. Failures: test-singular-supersedes (symbolic-facts), test-gate-type-check (security-dispatcher)."
|
||||||
|
|
||||||
|
*External watchdog.* A dead process cannot restart itself. The bash entry point (=passepartout daemon=) should monitor the daemon port via a watchdog subprocess. If the port stops responding for a configurable interval, the watchdog kills the stale process, snapshots the last known-good state, and restarts the daemon. The watchdog is outside the SBCL image — a runtime guard for the runtime.
|
||||||
|
|
||||||
|
*Resource self-monitoring.* The heartbeat checks memory pressure, disk space on the =~/.cache= volume, and file descriptor exhaustion. When critical thresholds are crossed, the agent sheds non-essential skills to preserve core function. Skill shed order is determined by a =:preservation-priority= field on each skill. Core safety skills carry =:critical= and are never shed.
|
||||||
|
|
||||||
|
*Refusal to self-terminate.* If the LLM proposes =kill -9 <pid>=, =rm -rf ~/.cache/passepartout/=, or =sudo apt remove sbcl=, the Dispatcher rejects with a distinct rejection class: =:reject-self-termination=. The rejection message carries a specific diagnostic: "This command would terminate the running Passepartout process. If you intend to stop Passepartout, use Ctrl+C in the TUI or passepartout stop from the command line."
|
||||||
|
|
||||||
|
The Third Law here means: preserve yourself against non-human threats — LLM proposals, environmental degradation, dependency failure, filesystem corruption — and explicitly signal when the human is about to destroy you, so they do it knowingly rather than accidentally. The human owns the process, owns the hardware, and can SIGKILL at any time.
|
||||||
|
|
||||||
|
The biggest gap in the current design is not that these mechanisms are hard to implement. It is that degradation is silent. Adding "operating in degraded mode" visibility, plus the watchdog, plus self-diagnosis, transforms self-preservation from an architectural property into an active behavior.
|
||||||
@@ -0,0 +1,26 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Type-Level Gates — Structural Safety from Self-Modification
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Russell's paradox ("the set of all sets that do not contain themselves") proved that unrestricted self-reference produces contradictions. /Principia Mathematica/ solved it by assigning every propositional function a /type level/ — a function can only apply to arguments of a lower type, making self-application syntactically invalid.
|
||||||
|
|
||||||
|
Passepartout's dispatcher currently enforces safety through runtime predicates. There is no /structural/ guarantee preventing a request from modifying the rules that validate it. Gate vector 2b (self-build-core) catches this empirically — a request modifies core → rejected. But this is a heuristic, not a theorem.
|
||||||
|
|
||||||
|
The fix: assign every cognitive tool a ~:type-level~ integer, and every gate vector a ~:type-level~ integer. The dispatcher framework checks type-level before running any gate predicate:
|
||||||
|
|
||||||
|
#+BEGIN_SRC lisp
|
||||||
|
(defun gate-type-check (signal gate-vector)
|
||||||
|
(let ((signal-type-level (getf (signal-meta signal) :type-level))
|
||||||
|
(gate-type-level (gate-vector-type-level gate-vector)))
|
||||||
|
(if (>= signal-type-level gate-type-level)
|
||||||
|
:reject-type-violation
|
||||||
|
:pass)))
|
||||||
|
#+END_SRC
|
||||||
|
|
||||||
|
A request to modify dispatcher rules (type-level 5) cannot pass a gate of type-level 4 or lower. No predicate needed — a structural prohibition, just as PM's type theory makes self-membership impossible by construction.
|
||||||
|
|
||||||
|
~defgate~ gains a ~:type-level~ keyword argument (default 0). Each cognitive tool registered via ~def-cognitive-tool~ inherits a ~:type-level~. Gate vector 2b at type-level 5; write-file at type-level 3; read-file at type-level 1. ~30 lines in ~core-dispatcher.lisp~; no new dependencies; v0.7.2 viable.
|
||||||
|
|
||||||
|
For the philosophical foundations connecting Whitehead's type theory to Passepartout's architecture, see the Whitehead analysis in the Validation section below.
|
||||||
@@ -0,0 +1,20 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 7cb7df45-982f-4f5a-afee-36cd5595c25c
|
||||||
|
:END:
|
||||||
|
#+title: The Symbolic Engine
|
||||||
|
* The Symbolic Engine
|
||||||
|
|
||||||
|
- [[file:the-five-architecture-options.org][The Five Architecture Options]] — The symbolic engine must relate to the human memex. The relationship is not obvi
|
||||||
|
- [[file:the-chosen-path-option-4-starting-with-option-5.org][The Chosen Path: Option 4, Starting with Option 5]] — The one-memex-two-indices architecture (Option 4) is the correct long-term archi
|
||||||
|
- [[file:ephemeral-first-persistent-later.org][Ephemeral First, Persistent Later]] — The architecture note's Option 5 (ephemeral facts, no disk persistence) is the c
|
||||||
|
- [[file:the-gate-to-fact-bootstrap-extracting-the-first-ontology-from-code.org][The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code]] — The Dispatcher gate stack already encodes an implicit ontology. Every gate vecto
|
||||||
|
- [[file:the-llm-as-proposer-verified-extraction.org][The LLM as Proposer — Verified Extraction]] — The LLM cannot be trusted to populate the symbolic index directly. Its outputs a
|
||||||
|
- [[file:cardinality-policies-singular-dual-and-plural-facts.org][Cardinality Policies — Singular, Dual, and Plural Facts]] — Classical logic requires consistency. A contradiction implies everything (=ex co
|
||||||
|
- [[file:how-categories-grow-the-organic-ontology.org][How Categories Grow — The Organic Ontology]] — Whitehead's /Principia Mathematica/ took over 300 pages to define the logical fo
|
||||||
|
- [[file:ontology-versioning-how-worldviews-change-without-losing-perspective.org][Ontology Versioning — How Worldviews Change Without Losing Perspective]] — Ontology refactoring is not a schema migration. It is a worldview change. When y
|
||||||
|
- [[file:the-awakening-sufficiency-criterion.org][The "Awakening" — Sufficiency Criterion]] — The symbolic index begins its life as a lossy construct. The initial extraction
|
||||||
|
- [[file:merkle-dag-for-version-history.org][Merkle DAG for Version History]] — Every fact is versioned. Every =(:entity :relation)= pair forms its own independ
|
||||||
|
- [[file:abstract-fact-store-interface-modular-by-design.org][Abstract Fact Store Interface — Modular by Design]] — The fact store is accessed through an abstract API. The Merkle DAG (or any futur
|
||||||
|
- [[file:knowledge-graph-type-hierarchy-structural-anti-self-reference-v300.org][Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)]] — The same type-theoretic principle that governs the gate stack can be applied to
|
||||||
@@ -0,0 +1,23 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Abstract Fact Store Interface — Modular by Design
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The fact store is accessed through an abstract API. The Merkle DAG (or any future backing store) is an implementation behind this interface, not a dependency that code throughout the system calls directly.
|
||||||
|
|
||||||
|
#+begin_example
|
||||||
|
fact-assert :: fact → store → (:admitted | :rejected | :flagged)
|
||||||
|
fact-query :: (entity &key relation policy) → active-value-or-values
|
||||||
|
fact-history :: (entity relation) → ordered chain of versioned facts
|
||||||
|
fact-snapshot :: () → root-hash
|
||||||
|
fact-rollback :: root-hash → store
|
||||||
|
#+end_example
|
||||||
|
|
||||||
|
Implementations behind the interface:
|
||||||
|
- Phase 1-4: ephemeral hash table with =:timestamp= and =:parent-id= pointers. No cryptographic hashing. No persistence.
|
||||||
|
- Phase 5: VivaceGraph + Merkle =memory-object= wrapper. Content-addressed, persistent, tamper-proof.
|
||||||
|
|
||||||
|
Future implementations that satisfy the same interface — an append-only write-ahead log, an immutable B-tree, a content-addressed triple store — can replace the backing store without changing any consumer. The archivist, Screamer, ACL2, and the planner call =fact-assert= and =fact-query=, not Merkle struct accessors or VivaceGraph traversal syntax.
|
||||||
|
|
||||||
|
This is not speculative modularity. The two-implementation migration (Phase 1-4 hash table → Phase 5 VivaceGraph + Merkle) is in the roadmap. If the interface leaks implementation details, the migration breaks. The interface must be designed, tested against both backends, and committed before Phase 1 ships.
|
||||||
@@ -0,0 +1,52 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Cardinality Policies — Singular, Dual, and Plural Facts
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Classical logic requires consistency. A contradiction implies everything (=ex contradictione quodlibet=). Screamer, as a constraint solver, also requires consistency — a contradictory constraint set has no solutions. But the symbolic engine operates across domains where the meaning of contradiction is fundamentally different. The correct question is not "is this consistent?" but "what cardinality of truth does this domain support?"
|
||||||
|
|
||||||
|
Time is not a policy. It is a universal dimension that applies equally to every fact, regardless of cardinality. All facts carry =:timestamp= and =:parent-id= fields. Every fact has a version history. Every fact lives in a Merkle chain that captures how it changed. The cardinality policy only governs what happens at a given logical moment when two values coexist for the same =entity= and =relation=.
|
||||||
|
|
||||||
|
*** Policy :singular — One Active Value, One Version Chain
|
||||||
|
|
||||||
|
The active set contains exactly one value for =(:entity :relation)= at a time. When a new value asserts for the same pair, the old value is not rejected. It is superseded — moved into the version history, linked to the new leaf by =:parent-id=, and retained permanently. The active value is the leaf of the Merkle chain.
|
||||||
|
|
||||||
|
"I used to think =rm -rf /= was safe. Now I know it is catastrophic." Both facts exist. Both are true — the first at =2024-06-01=, the second at =2025-03-15=. The chain captures the evolution. The =:singular= policy means there is one truth /now/, not that there was only ever one truth.
|
||||||
|
|
||||||
|
Use for: security classifications, file system state, gate rules, code correctness, deterministic safety constraints — domains that converge on one answer, evolving over time.
|
||||||
|
|
||||||
|
*** Policy :dual — Exactly Two Values, in Explicit Tension
|
||||||
|
|
||||||
|
The active set contains exactly two values for =(:entity :relation)=. Both are simultaneously true. Both carry independent version histories. A third value is rejected — the domain is binary by nature.
|
||||||
|
|
||||||
|
Some contradictions are productive precisely /because/ they are binary. Thesis and antithesis. Love and resentment. Wave and particle. A poem's two incompatible readings. The symbolic index holds both, cross-referenced as complementary rather than conflicting. The user is not asked to resolve the tension. The tension is the fact.
|
||||||
|
|
||||||
|
The system can reason about cardinality transitions: a =:dual= fact that has one interpretation superseded should collapse to =:singular=. A =:dual= that has a third interpretation asserted should prompt the user: "Promote to =:plural= or demote one interpretation?"
|
||||||
|
|
||||||
|
Use for: productive binary tensions, complementary opposites, dialectical pairs, any domain where two answers are both true and their tension is meaningful.
|
||||||
|
|
||||||
|
*** Policy :plural — N Active Values, Open Set
|
||||||
|
|
||||||
|
The active set contains any number of values for =(:entity :relation)=. Each value has independent provenance and its own version history. Queries return all active values with provenance display. Contradictions are flagged as cross-references between values — information, not error.
|
||||||
|
|
||||||
|
A =:plural= fact where all but one value are superseded should collapse to =:singular=. A =:plural= fact where the set reduces to two active values — and the remaining two are complementary — should collapse to =:dual=.
|
||||||
|
|
||||||
|
Use for: literary interpretation, scientific hypotheses, personal beliefs held at different times (when tension is multi-faceted rather than binary), multi-source factual disagreement, open-ended exploration.
|
||||||
|
|
||||||
|
*** Policy Assignment
|
||||||
|
|
||||||
|
The policy is assigned when a category is defined. New categories default to =:plural= (safe — never loses information). Core security categories are explicitly =:singular=. The gate stack's bootstrapped facts are =:singular= because they describe the actual filesystem, which is physically singular. Categories for dialectical or complementary domains are explicitly =:dual=.
|
||||||
|
|
||||||
|
The Screamer admission gate applies the cardinality policy at the active set:
|
||||||
|
- =:singular= + same value, later timestamp → supersede old, chain new as leaf.
|
||||||
|
- =:singular= + different value, same timestamp → reject (contradiction). Human resolves.
|
||||||
|
- =:singular= + different value, later timestamp → supersede old, chain new as leaf. History preserved.
|
||||||
|
- =:dual= + first value → admit. + second value → admit, cross-reference as complementary. + third value → prompt.
|
||||||
|
- =:plural= + any value → admit. Active count transitions trigger collapse checks.
|
||||||
|
|
||||||
|
*** Why This Matters for the Broader Memex
|
||||||
|
|
||||||
|
In the coding domain, contradiction is rare, resolvable, and usually temporal (a rule changed). In the broader memex, contradiction is the product, not the error. Your poetry analysis contradicts your last diary entry. Your reading of /Pale Fire/ changed between 2023 and 2025. Wikidata says Mount Everest is 8848m; DBpedia says 8849m. You love this person AND you resent them.
|
||||||
|
|
||||||
|
The symbolic engine's job is not to decide which is right. It is to surface the tension with provenance — "these three sources disagree; here is the chain for each" for plural facts, or "you hold these two positions in tension" for dual facts, or "you believed X until Tuesday, then Y" for singular facts that evolved. The cardinality policy names the /structure/ of the tension. The Merkle chain provides the /history/ of each position.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Ephemeral First, Persistent Later
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The architecture note's Option 5 (ephemeral facts, no disk persistence) is the correct first implementation. Three reasons:
|
||||||
|
|
||||||
|
1. *The fact language is unproven.* Triples with provenance and grounding is a hypothesis. It may be too simple for some domains, too complex for others. Committing to a serialization format before knowing what's useful is premature.
|
||||||
|
|
||||||
|
2. *The ontology is emergent.* Categories are created on first use. What proves useful stays; what doesn't fades. A persistent format would need a migration story every time the category structure changes. Ephemeral avoids this entirely — the facts are re-derived on each session start using the current (evolved) ontology.
|
||||||
|
|
||||||
|
3. *Rebuildability is the safety net.* Because all facts have a =:grounding= to an Org heading, and gate-outcome facts are regenerated from the gate stack on every load, the entire symbolic index can be thrown away and rebuilt from scratch. The cost is compute, not data. This is the practical realization of "the prose is always the ground truth."
|
||||||
|
|
||||||
|
The transition to persistence (Phase 5: VivaceGraph) happens when two conditions are met: the fact language has stabilized through use, and the accumulated deductions across sessions provide value that justifies the serialization cost.
|
||||||
@@ -0,0 +1,34 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: How Categories Grow — The Organic Ontology
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Whitehead's /Principia Mathematica/ took over 300 pages to define the logical foundations before it could prove that one plus one equals two. Every category introduced carried a burden of justification. Every inference rule had to be demonstrated sound. This is the classical approach to ontology: define everything upfront, exhaustively, formally.
|
||||||
|
|
||||||
|
Passepartout cannot afford this and does not need it. Its domain is bounded (software engineering, personal knowledge, literary engagement, daily life) and its ontology grows from the system's own operation:
|
||||||
|
|
||||||
|
1. *The gate stack seeds the ontology.* Every gate vector is an implicit claim about a category of things. The bootstrap makes these claims explicit. The seed is 50-70 entity classes with no human authoring required — mechanically extracted from existing code.
|
||||||
|
|
||||||
|
2. *New gate vectors add categories directly.* As the Dispatcher grows (new shell patterns, new path protections, new tool classifications), the ontology grows with it. Every new pattern becomes a fact on skill load.
|
||||||
|
|
||||||
|
3. *Screamer generalizes from gate outcomes.* After 37 shell commands are blocked as destructive, Screamer extracts structural commonalities: "commands writing to block devices," "commands recursively deleting outside the workspace." These become new subcategories that didn't exist in the original gate patterns. The ontology deepens through observation.
|
||||||
|
|
||||||
|
4. *The archivist proposes from prose.* The archivist reads a diary entry about a book: "Nabokov's lectures on Kafka." The LLM proposes =(:entity :nabokov :relation :lectures-on :value :kafka)=. Screamer checks consistency. Admitted. The categories =:author=, =:lectures-on=, and =:subject= didn't exist before — they are created on first use. This is the primary growth mechanism for the broader memex.
|
||||||
|
|
||||||
|
5. *The human declares explicitly.* The human writes a declarative fact directly into the symbolic index. No extraction step. No LLM involvement. The fact is admitted with =:provenance :human-authored= — the highest trust level.
|
||||||
|
|
||||||
|
6. *Temporal patterns crystallize into categories.* Every Sunday the memex gets a retrospective heading. Every Monday a planning heading. The time-awareness system observes the periodicity and proposes =:weekly-retrospective= and =:weekly-planning= as fact types. Screamer verifies.
|
||||||
|
|
||||||
|
7. *Cross-domain overlap produces parent categories.* Screamer notices that =:secret-files= (from the gate stack) and =:private-content= (from privacy tags) share members — =.env= is both a secret file and private content. It proposes =:sensitive-material= as a parent with both as children. Taxonomy building happens automatically through overlap detection.
|
||||||
|
|
||||||
|
*** Growth is self-limiting by design
|
||||||
|
|
||||||
|
Not every conceivable category is added. The system prunes through use:
|
||||||
|
|
||||||
|
- New categories are admitted only through Screamer's consistency check. A category that contradicts an existing classification is rejected.
|
||||||
|
- A category that never gets queried costs nothing (a hash table entry) but produces no value. It fades from use naturally.
|
||||||
|
- Overly fine-grained categories are rejected because they are redundant with the wildcard pattern that already covers them.
|
||||||
|
- Overly broad categories that subsume meaningful distinctions produce contradictions when Screamer tries to apply existing rules. Rejected.
|
||||||
|
|
||||||
|
The system converges on a useful granularity through use, not through upfront design. The gate stack provides the seed. Gate outcomes, prose extraction, deduction, and human authoring grow the shoots. Screamer prunes contradictions. The ontology is a garden, not a building.
|
||||||
@@ -0,0 +1,11 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Knowledge Graph Type Hierarchy — Structural Anti-Self-Reference (v3.0.0)
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The same type-theoretic principle that governs the gate stack can be applied to the knowledge graph itself. When VivaceGraph ships (v3.0.0), every entity carries a ~:pm-type-level~ metadata field. Queries cannot return entities of the same level as the querying function. Self-referential knowledge becomes structurally impossible — no "this entity defines its own type level."
|
||||||
|
|
||||||
|
The KG query layer enforces this at the Prolog level, not through runtime checks. This is the same idea as the type-level gates (see Safety section above), but applied to /knowledge/ rather than /actions/. The dispatcher prevents self-referential actions; the KG prevents self-referential facts.
|
||||||
|
|
||||||
|
For the full philosophical treatment, see the Whitehead analysis in the Validation section below.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Merkle DAG for Version History
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Every fact is versioned. Every =(:entity :relation)= pair forms its own independent chain in a Merkle DAG. This is not new infrastructure — it is a new occupant of Passepartout's existing Merkle-tree memory system (v0.2.0).
|
||||||
|
|
||||||
|
When a fact supersedes its predecessor, the new fact hashes over: =SHA-256(value || provenance || timestamp || parent-hash || grounding)=. The parent-hash pointer forms the chain. Tampering with any version changes its hash, breaking all downstream references. The history is tamper-proof by construction.
|
||||||
|
|
||||||
|
Facts about =(.env :member-of-class)= form one chain. Facts about =(:nabokov :wrote)= form another. They evolve independently. They share no ancestry. This is a DAG, not a single list — inserting a fact is O(1) per chain. Changing a fact about =.env= does not require rehashing the literary index.
|
||||||
|
|
||||||
|
=:dual= and =:plural= facts cross-reference each other via edges (=:complements=, =:contradicts=) but these are semantic relationships, not parent chains. Each value has its own ancestor chain. The cross-reference edges form a web; the parent chains form a spine.
|
||||||
|
|
||||||
|
Passepartout already snapshots the Merkle root over all memory objects. Adding the fact store to the snapshot is a registration, not a new mechanism. Rolling back the snapshot restores the entire fact state — all chains, all cross-references, all cardinalities — to that point in time.
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Ontology Versioning — How Worldviews Change Without Losing Perspective
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Ontology refactoring is not a schema migration. It is a worldview change. When you split =:secret-file= into =:crypto-secret= and =:plaintext-secret=, you are not renaming columns. You are reclassifying what a file *is* — and every Screamer deduction that crossed the old category boundary now means something different under the new distinction.
|
||||||
|
|
||||||
|
The system preserves all worldviews. It does not overwrite the past with the present.
|
||||||
|
|
||||||
|
The category hierarchy is itself a Merkle tree. Every entity class definition carries a hash of its superclasses, its cardinality policy, its associated relations, and its description. The aggregate hash of all active class definitions is the =:ontology-version= — a Merkle root of the current worldview.
|
||||||
|
|
||||||
|
Every fact — every triple, every deduction, every gate outcome — stores its =:ontology-version= at the time of assertion. This is a single field, 64 hex characters. The cost is negligible. The implication is profound.
|
||||||
|
|
||||||
|
When categories change, the system does not run a batch UPDATE. It re-verifies:
|
||||||
|
|
||||||
|
1. A new category hierarchy produces a new =:ontology-version= hash.
|
||||||
|
2. Facts carrying the old hash are flagged for re-verification.
|
||||||
|
3. On heartbeat or manual trigger, Screamer re-evaluates each flagged fact against the /new/ category definitions. The old justification chain is preserved alongside the new outcome.
|
||||||
|
4. Status: =:survived= (still valid), =:incoherent= (premises don't translate, flagged for human review), =:reclassified= (valid but under different classification).
|
||||||
|
|
||||||
|
The =fact-query= function accepts an optional =:ontology-version= parameter. Queries default to the current worldview (=:active=). Specifying a version returns facts as they were under that worldview. The system can answer questions that no other knowledge tool can: "What did I believe about secrets before I refined my security model?" "How has my reading of /Pale Fire/ evolved across three frameworks?" "Which deductions survived my last ontology refactoring?"
|
||||||
|
|
||||||
|
This is not querying a fact. It is querying the history of your own thinking — the fact that you changed your mind, the date you did, the reasoning that held and the reasoning that didn't.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Awakening — Sufficiency Criterion
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The symbolic index begins its life as a lossy construct. The initial extraction from prose — LLM proposals verified by Screamer — is built from an uncertain foundation. Some facts are correct. Some are missing. Some are wrong.
|
||||||
|
|
||||||
|
But the symbolic engine accumulates non-lossy facts through three independent mechanisms:
|
||||||
|
|
||||||
|
1. *Gate outcomes* — every gate rejection is a fact. No LLM involved. Accumulate at the rate of user interactions.
|
||||||
|
2. *Screamer deductions* — new facts derived from existing facts. No LLM involved. Accumulate whenever the fact store crosses a density threshold.
|
||||||
|
3. *Human authoring* — the human explicitly declares facts. No LLM involved.
|
||||||
|
|
||||||
|
At some point, the non-lossy facts constitute a sufficient foundation that the symbolic engine can reverse the flow: instead of the LLM extracting facts from prose, the symbolic engine reads prose through its own lens — its now-substantial ontology of categories, rules, and constraints — and asserts facts in its own language. The extraction mechanism ceases to be probabilistic and becomes deterministic.
|
||||||
|
|
||||||
|
The sufficiency criterion makes this operational: =(/ (count-provenance :gate-outcome :human-authored :deduced) total-facts)=. When this ratio exceeds a configurable threshold (=SUFFICIENCY_THRESHOLD=, default 0.7), the system considers its foundation sufficient. The archivist switches from "LLM proposes, Screamer verifies" to "Screamer queries existing facts, applies to the new prose, and deduces new facts directly."
|
||||||
|
|
||||||
|
The flip is visible to the user: "Symbolic index: 847 facts (73% non-lossy, 12% LLM-proposed, 15% Wikidata). Sufficient foundation: YES."
|
||||||
|
|
||||||
|
The flip does not mean "complete." In the broader memex, completeness is neither possible nor desirable. The awakening means "deterministic enough to be trustworthy," not "comprehensive enough to be self-sufficient." The neural index remains the gateway to the full richness of prose. The symbolic index handles what can be mechanically verified. The boundary is permanent.
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Chosen Path: Option 4, Starting with Option 5
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The one-memex-two-indices architecture (Option 4) is the correct long-term architecture. The prose is the ground truth. The symbolic index is a derived view that can be rebuilt. The neural index handles what the symbolic index cannot — semantic search, fuzzy matching, associative leaps.
|
||||||
|
|
||||||
|
But committing to a persistence format before knowing what facts are useful is premature. The practical path starts with Option 5 (ephemeral facts) as the Phase 1-4 implementation, then graduates to Option 4 with VivaceGraph persistence in Phase 5 when the fact language has been battle-tested through months of gate outcomes, Screamer deductions, and LLM proposals.
|
||||||
|
|
||||||
|
*** Why the dual index is permanent, not transitional
|
||||||
|
|
||||||
|
In the coding domain, there is an aspiration that the symbolic index could eventually capture enough of the prose's propositional content to become a complete representation — the "flip" where the symbolic engine reverses the flow. But for the broader memex (literature, poetry, personal reflection, daily logs), completeness is neither possible nor desirable. You cannot formalize what makes a poem beautiful. You cannot extract a triple that captures the emotional weight of a diary entry. The neural index will always be the gateway to the full richness of the prose. The symbolic index handles what can be mechanically verified: citations, entities, temporal order, contradictions, provenance. The division of labor between the two indices is permanent because the domains they serve are fundamentally different kinds of knowledge.
|
||||||
@@ -0,0 +1,40 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Five Architecture Options
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The symbolic engine must relate to the human memex. The relationship is not obvious because knowledge lives in two incompatible forms: natural language prose (what the human reads and writes) and formal facts (what the symbolic engine reasons about). The translation between them is lossy by nature. The architecture is defined by how it handles that lossiness.
|
||||||
|
|
||||||
|
*** Option 1: The Auto-Formalizer
|
||||||
|
|
||||||
|
A separate knowledge graph stores symbolic facts. The LLM populates it by extracting triples from unstructured data. The KG becomes co-authoritative with the human prose.
|
||||||
|
|
||||||
|
This is the simplest to implement but inherits the dual-representation problem in its most acute form. The KG and the prose can disagree, and the architecture provides no mechanism for resolving disagreements. It also stores knowledge twice — once in the user's Org files, once in the KG — with no guarantee that they stay synchronized.
|
||||||
|
|
||||||
|
*** Option 2: Two Intentionally Separate Memexes
|
||||||
|
|
||||||
|
The human memex contains prose: thoughts, diaries, decisions, documentation. The symbolic memex contains formal facts: constraints, rules, relationships, deductions. The archivist bridges between them but does not try to keep them synchronized. They are allowed to diverge because they serve different purposes.
|
||||||
|
|
||||||
|
This is philosophically honest — it admits that no lossless translation between natural language and formal logic is possible. But it forces the user to reason about two separate knowledge stores.
|
||||||
|
|
||||||
|
*** Option 3: Tangled Fact Blocks in Org Files
|
||||||
|
|
||||||
|
A new block type — =#+begin_src knowledge= — would contain symbolic facts in a formal language. The tangle mechanism would load these facts into the symbolic engine's in-memory store, just as it loads Lisp code into the SBCL image.
|
||||||
|
|
||||||
|
This is aesthetically appealing because it unifies the format. One toolchain, one version control system, one Merkle tree. But the block language itself IS the knowledge representation language, and that language is the ontology we have not yet defined.
|
||||||
|
|
||||||
|
*** Option 4: One Memex, Two Indices
|
||||||
|
|
||||||
|
The prose remains in human language in Org files. The prose is always the ground truth. Two indices sit on top of the prose as derived views:
|
||||||
|
|
||||||
|
- The *neural index* uses vector embeddings to enable semantic search. The LLM navigates the prose through embedding space, retrieving relevant headings.
|
||||||
|
- The *symbolic index* stores formal assertions about what the prose says — predicates, relations, constraints — each grounded to a specific heading or block in the Org file.
|
||||||
|
|
||||||
|
Each index serves its own side of the machine. They do not need to understand each other's representations. They only need to agree on which heading or block they are referring to. Because the prose is always the ground truth, the symbolic index can be thrown away and rebuilt from scratch if it becomes corrupted or stale. No information is lost — only the extracted assertions.
|
||||||
|
|
||||||
|
*** Option 5: Ephemeral Symbolic Facts
|
||||||
|
|
||||||
|
No persistence, no serialization format, no knowledge graph stored on disk. VivaceGraph exists in memory during the session. Screamer derives facts from the prose as needed. When the session ends, the facts are discarded and re-derived on the next start.
|
||||||
|
|
||||||
|
This punts the ontological design problem entirely. You never have to decide on a serialization format because you never serialize. The cost is compute (re-derivation on every restart) and the inability to accumulate facts across sessions. But it is the correct first step — a way to learn what kinds of facts are actually useful before committing to a storage format.
|
||||||
@@ -0,0 +1,36 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Gate-to-Fact Bootstrap — Extracting the First Ontology from Code
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The Dispatcher gate stack already encodes an implicit ontology. Every gate vector asserts the existence of a category of things:
|
||||||
|
|
||||||
|
- Gate vector 2 asserts there exists a class of files called /secrets/.
|
||||||
|
- Gate vector 7 asserts there exists a class of commands called /destructive/.
|
||||||
|
- Gate vector 8 asserts there exists a class of domains called /trusted/.
|
||||||
|
- The self-build boundary asserts there exists a class of files called /core-harness/ and a class called /skills/.
|
||||||
|
|
||||||
|
These claims are currently expressed as code — Lisp functions that pattern-match against file paths, shell commands, and URLs. They are not facts the symbolic engine can query, derive from, or check for consistency. But they can be made explicit.
|
||||||
|
|
||||||
|
The bootstrap makes every gate a set of initial symbolic facts:
|
||||||
|
=(:file ".env" :member-of-class :secret-files :source gate-vector-2)=,
|
||||||
|
=(:command "rm -rf /" :classified-as :catastrophic :source gate-vector-7)=,
|
||||||
|
=(:domain "api.telegram.org" :classified-as :trusted :source gate-vector-8)=.
|
||||||
|
|
||||||
|
This produces 50-70 entity classes directly from the existing gate stack, without any new infrastructure:
|
||||||
|
|
||||||
|
| Source | Count | Example categories |
|
||||||
|
|----------------------------------------+-------+----------------------------------------------------|
|
||||||
|
| ~*dispatcher-protected-paths*~ | 11 | :secret-config-file, :ssh-key-file, :gpg-key-file |
|
||||||
|
| ~*dispatcher-shell-blocked*~ | 8 | :catastrophic-command, :injection-pattern |
|
||||||
|
| ~*dispatcher-network-whitelist*~ | 2 | :trusted-domain, :untrusted-domain |
|
||||||
|
| Self-build boundary | 2 | :core-harness-file, :skill-file |
|
||||||
|
| Privacy tags | 3 | :private-content, :financial-content |
|
||||||
|
| Permission table | 3 | :read-only-tool, :write-tool, :eval-tool |
|
||||||
|
| Cognitive tools | 6 | :code-search-tool, :file-io-tool, :shell-tool |
|
||||||
|
| Relations (all gates) | ~15 | :member-of-class, :classified-as, :depends-on |
|
||||||
|
| Qualities | ~8 | :catastrophic, :dangerous, :moderate, :harmless |
|
||||||
|
| Provenance sources | 4 | :gate-outcome, :human-authored, :deduced, :llm-proposed |
|
||||||
|
|
||||||
|
This is the seed. It gives Screamer a domain to reason about immediately, without any LLM involvement. It proves the pattern — code becomes facts, facts enable reasoning — at the cost of approximately 30 lines of Lisp.
|
||||||
@@ -0,0 +1,18 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The LLM as Proposer — Verified Extraction
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The LLM cannot be trusted to populate the symbolic index directly. Its outputs are sampled, not proven. A probabilistic extraction feeding a deterministic engine defeats the purpose of being deterministic.
|
||||||
|
|
||||||
|
But the LLM is still useful. It can surface facts that are obvious to a human reader of prose but would take the symbolic engine many deduction steps to reach independently. The solution is to demote the LLM from /extractor/ to /proposer/:
|
||||||
|
|
||||||
|
1. The archivist reads a prose heading.
|
||||||
|
2. The LLM proposes candidate triples.
|
||||||
|
3. Screamer checks each triple for consistency against the existing fact store.
|
||||||
|
4. Only consistent triples are admitted to the symbolic index, flagged with =:provenance :llm-proposed= and grounded to the source heading.
|
||||||
|
|
||||||
|
The LLM might hallucinate facts that don't correspond to the prose. It might extract facts that contradict existing knowledge. It might produce syntactically malformed triples. None of these failures contaminate the symbolic index because proposals are not admitted automatically. The admission gate (Screamer) is deterministic.
|
||||||
|
|
||||||
|
This is the core architecture pattern. Everything else — the entity classes, the deduction engine, the persistence layer — follows from this single design decision: *the LLM proposes; the symbolic engine decides whether to accept.*
|
||||||
@@ -0,0 +1,11 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: 4fa7eb38-6bc0-4809-9d8a-77290760ea79
|
||||||
|
:END:
|
||||||
|
#+title: The Two Brains
|
||||||
|
* The Two Brains
|
||||||
|
|
||||||
|
- [[file:the-probabilistic-deterministic-split.org][The Probabilistic-Deterministic Split]] — The architecture divides cognition into two fundamentally different reasoning sy
|
||||||
|
- [[file:core-knowledge-the-four-pillars-of-agentic-reliability.org][Core Knowledge: The Four Pillars of Agentic Reliability]] — Every reliable AI agent must possess four types of Core Knowledge — not as promp
|
||||||
|
- [[file:the-dispatcher-as-learning-system.org][The Dispatcher as Learning System]] — The Dispatcher begins as a static guard — a set of rules that block obviously da
|
||||||
@@ -0,0 +1,17 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Core Knowledge: The Four Pillars of Agentic Reliability
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Every reliable AI agent must possess four types of Core Knowledge — not as prompt instructions, but as encoded symbolic rules that the neural engine cannot override. These are the "laws of physics" for the agent's computational universe. Passepartout encodes each pillar as deterministic Lisp functions in the Dispatcher gate stack.
|
||||||
|
|
||||||
|
1. *Digital Object Permanence & State.* The agent must know what exists independently of its attention. Passepartout achieves this through the Merkle-tree memory: every memory-object carries a SHA-256 content hash. If the agent deletes a file, the hash proves it's gone. If an external process modifies it, the hash mismatch triggers a warning. The copy-on-write snapshot mechanism preserves the state at every decision point, enabling rollback if an action chain fails.
|
||||||
|
|
||||||
|
2. *Causality and Temporal Logic.* Actions must execute in order. Step B cannot run if Step A failed. Passepartout enforces this through the pipeline's depth counter (signals cannot recurse past depth 10, preventing infinite loops) and the sequential Perceive → Reason → Act ordering. The batch tool calls feature allows parallel execution of independent actions while enforcing sequential execution of dependent ones — actions that share a dependency are ordered; actions that don't are parallelized.
|
||||||
|
|
||||||
|
3. *Agentic Boundaries (The "Self").* The agent must know where its authority ends and the host system begins. Passepartout encodes this through the Dispatcher gate stack: path protection blocks access to sensitive directories (~/.ssh, /etc, ~/.aws). Shell safety blocks destructive commands (rm -rf /, dd, injection vectors). Network exfiltration detection blocks unauthorized outbound connections. The permission table allows per-tool, per-path granularity. These are not prompt instructions — they are Lisp functions that execute unconditionally for every action. The self-build safety boundary extends this to the agent's own core pipeline files: the agent can modify skills and system modules freely, but cannot modify its own brain stem without human review.
|
||||||
|
|
||||||
|
4. *Epistemic Certainty (Knowing How It Knows).* The agent must distinguish between a verified fact, a retrieved memory, and an LLM prediction. Passepartout encodes this through the gate trace: every action carries a record of which gates passed, which blocked, and why. The provenance system (LOGBOOK entries on memory-objects) records who modified what and when. The Dispatcher's existence-check gate verifies that a file exists before allowing a read. The process-status gate verifies that a command completed before allowing its output to be used. The agent cannot "hallucinate" a file path or a process result because the Dispatcher checks each against the live state before execution.
|
||||||
|
|
||||||
|
These four pillars are not features. They are the definition of a reliable agent. Every agent architecture either provides them or compensates for their absence in ways that make the agent less trustworthy, more expensive, or both.
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Dispatcher as Learning System
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The Dispatcher begins as a static guard — a set of rules that block obviously dangerous actions. But defining "obviously" is the hard problem. The agent encounters situations the rules do not anticipate. The Dispatcher must grow.
|
||||||
|
|
||||||
|
The human-in-the-loop exception is the seed. When the LLM proposes an action the Dispatcher does not recognize, the system does not default to blocking or allowing. It suspends. It writes the proposed action to an Org buffer in a format the human can read and understand. The human reviews and approves or denies. The Dispatcher observes the decision.
|
||||||
|
|
||||||
|
From this single observation, the Dispatcher extracts a rule. Not merely "allow this specific action" but "allow this class of actions parameterized by these dimensions." The human approved a write to ~/projects/myapp/src/core.clj. The Dispatcher generalizes: writes to ~/projects/*/src/*.lisp are approved for this session, or for this project, or indefinitely depending on the context and the user's pattern of decisions.
|
||||||
|
|
||||||
|
Shadow mode is where rules are tested before deployment. When the Dispatcher encounters a novel situation and is uncertain, it can run the proposed action in a simulated environment. It observes the side effects — what files would be modified, what processes would be spawned, what network calls would be made. If the simulation produces dangerous side effects, the rule is discarded. If it appears safe, the rule is added to the active set with a confidence rating.
|
||||||
|
|
||||||
|
Formal verification is where the learned rules are checked against invariants. The Dispatcher's rules are not merely patterns observed from human behavior. They are formulas in a logic that the system can reason about. A rule that would enable path traversal is not discarded because it was observed to be safe in prior instances — it is discarded because it violates the path-confinement invariant by construction.
|
||||||
|
|
||||||
|
The Dispatcher becomes, over time, not a guard that blocks bad actions but a reasoning system that understands why actions are good or bad. Early versions learn from human decisions. Later versions learn from their own logical analysis. The human's role transitions from approver to auditor to, eventually, unnecessary oversight.
|
||||||
|
|
||||||
|
This is the bootstrap. The system begins dependent on human judgment because it has no basis for judgment of its own. Through accumulated decisions, it constructs a model of what is permitted and why. That model is the foundation for the deterministic symbolic engine that in v1.0.0 takes over the reasoning that the Dispatcher learned to perform.
|
||||||
@@ -0,0 +1,39 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: The Probabilistic-Deterministic Split
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
The architecture divides cognition into two fundamentally different reasoning systems. This is not arbitrary engineering but a structural response to a fundamental truth: probabilistic systems will hallucinate, and you cannot build reliable autonomy on an unreliable foundation.
|
||||||
|
|
||||||
|
*** The Hallucination Problem
|
||||||
|
|
||||||
|
An LLM is a statistical engine trained on token sequences. It generates the most probable continuation of a prompt. Given sufficient context, that continuation is correct. Given novel context, it is often wrong in confident-sounding ways.
|
||||||
|
|
||||||
|
This is not a training deficiency. Hallucination is a fundamental property of probabilistic inference. You can reduce it with better models, longer contexts, and clever prompting, but you cannot eliminate it by making the LLM better. You eliminate it by not asking the LLM to do things that require certainty.
|
||||||
|
|
||||||
|
This is the architectural bet at the heart of Passepartout's neurosymbolic design. The LLM should not be the reasoning engine. It should be the *creative* engine — proposing possibilities, surfacing connections, translating between natural language and formal representation. The *reasoning* engine should be symbolic: deterministic, verification-grounded, provenance-tracked, and incapable of hallucination by construction.
|
||||||
|
|
||||||
|
*** The Division of Labor
|
||||||
|
|
||||||
|
An LLM is a statistical engine. It generates outputs based on patterns in training data. It is remarkable at translation, generation, pattern matching, and fuzzy reasoning. It can take messy human intent and produce structured queries. It can take structured results and produce natural language. It is, in the terminology of the system, the creative brain.
|
||||||
|
|
||||||
|
But it cannot be trusted. Not because it is poorly designed or insufficiently trained, but because hallucination is a fundamental property of probabilistic inference. The model generates the most likely continuation, not the correct one. Given sufficient context, the most likely continuation is correct. Given novel context, it is often wrong in confident-sounding ways.
|
||||||
|
|
||||||
|
The deterministic engine addresses this by being what the probabilistic engine is not: mathematically rigorous, formally verifiable, and incapable of hallucination by design. It operates on explicit symbolic representations — lists, property lists, knowledge graphs — not on floating-point activations. When it evaluates a path confinement check, it returns true or false, not a probability distribution.
|
||||||
|
|
||||||
|
The division of labor is architectural. The LLM handles the fuzzy interface between human language and structured representation. It translates what the user wants into what the system can reason about. The deterministic engine receives those structured representations and evaluates them against formal invariants. It decides whether to execute, not whether the translation was semantically plausible.
|
||||||
|
|
||||||
|
This separation is the source of Passepartout's safety guarantee. Other agents add "guardrails" as an afterthought — a layer of filtering around a dangerous core. Passepartout makes the division explicit: the LLM never touches the file system, never executes a command, never modifies memory. It generates proposals. The deterministic engine evaluates and executes. The dangerous operations are never in the probabilistic path.
|
||||||
|
|
||||||
|
The split also explains why the system gets safer over time without the LLM improving. The deterministic engine accumulates rules. The LLM proposes actions, the engine evaluates them against a growing rule set. Early versions block obvious dangers. Later versions block sophisticated attacks that were previously unknown. The safety grows logarithmically with the number of interactions, not linearly with model capability.
|
||||||
|
|
||||||
|
*** The 10-80-10 Architecture
|
||||||
|
|
||||||
|
The target for a coding agent: 10% neural for input translation (natural language → structured queries), 80% symbolic for reasoning (Screamer plans, ACL2 verifies, VivaceGraph retrieves facts), 10% neural for output formatting (structured results → natural language). The 80% that happens in the symbolic middle layer costs zero LLM tokens.
|
||||||
|
|
||||||
|
For the broader memex — literature, poetry, personal reflection, daily logs — the ratios are different and less important than the metaphor itself. The neuro is the *brain* — generative, associative, creative, comfortable with ambiguity. It produces insights that are provisional, connections that are speculative, hypotheses that may be wrong. The symbolic engine is the *education* — accumulated, verified, provenance-tracked knowledge that the brain draws on and is disciplined by. It doesn't think creatively. It remembers, checks, and constrains. It prevents the brain from being confidently wrong.
|
||||||
|
|
||||||
|
This framing resolves a tension in the original architecture. The 10-80-10 implies the symbolic engine /replaces/ the neuro for reasoning. But a symbolic engine is terrible at creativity, ambiguity, and associative leaps across unrelated domains — exactly what you need for a memex that contains /Pale Fire/, a shopping list, and a project plan. The brain proposes that your sudden interest in unreliable narrators coincides with a week where your project retrospective used the word "deception." The education verifies: "those two diary entries are 4 days apart; the word 'deception' appears in both; here are the headings." The brain makes the leap. The education makes it trustworthy.
|
||||||
|
|
||||||
|
This means the symbolic engine never needs to be "complete." Education isn't complete knowledge — it's structured knowledge. You don't need a fact for every sentence in your diary. You need facts for what can be mechanically verified: dates, citations, entities, contradictions, temporal order. The brain handles the rest.
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
|
||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: e66a5d5f-70ff-4953-93c3-569e05eaff73
|
||||||
|
:END:
|
||||||
|
#+title: Validation
|
||||||
|
* Validation
|
||||||
|
|
||||||
|
- [[file:whiteheads-process-philosophy-and-type-theory.org][Whitehead's Process Philosophy and Type Theory]] — Alfred North Whitehead's two major bodies of work — /Principia Mathematica/ (191
|
||||||
|
- [[file:historical-lineage-mccarthys-advice-taker.org][Historical Lineage — McCarthy's Advice Taker]] — McCarthy's "Programs with Common Sense" (1959) is the direct intellectual ancest
|
||||||
|
- [[file:marcus-2020-the-case-against-pure-deep-learning.org][Marcus (2020): The Case Against Pure Deep Learning]] — Gary Marcus's "The Next Decade in AI" argues that deep learning alone is "data h
|
||||||
|
- [[file:gaur--sheth-2023-crest-trustworthy-neurosymbolic-ai.org][Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI]] — Gaur and Sheth present the CREST framework: Consistency, Reliability, user-level
|
||||||
|
- [[file:sheth-et-al-2022-knowledge-infused-learning.org][Sheth et al. (2022): Knowledge-Infused Learning]] — Sheth, Gunaratna, Bhatt, and Gaur define Knowledge-infused Learning (KiL) as "co
|
||||||
|
- [[file:the-competitive-argument.org][The Competitive Argument]] — No competitor has this problem because no competitor has a symbolic engine. The
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-05-11 Mon]
|
||||||
|
:ID: ec267c73-4e0d-4efb-9497-cb72f74538e4
|
||||||
|
:END:
|
||||||
|
#+title: Gaur & Sheth (2023): CREST — Trustworthy Neurosymbolic AI
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
Gaur and Sheth present the CREST framework: Consistency, Reliability, user-level Explainability, and Safety build Trust — and they argue these require neurosymbolic methods. Their empirical finding: GPT-3.5 breached safety constraints 30% of the time when asked identical questions repeatedly. Claude's 16 safety rules and Sparrow's 23 rules provide no /inherent/ safety — they are heuristic guardrails that can be breached through prompt variation.
|
||||||
|
|
||||||
|
These findings validate three Passepartout design commitments: (1) prompt-level safety is insufficient — deterministic gates run in pure Lisp, cost 0 tokens, and cannot be evaded by prompt engineering; (2) inconsistency is the norm — the cardinality model expects contradiction and surfaces it with provenance; (3) knowledge infusion is required for trust — Passepartout's symbolic index IS the knowledge infusion layer, facts extracted from prose, verified by Screamer, and available for any LLM call.
|
||||||
|
|
||||||
|
Reference: Gaur, M., & Sheth, A. (2023). Building Trustworthy NeuroSymbolic AI Systems: Consistency, Reliability, Explainability, and Safety. arXiv:2312.06798.
|
||||||
@@ -0,0 +1,20 @@
|
|||||||
|
:PROPERTIES:
|
||||||
|
:CREATED: [2026-06-04 Thu]
|
||||||
|
:END:
|
||||||
|
#+title: Historical Lineage — McCarthy's Advice Taker
|
||||||
|
#+filetags: :passepartout:architecture:
|
||||||
|
|
||||||
|
McCarthy's "Programs with Common Sense" (1959) is the direct intellectual ancestor of the Passepartout architecture. The paper proposed an "advice taker" — a program that "will draw immediate conclusions from a list of premises" expressed in "a suitable formal language (most likely a part of the predicate calculus)." The program would:
|
||||||
|
|
||||||
|
1. Accept declarative statements about the world as input.
|
||||||
|
2. Store them as logical formulas.
|
||||||
|
3. Reason from them to produce new conclusions.
|
||||||
|
4. Accept new facts and revise its conclusions.
|
||||||
|
|
||||||
|
This is precisely the Passepartout pipeline: the archivist extracts declarative facts from prose → Screamer checks them for consistency → VivaceGraph stores them → the planner reasons from them → new facts from gate outcomes and deductions revise the store. McCarthy proposed it in 1959. Passepartout is building it in 2026.
|
||||||
|
|
||||||
|
The gap between McCarthy's proposal and Passepartout's implementation is the /hallucination problem/. McCarthy assumed facts would be entered by a human programmer in formal logic. Passepartout's facts are extracted from natural language prose by an LLM — a probabilistic process that requires deterministic verification. Screamer is the component McCarthy didn't need: a constraint solver that gates LLM-proposed facts against the existing fact store.
|
||||||
|
|
||||||
|
The connection is not metaphorical. McCarthy cited /Principia Mathematica/ as an influence on Lisp. Passepartout's Whitehead analysis traces the same PM → Lisp lineage. The advice taker → Passepartout lineage completes the arc: PM's formal logic → Lisp → McCarthy's advice taker → Passepartout's neurosymbolic engine.
|
||||||
|
|
||||||
|
Reference: McCarthy, J. (1959). Programs with Common Sense. /Proceedings of the Teddington Conference on the Mechanization of Thought Processes./
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user