distribution: tiers, upgrades, and the divergence problem

Three distribution tiers: code-only (AGPL), code+knowledge (commercial
data package), code+knowledge+hardware (verification appliance).

The upgrade challenge: instances diverge in both code and knowledge.
A 'git pull' breaks because new code expects fact structures the old
store doesn't have. Solved by:
- Ontology versioning flags old facts for re-verification
- Degradation to fallback mode, not crash
- Reversible upgrades via Merkle snapshots
- Delta distribution (diffs against current ontology version)
- Per-instance verified migration (run new code against old facts in
  sandbox; ACL2 reports compatibility; operator reviews only failures)

Business model: code free, migration scripts subscription, domain
knowledge packages subscription, firmware bundled with hardware.

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