gbrain: sync converted org-mode brain files
This commit is contained in:
Hermes
@@ -176,8 +176,8 @@ Organized communities are the entry point because they force the Agora to be the
|
||||
* References
|
||||
|
||||
- [[file:agora.org][Agora overview]]
|
||||
- [[file:../agora/docs/agora-requirements-01-overview.org][Agora Protocol Overview — Platform Replacement Strategy]]
|
||||
- [[file:../agora/docs/agora-requirements-05-social.org][Social Space — Collective Personas and Governance]]
|
||||
- [[file:../agora/docs/agora-requirements-06-exchange-and-contracts.org][Exchange and Contracts — SCAL, Escrow, Arbitration]]
|
||||
- Agora Protocol Overview — Platform Replacement Strategy
|
||||
- Social Space — Collective Personas and Governance
|
||||
- Exchange and Contracts — SCAL, Escrow, Arbitration
|
||||
- [[file:alternative-growth-social-first.org][Social-first growth scenario]]
|
||||
- [[file:competitive-landscape-agora.org][Full competitive landscape]]
|
||||
|
||||
@@ -5,11 +5,11 @@
|
||||
#+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, Stoa, Agora) are the same; the order of operations and the primary growth levers differ fundamentally.
|
||||
The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. The triad components (Logos, [[file:stoa.org][Stoa]], [[file:agora.org][Agora]]) are the same; the order of operations and the primary growth levers differ fundamentally.
|
||||
|
||||
* Why This Path Exists
|
||||
|
||||
The institution-first scenario (growth-strategy.org) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But the triad ships with a second product that has nothing to do with verification: the Agora, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The Agora replaces all four with one provable layer.
|
||||
The institution-first scenario ([[file:growth-strategy.org][growth strategy]]) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But the triad ships with a second product that has nothing to do with verification: the Agora, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The Agora replaces all four with one provable layer.
|
||||
|
||||
The social-first scenario leans into what the Agora is /as a product/, not what the triad is /as a technology/. Publishing, payments, contracts, and identity are all mass-market primitives. They can grow without ever mentioning ACL2, gate rules, or compliance. Verification is the infrastructure underneath, invisible to users until they need it.
|
||||
|
||||
@@ -31,7 +31,7 @@ Growth lever: Multi-vector network effects. The Agora grows not on a single curv
|
||||
1. Publishing: each new creator attracts readers, who may become creators
|
||||
2. Payments: each new payment user creates liquidity that makes the network more useful for everyone
|
||||
3. Contracts: each new contract written on the Agora creates a template and a precedent
|
||||
4. PDS: each new PDS increases the federation surface and the compute marketplace supply
|
||||
4. PDS: each new PDS increases the federation surface and the [[file:compute-marketplace.org][compute marketplace]] supply
|
||||
|
||||
Any of these can be the primary growth vector in a given market. If publishing stalls in one region, payments might take off. This redundancy dramatically increases the probability that /some/ vector finds PMF.
|
||||
|
||||
@@ -45,7 +45,7 @@ Tactics:
|
||||
|
||||
4. /PDS hosting as infrastructure./ The PDS is the backbone, not the headline. Freemium model: first 1GB free, $5-15/mo for unlimited. The PDS stores your identity, content, contracts, and payment history in one place. The value prop: /one account, one data store, one reputation, everywhere/.
|
||||
|
||||
5. /Fee-based revenue./ The Agora takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data licensing, compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow.
|
||||
5. /Fee-based revenue./ The Agora takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data [[file:licensing.org][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 1 target | Mature |
|
||||
@@ -134,7 +134,7 @@ Customer: At this scale, the Agora is the default identity and communication lay
|
||||
|
||||
Growth lever: Default status. The network is the path of least resistance. A new social platform would need to replicate not just the user base but the entire attestation history, compute marketplace, and institutional infrastructure. The moat is not legal (regulation) but practical (installed base + cumulative value).
|
||||
|
||||
Tactics: Similar end state to the institution-first scenario — verification monopoly, certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat:
|
||||
Tactics: Similar end state to the institution-first scenario — [[file:verification-monopoly.org][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat:
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -11,9 +11,9 @@ Research on corporate structures for a US-incorporated tech company with offshor
|
||||
|
||||
The triad has three distinct asset classes, each with different protection needs:
|
||||
|
||||
1. /IP (Logos):/ Passepartout codebase, gate rules, ACL2 proof libraries, the verification monopoly. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable.
|
||||
1. /IP (Logos):/ Passepartout codebase, gate rules, ACL2 proof libraries, the [[file:verification-monopoly.org][verification monopoly]]. This is the core defensible IP. Needs to be owned separately from the operating company so that if the operating company is sued, the IP is not reachable.
|
||||
|
||||
2. /Platform (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 ([[file:agora.org][Agora]]):/ The network itself — user base, reputation graph, contract history, protocol specification. This is harder to value and harder to protect because its value is partly in the user base. But the code, protocol spec, and network infrastructure can be owned separately.
|
||||
|
||||
3. /Revenue streams:/ Enterprise compliance contracts, transaction fees, PDS hosting subscriptions. These flow through the operating company. A judgment against the operating company attaches to the revenue in that entity.
|
||||
|
||||
@@ -35,7 +35,7 @@ Assessment: Fine for Phase 0. Upgrade when revenue exceeds liability risk tolera
|
||||
- Delaware C-Corp is the operating company (sells verification, runs the Agora PDS infrastructure)
|
||||
- A separate IP holding company in BVI, Cayman, or Nevis owns the Passepartout code, gate rules, ACL2 libraries, and the Agora protocol spec
|
||||
- The operating company licenses the IP from the holding company at arm's-length royalty rates
|
||||
- The holding company accumulates IP licensing revenue in the offshore jurisdiction
|
||||
- The holding company accumulates IP [[file:licensing.org][licensing]] revenue in the offshore jurisdiction
|
||||
|
||||
Pros: Strong IP protection — a judgment against the operating company cannot reach the IP (the operating company doesn't own it). Profits from licensing are outside US tax jurisdiction until repatriated.
|
||||
Cons: US tax reform (TCJA 2017) introduced GILTI (Global Intangible Low-Taxed Income) — this structure is less tax-effective than pre-2017. Transfer pricing documentation required. Increases administrative complexity.
|
||||
@@ -52,7 +52,7 @@ Cons: Complex, expensive to set up and maintain. Many investors are uncomfortabl
|
||||
** Structure D: Delaware C-Corp + Delaware LLC Series + Offshore
|
||||
|
||||
- Delaware C-Corp as parent
|
||||
- Each business line (Logos verification, Agora network, compute marketplace, PDS hosting) is a separate Delaware series LLC
|
||||
- Each business line (Logos verification, Agora network, [[file:compute-marketplace.org][compute marketplace]], PDS hosting) is a separate Delaware series LLC
|
||||
- IP held in an offshore company, licensed to each series LLC
|
||||
- Series LLCs protect assets within each series from liabilities arising in other series
|
||||
|
||||
|
||||
@@ -6,11 +6,11 @@
|
||||
|
||||
The [[file:evaluation-harness.org][evaluation harness]] is not a static test suite written once. It is a living artifact that grows with every deployed instance. Every gate decision that a human corrects becomes a test case. Every bug fix adds an edge case. Every regulatory update adds a rule that must be checked.
|
||||
|
||||
This specification describes how the collective regression suite is built, maintained, and used, with Agora as the substrate for distribution and contribution.
|
||||
This specification describes how the collective regression suite is built, maintained, and used, with [[file:agora.org][Agora]] as the substrate for distribution and contribution.
|
||||
|
||||
**Why collective**
|
||||
|
||||
A single instance learns from its own mistakes. The collective learns from every instance's mistakes. A HIPAA deployment in one hospital discovers an edge case that a SOC2 deployment in a SaaS company would never encounter on its own — but if that SaaS company ever expands into healthcare, their gate stack must handle that edge case. The collective suite gives them hundreds of thousands of edge cases they did not pay to discover.
|
||||
A single instance learns from its own mistakes. The collective learns from every instance's mistakes. A [[file:compliance/hipaa.org][HIPAA]] deployment in one hospital discovers an edge case that a [[file:compliance/soc2.org][SOC2]] deployment in a SaaS company would never encounter on its own — but if that SaaS company ever expands into healthcare, their gate stack must handle that edge case. The collective suite gives them hundreds of thousands of edge cases they did not pay to discover.
|
||||
|
||||
This is the mechanism behind the [[file:verification-monopoly.org][verification monopoly claim]]. A certification means "your gate stack is verified against every edge case ever discovered by any instance in the ecosystem." A competitor starting from scratch cannot buy or scrape this knowledge.
|
||||
|
||||
|
||||
@@ -10,11 +10,11 @@ Three standard dialects: CLIF (Common Logic Interchange Format), CGIF (Conceptua
|
||||
|
||||
**Relevance to Passepartout**
|
||||
|
||||
The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances (Agora sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[file:gate-rule-encoding.org][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas.
|
||||
The fact store interchange format. Passepartout's fact store uses plists internally — fast, native to Lisp, zero serialization cost. But between instances ([[file:agora.org][Agora]] sync, backup/restore, export), a standardized format is needed. CLIF is a strong candidate because its first-order logic is a direct match for the [[file:gate-rule-encoding.org][gate rules]] ACL2 verifies. A CLIF-to-ACL2 translator is mechanically straightforward — both operate on first-order formulas.
|
||||
|
||||
The dialect architecture mirrors Passepartout. CL's defining insight: define abstract semantics, let any concrete syntax map to it, get interoperability for free. This is the exact same pattern as Passepartout's "one gate stack, many skills" — the gate stack defines the security ontology (abstract semantics), and skills (dialects) map their operations to it. CL's approach validates Passepartout's design choice and provides a theoretical framework for it.
|
||||
|
||||
ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for HIPAA, SOC2, FedRAMP, and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires.
|
||||
ISO standard as a credential. For regulated industries, "the knowledge representation follows ISO/IEC 24707" is a strong signal. It says the format is not proprietary, has formal semantics, and has been reviewed by an international body. This matters for [[file:compliance/hipaa.org][HIPAA]], SOC2, [[file:compliance/fedramp.org][FedRAMP]], and any compliance framework that asks about data representation standards. It is a checkbox that enterprise procurement requires.
|
||||
|
||||
The RDF/OWL bridge. CL has defined translations to RDF and OWL. This means Passepartout can consume knowledge from the semantic web without building a separate RDF parser. The fact store stays in plists internally; CL is the serialization and interchange layer. Any enterprise knowledge graph expressed in OWL can be ingested as CLIF, translated to plists, and verified by ACL2.
|
||||
|
||||
|
||||
@@ -381,7 +381,7 @@ gate system without an agent to gate.
|
||||
| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. |
|
||||
| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. |
|
||||
| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). |
|
||||
| Triad | Passepartout + Stoa + Agora | None | No competitor is building a full computing stack + social network. |
|
||||
| Triad | Passepartout + [[file:stoa.org][Stoa]] + [[file:agora.org][Agora]] | None | No competitor is building a full computing stack + social network. |
|
||||
| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. |
|
||||
|
||||
* Where Competitors Lead
|
||||
|
||||
@@ -214,7 +214,7 @@ The OnlyFans/Patreon entry vector is the strongest Phase 1 play: a community wit
|
||||
- [[file:agora.org][Agora overview]] (brain docs)
|
||||
- [[file:agora-contracts.org][Agora contract platform]]
|
||||
- [[file:alternative-growth-social-first.org][Social-first growth scenario]]
|
||||
- [[file:../agora/docs/agora-requirements-01-overview.org][Agora Protocol Overview]] (spec repo)
|
||||
- [[file:../agora/docs/agora-requirements-05-social.org][Social Space specification]]
|
||||
- [[file:../agora/docs/agora-requirements-06-exchange-and-contracts.org][Exchange and Contracts specification]]
|
||||
- [[file:../agora/docs/agora-requirements-10-user-journey.org][User journey and platform replacement strategy]]
|
||||
- Agora Protocol Overview (spec repo)
|
||||
- Social Space specification
|
||||
- Exchange and Contracts specification
|
||||
- User journey and platform replacement strategy
|
||||
|
||||
@@ -8,23 +8,23 @@
|
||||
|
||||
This file has been split into atomic framework notes under [[file:compliance/][compliance/]].
|
||||
|
||||
See [[file:compliance/_index.org][Compliance framework index]] for the hub with per-framework links.
|
||||
See [[file:compliance/compliance-index.org][Compliance framework index]] for the hub with per-framework links.
|
||||
See [[file:compliance/first-mover-window.org][First-mover window analysis]] for timing.
|
||||
See [[file:compliance/revenue-table.org][Revenue table]] for pricing and TAM.
|
||||
See [[file:compliance/revenue-table.org][[[file:compliance/revenue-table.org][Revenue table]]]] for pricing and TAM.
|
||||
|
||||
Each framework is its own file in [[file:compliance/][compliance/]]:
|
||||
- [[file:compliance/hipaa.org][HIPAA]]
|
||||
- [[file:compliance/soc2.org][SOC 2]]
|
||||
- [[file:compliance/gdpr.org][GDPR]]
|
||||
- [[file:compliance/fedramp.org][FedRAMP]]
|
||||
- [[file:compliance/fedramp.org][[[file:compliance/fedramp.org][FedRAMP]]]]
|
||||
- [[file:compliance/sox.org][SOX]]
|
||||
- [[file:compliance/glba.org][GLBA]]
|
||||
- [[file:compliance/ny-dfs-500.org][NY DFS 500]]
|
||||
- [[file:compliance/ny-dfs-500.org][[[file:compliance/ny-dfs-500.org][NY DFS 500]]]]
|
||||
- [[file:compliance/ccpa-cpra.org][CCPA/CPRA]]
|
||||
- [[file:compliance/quebec-law-25.org][Quebec Law 25]]
|
||||
- [[file:compliance/uk-gdpr.org][UK GDPR]]
|
||||
- [[file:compliance/quebec-law-25.org][[[file:compliance/quebec-law-25.org][Quebec Law 25]]]]
|
||||
- [[file:compliance/uk-gdpr.org][[[file:compliance/uk-gdpr.org][UK [[file:compliance/gdpr.org][GDPR]]]]]]
|
||||
- [[file:compliance/nis2.org][NIS2]]
|
||||
- [[file:compliance/eu-ai-act.org][EU AI Act]]
|
||||
- [[file:compliance/eu-ai-act.org][[[file:compliance/eu-ai-act.org][EU AI Act]]]]
|
||||
- [[file:compliance/dora.org][DORA]]
|
||||
- [[file:compliance/eidas2.org][eIDAS 2.0]]
|
||||
- [[file:compliance/cra.org][CRA]]
|
||||
@@ -32,17 +32,17 @@ Each framework is its own file in [[file:compliance/][compliance/]]:
|
||||
- [[file:compliance/ismap.org][ISMAP]]
|
||||
- [[file:compliance/pipa.org][PIPA]]
|
||||
- [[file:compliance/privacy-act-aus.org][Privacy Act Australia]]
|
||||
- [[file:compliance/apra-cps-234.org][APRA CPS 234]]
|
||||
- [[file:compliance/apra-cps-234.org][[[file:compliance/apra-cps-234.org][APRA CPS 234]]]]
|
||||
- [[file:compliance/irap.org][IRAP]]
|
||||
- [[file:compliance/dpdp-act.org][DPDP Act India]]
|
||||
- [[file:compliance/dpdp-act.org][[[file:compliance/dpdp-act.org][DPDP Act]] India]]
|
||||
- [[file:compliance/lgpd.org][LGPD Brazil]]
|
||||
- [[file:compliance/lfp-dppp.org][LFPDPPP Mexico]]
|
||||
- [[file:compliance/iso-27001.org][ISO 27001]]
|
||||
- [[file:compliance/iso-27701.org][ISO 27701]]
|
||||
- [[file:compliance/basel-iii.org][Basel III]]
|
||||
- [[file:compliance/iso-27001.org][[[file:compliance/iso-27001.org][ISO 27001]]]]
|
||||
- [[file:compliance/iso-27701.org][[[file:compliance/iso-27701.org][ISO 27701]]]]
|
||||
- [[file:compliance/basel-iii.org][[[file:compliance/basel-iii.org][Basel III]]]]
|
||||
- [[file:compliance/fatf.org][FATF AML/CFT]]
|
||||
- [[file:compliance/ifrs.org][IFRS]]
|
||||
- [[file:compliance/oecd.org][OECD Privacy/AI]]
|
||||
- [[file:compliance/world-bank-esf.org][World Bank ESF]]
|
||||
- [[file:compliance/world-bank-esf.org][[[file:compliance/world-bank-esf.org][World Bank ESF]]]]
|
||||
- [[file:compliance/ifc-ps.org][IFC PS]]
|
||||
- [[file:compliance/un-cefact.org][UN/CEFACT]]
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-appi
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: APPI (Act on the Protection of Personal Information — Japan)
|
||||
#+filetags: :passepartout:compliance:framework:appi:
|
||||
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ license cancellation for non-compliance. Personal liability for board and
|
||||
senior management.
|
||||
|
||||
Why it matters: CPS 234's control testing requirement creates demand for
|
||||
continuous verification — exactly what the gate stack and evaluation harness
|
||||
continuous verification — exactly what the gate stack and [[file:../evaluation-harness.org][evaluation harness]]
|
||||
provide. First-mover advantage: CPS 234 is mature (2019) but enforcement is
|
||||
escalating. No vendor provides a deterministic control-testing pipeline.
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
:ID: auto-ccpa-cpra
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: CCPA/CPRA (California Consumer Privacy Act)
|
||||
#+filetags: :passepartout:compliance:framework:ccpa:
|
||||
|
||||
|
||||
California's comprehensive privacy law — the closest US analogue to GDPR.
|
||||
California's comprehensive privacy law — the closest US analogue to [[file:gdpr.org][GDPR]].
|
||||
CPRA (effective 2023) amended and strengthened CCPA. Key rights: right to
|
||||
know, delete, opt out of sale/sharing, correct inaccurate data, limit use
|
||||
of sensitive PI. Private right of action for data breaches.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
#+title: Compliance Framework Index — Global Regulated Industries
|
||||
#+filetags: :passepartout:triad:compliance:global:index:hub:
|
||||
|
||||
The verification monopoly and domain gate package revenue streams depend on
|
||||
The [[file:../verification-monopoly.org][verification monopoly]] and domain gate package revenue streams depend on
|
||||
selling into regulated industries. These industries buy compliance, not software.
|
||||
Each framework below maps to a gate package the triad can sell — ACL2-verified
|
||||
gate rules that produce deterministic audit trails.
|
||||
@@ -75,5 +75,5 @@ See [[file:first-mover-window.org][First-mover window analysis]] and [[file:reve
|
||||
| International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) |
|
||||
|
||||
Next: [[file:first-mover-window.org][First-mover window analysis]] | [[file:revenue-table.org][Full revenue table]]
|
||||
See also: [[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/domain-gate-packages.org][Domain gate packages]],
|
||||
[[file:../../ideas/compute-marketplace.org][Compute marketplace]], [[file:../../ideas/infrastructure-lock-in.org][Infrastructure lock-in]]
|
||||
See also: [[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/domain-gate-packages.org][[[file:../domain-gate-packages.org][Domain gate packages]]]],
|
||||
[[file:../../ideas/compute-marketplace.org][[[file:../compute-marketplace.org][Compute marketplace]]]], [[file:../../ideas/infrastructure-lock-in.org][Infrastructure lock-in]]
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-cra
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: transaction." First-mover advantage: wallets are being built now; the provider
|
||||
#+title: CRA (EU Cyber Resilience Act)
|
||||
#+filetags: :passepartout:compliance:framework:cra:
|
||||
|
||||
transaction." First-mover advantage: wallets are being built now; the provider
|
||||
@@ -23,8 +23,8 @@ Penalties: Up to 15M EUR or 2.5% of global turnover for non-compliance with
|
||||
reporting obligations.
|
||||
|
||||
Why it matters: CRA's CE marking requirement creates a certification pipeline
|
||||
that the verification appliance can supply. If Passepartout's gate stack is
|
||||
itself CRA-compliant (verified by the evaluation harness), it becomes the
|
||||
that the [[file:../verification-appliance.org][verification appliance]] can supply. If Passepartout's gate stack is
|
||||
itself CRA-compliant (verified by the [[file:../evaluation-harness.org][evaluation harness]]), it becomes the
|
||||
compliance infrastructure for any product built on it. First-mover advantage:
|
||||
Class II products require notified body assessment — the bottleneck is notified
|
||||
body capacity. The gate stack's automated evidence pipeline bypasses the
|
||||
|
||||
@@ -22,7 +22,7 @@ Penalties: Up to 2% of average daily turnover × number of days breached, or
|
||||
|
||||
Why it matters: DORA's third-party risk management requirement is a natural gate
|
||||
stack use case — every ICT provider access must be gated, logged, and auditable.
|
||||
TLPT (threat-led penetration testing) maps to the evaluation harness. First-mover
|
||||
TLPT (threat-led penetration testing) maps to the [[file:../evaluation-harness.org][evaluation harness]]. First-mover
|
||||
advantage is extremely time-sensitive: DORA is already in effect (January 2025).
|
||||
Financial institutions are scrambling for compliance tooling. A DORA gate package
|
||||
at $50K/yr with zero incremental cost per additional user is an immediate sale.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-dpdp-act
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: DPDP Act (Digital Personal Data Protection Act — India)
|
||||
#+filetags: :passepartout:compliance:framework:dpdp:
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-eidas2
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: eIDAS 2.0 (European Digital Identity Framework)
|
||||
#+filetags: :passepartout:compliance:framework:eidas2:
|
||||
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Who must comply: Providers and deployers of AI systems in the EU. Extraterritori
|
||||
if the AI system output is used in the EU. Scope covers GPAI (general-purpose AI)
|
||||
with additional obligations for systemic-risk GPAI.
|
||||
|
||||
Penalties: Up to 35M EUR or 7% of global turnover (higher than GDPR).
|
||||
Penalties: Up to 35M EUR or 7% of global turnover (higher than [[file:gdpr.org][GDPR]]).
|
||||
|
||||
Why it matters: The EU AI Act's conformity assessment requirement creates an
|
||||
instant certification market. Passepartout's gate stack can serve as the
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-fatf
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB
|
||||
#+title: FATF (Financial Action Task Force)
|
||||
#+filetags: :passepartout:compliance:framework:fatf:
|
||||
|
||||
risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB
|
||||
|
||||
@@ -12,12 +12,12 @@ dominance before incumbents respond or the market settles on a standard approach
|
||||
|
||||
| Window | Frameworks | Rationale |
|
||||
|--------|-----------|-----------|
|
||||
| **Critical (<12 months)** | EU AI Act (Aug 2026 effective), NIS2 (Oct 2025 deadline), DORA (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
|
||||
| **Wide (12-36 months)** | DPDP Act 2023 (rules drafting), India privacy; Privacy Act Review (Australia); Quebec Law 25; CRA phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
|
||||
| **Mature (commodity)** | GDPR (2018), SOX (2002), HIPAA (1996), GLBA (1999), Basel III (2010), FATF 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
|
||||
| **Latent (undiscovered)** | OECD AI Principles, UN/CEFACT, World Bank ESF, IFC PS | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
|
||||
| **Critical (<12 months)** | [[file:eu-ai-act.org][EU AI Act]] (Aug 2026 effective), [[file:nis2.org][NIS2]] (Oct 2025 deadline), [[file:dora.org][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
|
||||
| **Wide (12-36 months)** | [[file:dpdp-act.org][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[file:quebec-law-25.org][Quebec Law 25]]; [[file:cra.org][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
|
||||
| **Mature (commodity)** | [[file:gdpr.org][GDPR]] (2018), [[file:sox.org][SOX]] (2002), [[file:hipaa.org][HIPAA]] (1996), [[file:glba.org][GLBA]] (1999), [[file:basel-iii.org][Basel III]] (2010), [[file:fatf.org][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
|
||||
| **Latent (undiscovered)** | [[file:oecd.org][OECD]] AI Principles, UN/CEFACT, [[file:world-bank-esf.org][World Bank ESF]], [[file:ifc-ps.org][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
|
||||
|
||||
|
||||
|
||||
See also: [[file:_index.org][Compliance index]], [[file:revenue-table.org][Revenue table]],
|
||||
[[file:../../ideas/verification-appliance.org][Verification appliance]], [[file:../../ideas/verification-monopoly.org][Verification monopoly]]
|
||||
See also: [[file:compliance-index.org][Compliance index]], [[file:revenue-table.org][Revenue table]],
|
||||
[[file:../../ideas/verification-appliance.org][[[file:../verification-appliance.org][Verification appliance]]]], [[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]]
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-glba
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: GLBA (Gramm-Leach-Bliley Act)
|
||||
#+filetags: :passepartout:compliance:framework:glba:
|
||||
|
||||
|
||||
@@ -19,5 +19,5 @@ and directors personally liable.
|
||||
Why it matters: The Safeguards Rule maps directly to gate stack access controls.
|
||||
Every NPI access is gated; the proof log is the security program's evidence.
|
||||
First-mover advantage is narrow (GLBA is well-understood) but the market is
|
||||
large because every financial institution that dodges HIPAA still faces GLBA.
|
||||
large because every financial institution that dodges [[file:hipaa.org][HIPAA]] still faces GLBA.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-ifc-ps
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: projects in 100+ countries. Also adopted by many multilateral development banks
|
||||
#+title: IFC Performance Standards
|
||||
#+filetags: :passepartout:compliance:framework:ifc:
|
||||
|
||||
projects in 100+ countries. Also adopted by many multilateral development banks
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-ifrs
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: IFC Performance Standards (Environmental and Social Sustainability)
|
||||
#+filetags: :passepartout:compliance:framework:ifrs:
|
||||
|
||||
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
:ID: auto-irap
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: IRAP (Infosec Registered Assessors Program — Australia)
|
||||
#+filetags: :passepartout:compliance:framework:irap:
|
||||
|
||||
|
||||
** IRAP (Infosec Registered Assessors Program)
|
||||
|
||||
Australian government's cloud security assessment program — analogous to
|
||||
FedRAMP. Cloud services used by Australian government agencies must have an
|
||||
[[file:fedramp.org][FedRAMP]]. Cloud services used by Australian government agencies must have an
|
||||
IRAP assessment. Managed by the Australian Cyber Security Centre (ACSC).
|
||||
Assessment levels: Protected (highest), Secret (top secret), Unclassified DLM.
|
||||
|
||||
Who must comply: Cloud providers selling to Australian federal, state, and
|
||||
local government agencies. Also critical infrastructure providers.
|
||||
|
||||
Why it matters: Like FedRAMP and ISMAP, IRAP is a procurement gate. An IRAP
|
||||
Why it matters: Like FedRAMP and [[file:ismap.org][ISMAP]], IRAP is a procurement gate. An IRAP
|
||||
Protected-level assessment is expensive and takes 6-12 months. First-mover
|
||||
advantage: the gate stack's deterministic audit trail can be the primary
|
||||
evidence artifact, reducing assessment scope/cost.
|
||||
|
||||
@@ -2,15 +2,15 @@
|
||||
:ID: auto-ismap
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: is moderate — few non-Japanese vendors target APPI specifically, and the 2022
|
||||
#+title: ISMAP (Government Security Framework — Japan)
|
||||
#+filetags: :passepartout:compliance:framework:ismap:
|
||||
|
||||
is moderate — few non-Japanese vendors target APPI specifically, and the 2022
|
||||
is moderate — few non-Japanese vendors target [[file:appi.org][APPI]] specifically, and the 2022
|
||||
amendments added requirements that created compliance gaps.
|
||||
|
||||
** ISMAP (Government Information System Security Management and Assessment Program)
|
||||
|
||||
Japan's government cloud security program — analogous to FedRAMP. Cloud services
|
||||
Japan's government cloud security program — analogous to [[file:fedramp.org][FedRAMP]]. Cloud services
|
||||
used by Japanese government agencies must be ISMAP-authorized. Managed by the
|
||||
Digital Agency and the Information-technology Promotion Agency (IPA).
|
||||
|
||||
@@ -18,7 +18,7 @@ Who must comply: Cloud service providers selling to Japanese national and local
|
||||
government agencies.
|
||||
|
||||
Why it matters: Like FedRAMP, ISMAP is a procurement gate. Authorization is
|
||||
time-consuming and expensive. A compute marketplace provider with ISMAP
|
||||
time-consuming and expensive. A [[file:../compute-marketplace.org][compute marketplace]] provider with ISMAP
|
||||
authorization has exclusive access to the Japanese government market. First-mover
|
||||
advantage is significant — as of 2025, fewer than 100 services are ISMAP-registered.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-iso-27001
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: ISO/IEC 27001 (Information Security Management)
|
||||
#+filetags: :passepartout:compliance:framework:iso:
|
||||
|
||||
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
:ID: auto-iso-27701
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: ISO/IEC 27701 (Privacy Information Management)
|
||||
#+filetags: :passepartout:compliance:framework:iso:
|
||||
|
||||
|
||||
International standard extending ISO 27001 for privacy information management.
|
||||
Aligns with GDPR requirements. Provides a framework for PII (personally
|
||||
International standard extending [[file:iso-27001.org][ISO 27001]] for privacy information management.
|
||||
Aligns with [[file:gdpr.org][GDPR]] requirements. Provides a framework for PII (personally
|
||||
identifiable information) controllers and processors.
|
||||
|
||||
Why it matters: ISO 27701 bridges information security and privacy compliance.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-lfp-dppp
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: LFPDPPP (Ley Federal de Protección de Datos Personales — Mexico)
|
||||
#+filetags: :passepartout:compliance:framework:lfp:
|
||||
|
||||
|
||||
@@ -20,5 +20,5 @@ Why it matters: USMCA (US-Mexico-Canada Agreement) trade obligations are
|
||||
pushing toward privacy regime interoperability. A bilingual (Spanish/English)
|
||||
gate package covering both LFPDPPP and US frameworks serves the massive
|
||||
US-Mexico cross-border commerce market. First-mover advantage: LFPDPPP is
|
||||
less automated than GDPR; the market has fewer vendors and lower expectations.
|
||||
less automated than [[file:gdpr.org][GDPR]]; the market has fewer vendors and lower expectations.
|
||||
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
:ID: auto-lgpd
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: LGPD (Lei Geral de Proteção de Dados — Brazil)
|
||||
#+filetags: :passepartout:compliance:framework:lgpd:
|
||||
|
||||
|
||||
Brazil's comprehensive privacy law (effective 2020, fines effective 2023).
|
||||
Modeled on GDPR but with differences: LGPD defines "data processing agents"
|
||||
Modeled on [[file:gdpr.org][GDPR]] but with differences: LGPD defines "data processing agents"
|
||||
(controller and operator), requires appointment of DPO (data protection officer),
|
||||
mandates breach notification to ANPD (National Data Protection Authority) and
|
||||
affected data subjects. 10 legal bases for processing (vs 6 in GDPR).
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-nis2
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: NIS 2 Directive (EU Network and Information Security)
|
||||
#+filetags: :passepartout:compliance:framework:nis2:
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-ny-dfs-500
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: NY DFS 500 (New York Cybersecurity Regulation)
|
||||
#+filetags: :passepartout:compliance:framework:ny:
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-oecd
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: verification path, and produce an auditable trail for every suspicion
|
||||
#+title: OECD Guidelines
|
||||
#+filetags: :passepartout:compliance:framework:oecd:
|
||||
|
||||
verification path, and produce an auditable trail for every suspicion
|
||||
@@ -17,7 +17,7 @@ approach.
|
||||
OECD Privacy Guidelines (revised 2013): Eight principles — collection limitation,
|
||||
data quality, purpose specification, use limitation, security safeguards,
|
||||
openness, individual participation, accountability. Non-binding but foundational
|
||||
— the basis for GDPR, APPI, LGPD, and most other privacy laws.
|
||||
— the basis for [[file:gdpr.org][GDPR]], [[file:appi.org][APPI]], [[file:lgpd.org][LGPD]], and most other privacy laws.
|
||||
|
||||
OECD AI Principles (adopted 2019, updated 2024): Five values-based principles
|
||||
— inclusive growth and well-being, human-centered values and fairness,
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-pipa
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: PIPA (Personal Information Protection Act — South Korea)
|
||||
#+filetags: :passepartout:compliance:framework:pipa:
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ against major tech companies. Class action lawsuits permitted.
|
||||
Who must comply: Any organization handling personal information of South Korean
|
||||
residents. Extraterritorial scope is broad and actively enforced.
|
||||
|
||||
Why it matters: PIPA is structurally similar to GDPR but with stricter
|
||||
Why it matters: PIPA is structurally similar to [[file:gdpr.org][GDPR]] but with stricter
|
||||
enforcement and higher penalties relative to market size. The gate stack's
|
||||
purpose-boundary gates map directly to PIPA's purpose limitation requirement.
|
||||
First-mover advantage is large — PIPA has fewer compliance automation vendors
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-privacy-act-aus
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: Privacy Act 1988 (Australia)
|
||||
#+filetags: :passepartout:compliance:framework:privacy:
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-quebec-law-25
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: gate rules. The gate stack can encode "this data flow crosses a CCPA boundary"
|
||||
#+title: Quebec Law 25
|
||||
#+filetags: :passepartout:compliance:framework:quebec:
|
||||
|
||||
gate rules. The gate stack can encode "this data flow crosses a CCPA boundary"
|
||||
@@ -13,7 +13,7 @@ verifiable audit trail — they are all document-based.
|
||||
** Canadian provincial privacy (Quebec Law 25, Ontario PHIPA)
|
||||
|
||||
Quebec Law 25 (2023-2024 phased) is Canada's most aggressive privacy
|
||||
regulation — closer to GDPR than PIPEDA. Requires: privacy officer appointment,
|
||||
regulation — closer to [[file:gdpr.org][GDPR]] than PIPEDA. Requires: privacy officer appointment,
|
||||
privacy impact assessments, consent modernization, data portability, right to
|
||||
de-index, algorithm transparency (automated decision-making disclosures).
|
||||
Penalties up to $25M CAD or 4% of global revenue.
|
||||
|
||||
@@ -9,39 +9,39 @@
|
||||
|
||||
| Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
|
||||
|-----------|--------|--------------|------------------|-------------------|---------------------|----------------|
|
||||
| HIPAA | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
|
||||
| [[file:hipaa.org][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
|
||||
| SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
|
||||
| GDPR | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
|
||||
| FedRAMP | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
|
||||
| SOX | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
|
||||
| GLBA | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
||||
| NY DFS 500 | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
||||
| [[file:gdpr.org][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
|
||||
| [[file:fedramp.org][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
|
||||
| [[file:sox.org][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
|
||||
| [[file:glba.org][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
||||
| [[file:ny-dfs-500.org][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
||||
| CCPA/CPRA | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
|
||||
| NIS2 | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
|
||||
| EU AI Act | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
|
||||
| DORA | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
|
||||
| [[file:nis2.org][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
|
||||
| [[file:eu-ai-act.org][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
|
||||
| [[file:dora.org][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
|
||||
| eIDAS 2.0 | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
|
||||
| CRA | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
|
||||
| UK GDPR | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
|
||||
| APPI | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
|
||||
| ISMAP | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
|
||||
| PIPA | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
|
||||
| [[file:cra.org][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
|
||||
| [[file:uk-gdpr.org][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
|
||||
| [[file:appi.org][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
|
||||
| [[file:ismap.org][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
|
||||
| [[file:pipa.org][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
|
||||
| Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
|
||||
| APRA CPS 234 | Australia | $40K | 500 | $20M | Moderate | Info security controls |
|
||||
| IRAP | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
|
||||
| DPDP Act | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
|
||||
| LGPD | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
||||
| [[file:apra-cps-234.org][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls |
|
||||
| [[file:irap.org][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
|
||||
| [[file:dpdp-act.org][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
|
||||
| [[file:lgpd.org][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
||||
| LFPDPPP | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
|
||||
| ISO 27001 | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
|
||||
| ISO 27701 | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
|
||||
| Basel III | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
|
||||
| FATF AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
|
||||
| IFRS 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
|
||||
| [[file:iso-27001.org][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
|
||||
| [[file:iso-27701.org][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
|
||||
| [[file:basel-iii.org][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
|
||||
| [[file:fatf.org][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
|
||||
| [[file:ifrs.org][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
|
||||
| UN/CEFACT | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
|
||||
| World Bank ESF | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
|
||||
| IFC PS | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
|
||||
| [[file:world-bank-esf.org][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
|
||||
| [[file:ifc-ps.org][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
|
||||
|
||||
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
||||
A [[file:../compute-marketplace.org][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP +
|
||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||
@@ -56,5 +56,5 @@ for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||
At 10,000 such enterprises: $5B/yr.
|
||||
|
||||
See also: [[file:_index.org][Compliance index]], [[file:first-mover-window.org][First-mover window analysis]],
|
||||
[[file:../../ideas/verification-monopoly.org][Verification monopoly]], [[file:../../ideas/compute-marketplace.org][Compute marketplace]]
|
||||
See also: [[file:compliance-index.org][Compliance index]], [[file:first-mover-window.org][First-mover window analysis]],
|
||||
[[file:../../ideas/verification-monopoly.org][[[file:../verification-monopoly.org][Verification monopoly]]]], [[file:../../ideas/compute-marketplace.org][Compute marketplace]]
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-sox
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: SOX (Sarbanes-Oxley Act)
|
||||
#+filetags: :passepartout:compliance:framework:sox:
|
||||
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
:PROPERTIES:
|
||||
:ID: auto-uk-gdpr
|
||||
:ID: auto-uk-[[file:gdpr.org][gdpr]]
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title:
|
||||
#+title: UK GDPR (Post-Brexit Data Protection)
|
||||
#+filetags: :passepartout:compliance:framework:uk:
|
||||
|
||||
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
:ID: auto-un-cefact
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most
|
||||
#+title: UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)
|
||||
#+filetags: :passepartout:compliance:framework:un:
|
||||
|
||||
EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most
|
||||
of Asia and Africa. The US (GAAP) is the major holdout.
|
||||
|
||||
Why it matters: IFRS 17 and IFRS 9 are algorithmically complex rule sets.
|
||||
Why it matters: [[file:ifrs.org][IFRS]] 17 and IFRS 9 are algorithmically complex rule sets.
|
||||
Getting an actuarial model or credit loss calculation wrong is a financial
|
||||
reporting error. The gate stack's ACL2 prover can verify that the calculation
|
||||
implementations match the standard's mathematical requirements. First-mover
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
:ID: auto-world-bank-esf
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: — inclusive growth and well-being, human-centered values and fairness,
|
||||
#+title: World Bank Environmental and Social Framework
|
||||
#+filetags: :passepartout:compliance:framework:world:
|
||||
|
||||
— inclusive growth and well-being, human-centered values and fairness,
|
||||
@@ -10,7 +10,7 @@ transparency and explainability, robustness and safety, accountability.
|
||||
Non-binding but influential — the AI Act, Canada's AIDA, and Japan's AI
|
||||
guidelines all cite them.
|
||||
|
||||
Why it matters: The OECD frameworks are indirect revenue drivers. Regulatory
|
||||
Why it matters: The [[file:oecd.org][OECD]] frameworks are indirect revenue drivers. Regulatory
|
||||
alignment with OECD principles is often a procurement requirement for
|
||||
international organizations and development finance institutions. First-mover
|
||||
advantage is about standard-setting: the gate package that maps to OECD
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
#+title: Agora Compute Marketplace
|
||||
#+filetags: :passepartout:agora:revenue:compute:marketplace:
|
||||
|
||||
Passepartout instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the Agora network.
|
||||
Passepartout instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the [[file:agora.org][Agora]] network.
|
||||
|
||||
The early player runs a large instance and sells compute to smaller instances. The AGPL allows this because the marketplace is a service, not a modification of the code. Revenue is a percentage of each compute transaction.
|
||||
|
||||
@@ -22,7 +22,7 @@ Your local instance cannot produce any of this. The provider's proof carries /re
|
||||
|
||||
**3. Bootstrap verification for new instances.** A fresh Passepartout cannot verify its own initial state — the bootstrapping problem. You need a working system to generate the proof that the system is correct, but the proof refers to the system itself. The marketplace provides bootstrap proofs from existing trusted providers. Once verified, your instance stands on its own, but the initial self-certification requires an external prover that /already/ has a self-verified image. This is a one-time cost per instance (or per upgrade).
|
||||
|
||||
Secondary but real: burst capacity for heavy proofs (hours-long ACL2 conjectures you do not want tying up your daily agent's CPU), collective regression suite execution (small instances contribute edge cases but cannot run the full suite on every change), and latency guarantees for time-critical gate verifications (trading, emergency shutdown). These are infrastructure economics — the same reason individuals buy cloud burst instances despite having their own hardware.
|
||||
Secondary but real: burst capacity for heavy proofs (hours-long ACL2 conjectures you do not want tying up your daily agent's CPU), [[file:collective-regression-suite.org][collective regression suite]] execution (small instances contribute edge cases but cannot run the full suite on every change), and latency guarantees for time-critical gate verifications (trading, emergency shutdown). These are infrastructure economics — the same reason individuals buy cloud burst instances despite having their own hardware.
|
||||
|
||||
If Passepartout instances on Agora transact billions of verified operations per day, the spread on compute transactions is enormous. This is not a product sale — it is a bet on network effects. Every new instance increases the value of the network (more capacity, more diversity, more resilience).
|
||||
|
||||
|
||||
@@ -6,10 +6,10 @@
|
||||
|
||||
Pre-verified [[file:gate-rule-encoding.org][gate rule]] packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
|
||||
|
||||
- HIPAA package: $50K/yr
|
||||
- SOC2 package: $50K/yr
|
||||
- GDPR package: $50K/yr
|
||||
- FedRAMP package: $100K/yr
|
||||
- [[file:compliance/hipaa.org][HIPAA]] package: $50K/yr
|
||||
- [[file:compliance/soc2.org][SOC2]] package: $50K/yr
|
||||
- [[file:compliance/gdpr.org][GDPR]] package: $50K/yr
|
||||
- [[file:compliance/fedramp.org][FedRAMP]] package: $100K/yr
|
||||
- Combined enterprise: $250K/yr
|
||||
|
||||
Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[file:infrastructure-lock-in.org][infrastructure lock-in]] compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
|
||||
|
||||
@@ -39,7 +39,7 @@ Key observation: the verified API gateway decouples the effect from triad adopti
|
||||
|-------+-------------------+------------------------|
|
||||
| 100–500 | /Regulation as code:/ first regulator encodes a rule as a gate | All regulated entities under that regulator must adopt Passepartout — step function in demand |
|
||||
| 500–2K | /AI safety shift:/ gate rule verification becomes expected in enterprise AI procurement | Every company buying AI services requires a proof log — API gateway demand explodes |
|
||||
| 2K–10K | /Proof library compounding:/ the collective regression suite has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage |
|
||||
| 2K–10K | /Proof library compounding:/ the [[file:collective-regression-suite.org][collective regression suite]] has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage |
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
#+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. Agora (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable.
|
||||
The triad has two independent growth engines that share the same infrastructure. Logos (verification) grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[file:agora.org][Agora]] (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable.
|
||||
|
||||
This page defines the combined growth strategy across four phases, with each engine advancing in parallel and reinforcing the other at specific transitions.
|
||||
|
||||
@@ -124,7 +124,7 @@ This is the critical reinforcement point:
|
||||
*Growth lever:* Stoa premium enterprise features + insurance marketplace.
|
||||
|
||||
*Tactics:*
|
||||
1. Stoa premium ships SSO, compliance dashboards, fleet management.
|
||||
1. [[file:stoa.org][Stoa]] premium ships SSO, compliance dashboards, fleet management.
|
||||
2. Insurance marketplace forms — actuaries price proof insurance based on track records of 10K+ instances.
|
||||
3. Verification monopoly begins — the gate library is the largest, most cited, most battle-tested.
|
||||
|
||||
@@ -197,4 +197,4 @@ The crossover is automatic. Enterprise employees get DIDs from their company's P
|
||||
- [[file:compute-marketplace.org][Compute marketplace]]
|
||||
- [[file:verification-monopoly.org][Verification monopoly]]
|
||||
- [[file:agora-contracts.org][Agora contracts]]
|
||||
- [[file:../agora/docs/agora-requirements-00-readme.org][Agora Protocol Specification — full requirements]]
|
||||
- Agora Protocol Specification — full requirements (spec repo at /tmp/agora)
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
#+title: Infrastructure Lock-In and Switching Costs
|
||||
#+filetags: :passepartout:economics:moats:lock-in:switching:
|
||||
|
||||
A hospital that runs Passepartout with HIPAA gate rules ($50K/yr) for five years has accumulated:
|
||||
A hospital that runs Passepartout with [[file:compliance/hipaa.org][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
|
||||
|
||||
@@ -43,7 +43,7 @@ Wyoming passed HB 185 in 2025 creating the "Decentralized Autonomous Organizatio
|
||||
|
||||
** Relevance to This Venture
|
||||
|
||||
The 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 [[file:agora.org][Agora]]'s governance modules (liquid democracy, Collective Personas, GEM) map /directly/ onto the DAO LLC concept. If a community on the Agora wants to be a legal entity — own a shared website domain, hold a pooled treasury, sign a contract with a vendor — they could incorporate as a Wyoming DAO LLC. The Agora's existing governance infrastructure (voting, constitutions, role management) becomes the DAO LLC's management mechanism.
|
||||
|
||||
** This Is Not the OpCo or IP Co Structure
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Recommended structure: Delaware C-Corp (US OpCo) + BVI Business Company (IP Co).
|
||||
│
|
||||
owns the IP assets
|
||||
(Passepartout code, gate rules,
|
||||
ACL2 libraries, Agora protocol
|
||||
ACL2 libraries, [[file:agora.org][Agora]] protocol
|
||||
spec, trademarks, domain names)
|
||||
|
||||
The OpCo pays the IP Co an arm's-length royalty for the right to use the IP in its business (compliance sales, PDS hosting, marketplace operations). The IP Co accumulates royalty income in a tax-neutral jurisdiction (BVI has 0% corporate tax). The founders own both entities under the same cap table.
|
||||
@@ -132,7 +132,7 @@ This is the most important document. It must:
|
||||
|
||||
4. /Territory:/ Global license, exclusive or non-exclusive.
|
||||
|
||||
5. /Sub-licensing:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing.
|
||||
5. /Sub-[[file:licensing.org][licensing]]:/ Whether the OpCo can sub-license. Typically no — the IP Co controls sub-licensing.
|
||||
|
||||
* Layer 3: Founders' Ownership
|
||||
|
||||
|
||||
@@ -77,5 +77,5 @@ This is adequate while the gate stack and planner are the priority.
|
||||
The native org module replaces gbrain entirely once built.
|
||||
|
||||
** See also
|
||||
[[file:../../concepts/compliance-framework-mapping.org][Compliance framework mapping]]
|
||||
[[file:../../ideas/passepartout-economics.org][Passepartout economics]]
|
||||
[[file:../../concepts/compliance-framework-mapping.org][[[file:compliance-framework-mapping.org][Compliance framework mapping]]]]
|
||||
[[file:../../ideas/passepartout-economics.org][[[file:passepartout-economics.org][Passepartout economics]]]]
|
||||
|
||||
@@ -17,7 +17,7 @@ The hierarchy:
|
||||
| Days | Shippable thing, momentum building | Next day | Drift, distraction |
|
||||
| Weeks | Sprint, feature, market pulse | One cycle | Wrong direction |
|
||||
| Months | Product cycle, hiring, traction | One data point | Bleeding out slow |
|
||||
| Years | Company, moats, technology shifts | Scarce | Irrelevance |
|
||||
| Years | Company, [[file:moats.org][moats]], technology shifts | Scarce | Irrelevance |
|
||||
| Generations | Culture, regulation, infrastructure | Post-founding | Irreversibility |
|
||||
|
||||
Practical use:
|
||||
|
||||
@@ -34,7 +34,7 @@ Penalties: $46,517 per violation. Criminal penalties for harvesting + sending.
|
||||
|
||||
** EU/EEA — GDPR (2018)
|
||||
|
||||
/Applies to:/ Processing personal data of data subjects in the EU, regardless of where the controller is established. GDPR has extraterritorial reach (Article 3).
|
||||
/Applies to:/ Processing personal data of data subjects in the EU, regardless of where the controller is established. [[file:compliance/gdpr.org][GDPR]] has extraterritorial reach (Article 3).
|
||||
|
||||
Relevant requirements:
|
||||
1. /Lawful basis required for processing./ Cold email to a corporate address may use "legitimate interest" (Article 6(1)(f)) or "consent" (Article 6(1)(a)). For B2B cold email to professional addresses, legitimate interest is the standard basis — but must balance against the recipient's rights.
|
||||
@@ -127,6 +127,6 @@ The automation waits on Passepartout — but the legal foundation and the infras
|
||||
|
||||
- CAN-SPAM Act (15 U.S.C. 7701-7713)
|
||||
- GDPR (Regulation (EU) 2016/679)
|
||||
- UK GDPR + PECR (SI 2003/2426)
|
||||
- [[file:compliance/uk-gdpr.org][UK GDPR]] + PECR (SI 2003/2426)
|
||||
- Egypt PDPL (Law No. 151 of 2020)
|
||||
- CASL (S.C. 2010, c. 23)
|
||||
|
||||
@@ -196,7 +196,7 @@ defensibility.
|
||||
** Cost structure
|
||||
|
||||
- One-time cost: gate-rule encoding for a domain (from hours for codified
|
||||
domains — FAR, HIPAA, ISO standards — up to months for tacit domains)
|
||||
domains — FAR, [[file:compliance/hipaa.org][HIPAA]], ISO standards — up to months for tacit domains)
|
||||
- The LLM translates codified rules directly: ingest regulation → produce
|
||||
gate rule plist → ACL2 verifies consistency → human reviews. This is
|
||||
translation, not reasoning.
|
||||
@@ -214,7 +214,7 @@ defensibility.
|
||||
| Industrial infrastructure (refineries, power grids, manufacturing) | Offline operation, provably safe, near-zero marginal cost, mandatory audit trail | Lisp Machine appliance + SCADA certification package |
|
||||
| Healthcare administration (billing, claims, prior authorization) | Rule-heavy domain, privacy-mandated, audit-driven, high per-transaction cost today | Subscription for regulatory gate packages (CPT/ICD-10/HIPAA rules), updated when CMS publishes new rules |
|
||||
| Software supply chain (CI/CD security, SBOM verification) | First-order structural verification — ACL2 is natural fit, CI/CD pipeline is already a sequence of gate-checkable steps | Evaluation harness as certification service — "run our 10,000-task suite and get a provable score" |
|
||||
| Regulatory compliance (GDPR, SOC2, SOX, GxP) | Rule-completeness, active enforcement (not document-based), provable audit trail | Subscription for regulation-specific gate packages — GDPR package, SOC2 package, FedRAMP package, updated when regulations change |
|
||||
| Regulatory compliance ([[file:compliance/gdpr.org][GDPR]], [[file:compliance/soc2.org][SOC2]], [[file:compliance/sox.org][SOX]], GxP) | Rule-completeness, active enforcement (not document-based), provable audit trail | Subscription for regulation-specific gate packages — GDPR package, SOC2 package, [[file:compliance/fedramp.org][FedRAMP]] package, updated when regulations change |
|
||||
| Defense and classified environments | Air-gapped operation, classification-level gate rules, Merkle provenance is court-admissible evidence | Government contract + hardened appliance with hardware root of trust |
|
||||
|
||||
** Critical insight: encoding cost drops to near-zero for codified domains **
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
#+title: Personal Data Store as a Service
|
||||
#+filetags: :passepartout:agora:revenue:pds:saas:
|
||||
|
||||
Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on Agora can be self-hosted (free, AGPL) or hosted by the early player.
|
||||
Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on [[file:agora.org][Agora]] can be self-hosted (free, AGPL) or hosted by the early player.
|
||||
|
||||
- **Free tier (self-hosted):** full AGPL PDS, runs on any Lisp host, full control, no cost
|
||||
- **Basic hosted tier:** $10-$20/month, 10GB fact store, 10M queries/month, automated backup, automatic upgrades
|
||||
@@ -15,4 +15,4 @@ The free self-hosted version drives adoption and trust (you can inspect every li
|
||||
|
||||
Target: 100K subscribers at $15/month average = $18M/yr recurring, near-zero marginal cost per additional subscriber (the symbolic engine is CPU-bound, not per-user metered).
|
||||
|
||||
Combined with [[file:agora-usernames.org][premium usernames]]: $28M/yr from Agora services alone before compute marketplace revenue. The hosted model also creates [[file:infrastructure-lock-in.org][infrastructure lock-in]] as users build their Merkle fact stores on the platform, making migration costly. The AGPL licensing model is described in [[file:licensing.org][Licensing]].
|
||||
Combined with [[file:agora-usernames.org][premium usernames]]: $28M/yr from Agora services alone before [[file:compute-marketplace.org][compute marketplace]] revenue. The hosted model also creates [[file:infrastructure-lock-in.org][infrastructure lock-in]] as users build their Merkle fact stores on the platform, making migration costly. The AGPL licensing model is described in [[file:licensing.org][Licensing]].
|
||||
|
||||
@@ -18,10 +18,10 @@ Run on Linux, use C libraries through CFFI, deliver value without replacing the
|
||||
| Component | Lines | Method | Scale |
|
||||
|----------+-------+--------+-------|
|
||||
| Neurosymbolic core (ACL2 + Screamer + LLM bridge) | ~4,500 | Agent-generated Lisp, human-validated | Weeks — dense, well-bounded, proven approach |
|
||||
| Terminal-based Stoa (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established |
|
||||
| Terminal-based [[file:stoa.org][Stoa]] (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established |
|
||||
| Gate rule SDK + marketplace | ~1,500 | ACL2 gate packages | Weeks — pure symbolic, well-specified |
|
||||
| CFFI wrappers (system, GPU, crypto, storage) | ~2,000 | Thin bindings | Days — mechanical translation |
|
||||
| Verification appliance CLI + Agora namespace | ~1,000 | API surface | Weeks |
|
||||
| [[file:verification-appliance.org][Verification appliance]] CLI + [[file:agora.org][Agora]] namespace | ~1,000 | API surface | Weeks |
|
||||
|
||||
*Total MVP: ~11,000 lines. Timeline: 1-3 months. Human review: ~20 hours.*
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
#+title: Triad — Systemic Effects Over Time
|
||||
#+filetags: :passepartout:strategy:effects:geopolitics:society:
|
||||
|
||||
The [[file:triad-overview.org][triad (Logos + Stoa + Agora)]] is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible.
|
||||
The [[file:triad-overview.org][triad (Logos + [[file:stoa.org][Stoa]] + [[file:agora.org][Agora]])]] is not a product in an existing category. Verified infrastructure is a new category, and every existing category — cloud, AI, OS, social, payments, compliance, governance — eventually migrates into it because the alternative becomes indefensible.
|
||||
|
||||
Using the [[file:orders-of-magnitude-time.org][orders-of-magnitude framework]], the effects cascade across time scales. Each scale is qualitatively different, not just more of the same.
|
||||
|
||||
@@ -19,7 +19,7 @@ The effect compounds: proof repositories accumulate lemma libraries across field
|
||||
|
||||
** Economic: the compliance industry's margins erode
|
||||
|
||||
The first enterprise that replaces a SOC2 audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function).
|
||||
The first enterprise that replaces a [[file:compliance/soc2.org][SOC2]] audit with a gate rule saves $500K and two weeks. The Big Four consulting revenue in GRC (governance, risk, compliance) starts eroding — first at the margins (automated control testing), then structurally (the entire audit function).
|
||||
|
||||
[[file:domain-gate-packages.org][Gate rule packages]] sell to the same CISO who buys audit prep today. The difference: audit prep is a cost center; gate rules are an investment that compounds.
|
||||
|
||||
@@ -33,7 +33,7 @@ A regulation that says "access logs must be tamper-proof" is a negotiation. A ga
|
||||
|
||||
** Technological: AI safety becomes engineering, not policy
|
||||
|
||||
The verified API gateway (captured in [[file:revenue-hub.org]]) proves that AI safety is a /software engineering problem/, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production.
|
||||
The verified API gateway ([[file:revenue-hub.org][revenue hub]]) proves that AI safety is a /software engineering problem/, not a policy problem. Companies don't need AI regulation — they need Passepartout gate rules between the LLM and production.
|
||||
|
||||
This shifts the entire AI safety discourse. The question stops being "what should we ban?" and becomes "what gates should we verify?" Prompt injection, jailbreaks, data leakage, hallucination in critical paths — all become gate rule specifications, not white papers.
|
||||
|
||||
@@ -41,7 +41,7 @@ This shifts the entire AI safety discourse. The question stops being "what shoul
|
||||
|
||||
/I verified it/ replaces /I trust the auditor/. DIDs make platform-owned identity look like a historical anomaly. The [[file:pds-as-a-service.org][PDS model]] makes surveillance advertising technically impossible without the user's active consent gate.
|
||||
|
||||
The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The GDPR model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible.
|
||||
The social contract around data shifts: companies don't own user data because the architecture literally prevents them from accessing it without a permission gate. The [[file:compliance/gdpr.org][GDPR]] model (notice + consent) was a regulation trying to fix bad architecture. The PDS model is architecture that makes bad behaviour impossible.
|
||||
|
||||
** Cultural: verification earns cachet
|
||||
|
||||
@@ -53,11 +53,11 @@ The /move fast and break things/ ethos ages overnight. In the C-suite, saying /w
|
||||
|
||||
** Economic: the verification monopoly
|
||||
|
||||
If every transaction on Agora, every plugin on Stoa, every gate rule on Logos passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[file:verification-monopoly.org]].
|
||||
If every transaction on Agora, every plugin on Stoa, every gate rule on Logos passes through Passepartout's verification, then the early player collects a tax on the entire verified economy. This is the [[file:verification-monopoly.org][verification monopoly]].
|
||||
|
||||
The $960B TAM (from [[file:triad-index.org]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money.
|
||||
The $960B TAM ([[file:triad-index.org][triad index]]) is not aspirational — it is the cost of admission to the verified stack. Every dollar spent on cloud, AI, OS, social media, payments, and compliance eventually flows through the verification layer. The early player does not capture 100% of that, but the spread on even 5-10% is venture-scale money.
|
||||
|
||||
The switching cost to unverified infrastructure becomes infinite. No enterprise can justify / why would we go back to unverified code / once verification is in place. This is the [[file:infrastructure-lock-in.org]].
|
||||
The switching cost to unverified infrastructure becomes infinite. No enterprise can justify / why would we go back to unverified code / once verification is in place. This is the [[file:infrastructure-lock-in.org][infrastructure lock-in]].
|
||||
|
||||
** Geopolitical: compute becomes a strategic asset
|
||||
|
||||
@@ -98,7 +98,7 @@ The frontier shifts. The question is no longer /can we verify this/ but /what ne
|
||||
|
||||
** Economic: the old economy becomes a historical layer
|
||||
|
||||
Proprietary software licensing, cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite.
|
||||
Proprietary software [[file:licensing.org][licensing]], cloud lock-in, compliance consulting, annual audit firms — these are as alien to someone born into the verified era as mainframes and COBOL are to a cloud-native developer. The new economy runs on verified infrastructure where the marginal cost of verification is zero and the switching cost to unverified infrastructure is infinite.
|
||||
|
||||
The insurance industry, which prices based on risk, shifts to pricing based on proof coverage. Companies with full verification pay lower premiums. Companies without it cannot get insured. This is the completion of the feedback loop: verification is not just better engineering — it is a requirement for participation in the formal economy.
|
||||
|
||||
|
||||
@@ -16,5 +16,5 @@ Once instances diverge in both code and knowledge, naive git pull breaks things.
|
||||
**Business model for upgrades:**
|
||||
- Code upgrades: free (AGPL)
|
||||
- Migration scripts: subscription. The verified migration path from current ontology version to new one.
|
||||
- [[file:domain-gate-packages.org][Domain knowledge package upgrades]]: subscription. When HIPAA updates, the healthcare package updates.
|
||||
- [[file:domain-gate-packages.org][Domain knowledge package upgrades]]: subscription. When [[file:compliance/hipaa.org][HIPAA]] updates, the healthcare package updates.
|
||||
- [[file:verification-appliance.org][Verification appliance firmware]]: bundled with hardware. Signed and verified against hardware root of trust.
|
||||
|
||||
Reference in New Issue
Block a user