diff --git a/ideas/passepartout-economics.org b/ideas/passepartout-economics.org index 4ba8bd7..33eac30 100644 --- a/ideas/passepartout-economics.org +++ b/ideas/passepartout-economics.org @@ -477,6 +477,123 @@ The remaining question is not whether the economics flipped — it's whether anyone builds the bridge from today's AGPL software to tomorrow's verification appliance. Passepartout is that bridge. +** Distribution and lifecycle management + +Passepartout diverges in two independent dimensions across instances: +code (engine, macro layers, skills) and knowledge (gate rules, fact store, +ontology, proof forest, empirical decision history). This creates a +distribution problem no current AI system faces — most agents ship as +static binaries with no per-instance knowledge divergence. + +*** Distribution tiers + +Code only (AGPL repo — GitHub) +- The core engine, ACL2 macro layers as skills, generic gate rules. +- No domain knowledge, no pre-seeded fact store, no proof forest. +- User bootstraps from scratch — the system learns from their gate outcomes. +- Audience: hobbyists, researchers, early adopters willing to invest time. + +Code + basic knowledge (commercial data package) +- Pre-seeded fact store for a domain (healthcare, finance, infrastructure). +- Curated gate rules, ontology categories, and initial ACL2 theorem set. +- The buyer gets sufficiency faster — weeks instead of months to reach + the Phase 4 flip in their domain. +- Audience: enterprises that want fast deployment without bootstrapping. + +Code + knowledge + verification appliance (hardware product) +- RISC-V + Lisp μcode on FPGA or custom ASIC. +- Pre-loaded with full domain-specific knowledge package. +- Hardened, certified, no-cloud, tamper-proof HSM root of trust. +- Audience: regulated industries that need provable compliance out of + the box. + +*** The upgrade problem + +Once instances diverge in both code and knowledge, a naive `git pull` +breaks things: + +1. A new macro layer expects a fact structure the old store doesn't have + → re-verification fails, system degrades to pre-macro state + +2. Two instances of the same version develop different ontologies + → a shared gate rule package produces different outcomes on each + +3. Knowledge learned in v1 must be verified against v2's code + → old facts carry `:ontology-version`, ACL2 checks they're still + consistent under the new code's rules + +4. A security patch changes the gate stack + → all existing gate-outcome facts must be re-verified against the + new gate vectors + +*** How Passepartout's architecture handles this + +The architecture already has the primitives for safe upgrades: + +- **Ontology versioning (Phase 5).** Every fact stores the ontology + version at assertion. On upgrade, facts with old versions are flagged + for re-verification. ACL2 checks consistency against new code. Facts + that survive are promoted to the new version. Facts that fail are + flagged for review. + +- **Degradation, not crash.** If an upgrade breaks the fact store, the + system degrades to the pre-macro symbolic state (hash-table fallback + for VivaceGraph, text-scan fallback for Screamer). It still works — + it just can't prove as much. The TUI displays: "Symbolic index: legacy + mode. 2,134 facts pending re-verification under new ontology." + +- **Reversible upgrades (Phase 0 undo).** Every upgrade produces a + Merkle snapshot before applying. If re-verification fails, the system + rolls back to the pre-upgrade state. The failed upgrade becomes a + memory-object with `:provenance :failed-upgrade` — empirical data + for the next upgrade attempt. + +- **Delta distribution.** Upgrades are delivered as diffs against the + current ontology version, not full replacements. A code upgrade ships + with a migration script: "This version changes the gate rule structure + from (action pattern) to (action pattern context meta). Here is the + automated migration for your existing gate rules." The user's + empirical data is preserved across the migration. + +*** The real challenge: divergence of empirical knowledge + +The hardest upgrade is not code — it's the fact store. Two instances +that started from the same code but served different users for a year +have diverged ontologies. Instance A's gate rules encode "emergency +restart = docker compose restart" (hospital IT). Instance B's gate rules +encode "emergency restart = emergency_shutdown.py" (factory floor). + +A code upgrade that changes how emergency restarts are processed cannot +be safely applied to both instances with the same migration. The +migration must be per-instance, tested against the instance's specific +facts. + +The pattern that solves this: **the upgrade is itself verified by the +upgraded system before committing.** The distributor ships: "Here is +the new `emergency-restart` gate vector. Run it against your existing +gate rules. ACL2 will report which rules are compatible and which need +human review." The instance operator reviews only the incompatible +subset. + +This is slower than `git pull` but avoids the catastrophe of a silent +incompatibility. An enterprise running Passepartout in a compliance +context would not accept an unverified upgrade anyway. + +*** The business model for upgrades + +- Code upgrades: free (AGPL). Core engine improvements benefit everyone. +- Migration scripts: subscription. The instance operator pays for the + verified migration path from their current ontology version to the + new one. The migration script is generated by running the new code + against the instance's fact store in a sandbox. +- Domain knowledge package upgrades: subscription. When HIPAA updates, + the healthcare gate rule package updates. The new rules are verified + against the instance's existing fact store before shipping. +- Verification appliance firmware: bundled with hardware. The Lisp + Machine's microcode is updated as the engine evolves. The update is + signed and verified against the hardware root of trust before + applying. + A software ecosystem changing hardware economics has never happened before. Passepartout's most realistic path: verification appliances for regulated industries — RISC-V cores with Lisp microcode on FPGA, sold as hardened