How we update every connected document and system.

1. Name the trigger using the catalog below (algorithm change, schema change, pricing change, strategic pivot, IP boundary change, new partner, regulatory update, lessons-learned).
2. Pull the affected docs from the Meta-Architecture matrix. Filter by ipLayer, systemLayer, and methodologyRole.
3. Re-classify if needed. A pricing change might bump a doc from internal → partner audience. A new algorithm version might bump from L3 → L4.

The cascade matrix (further down this page) maps "if X changes, then Y must change too". Walking it is how you avoid the classic failure mode — updating the spec but forgetting the runbook, or updating the runbook but forgetting the investor narrative.

Output: a write list of every doc, system, scenario, schema, and external surface that needs touching.

• Architecture docs: semver. MAJOR for breaking changes (schema migration required), MINOR for additive features, PATCH for clarifications. Filename = BA-Whatever-Architecture-v1.2.html.
• Strategy/narrative docs: date stamp. 2026-05-31 in filename when the version of record changes.
• Algorithm/IP docs: semver + ledger entry. Add to Master-Algorithm-Design-Doc change ledger.
• Sprint plans: rename old to -completed, archive into Archive/. Never overwrite.
• The rule: every superseded file moves to an Archive/ subfolder within the same topic directory. No deletes, ever.

Order of operation always: specification → implementation → operations → narrative → evidence. Updating downstream artifacts before the spec is the bug pattern that produces silent drift.

Examples:

• Algorithm change: Update Master Algorithm Design Doc before the LESRI Worker code and any Supabase configuration tables (thresholds, weights, lookup rows) that the Worker reads from.
• Schema change: Update ba-database-schema.sql before migration scripts, RLS policies, Worker endpoints.
• Pricing change: Update project_unit_economics_tiered_pricing memory before pro forma, investor deck, or sales materials.

1. Worker code & Supabase schema/config: write migration; update Worker handlers and types; deploy to staging; verify; deploy to prod. The Worker is the single source of computation — LESRI, phi thresholds, ABC opt, Fibonacci progression, Golden Ratio scaling, and the prescription/AI-agent endpoints all live here.
2. Make.com scenarios (historical / selective): Make is no longer a primary orchestration layer under V2. The LESRI-Compute and AUTO-RX1 scenarios are archived. Any remaining scenario is retained only after per-scenario cost analysis confirms it's worth keeping; edit module-by-module when retained, and do not duplicate scenarios as backup.
3. SmartSuite operational mirror: SmartSuite holds no math and no algorithm logic under V2 — it is a one-way operational mirror fed by the Worker (F.32 prescription mirror is the canonical push direction). When the mirror's field shapes themselves must change, always script field/table changes from 01-SCRIPTS/ using python3. Never manual entry unless the API can't do it.
4. Runbooks: update step numbers, screenshots, expected outputs. Update the dashboard execution runbook if applicable.

The order here protects IP layer separation. Under V2 canon, IP layers are resolved against the kb_ip_layers lookup in Supabase — a four-tier model that replaces the prior L1-L3 SmartSuite-internal model:

• public: marketing site, blog, social. Generic functional descriptions only. No vendor brands. No trade-secret detail.
• internal: BA team-facing operational documentation, runbooks, and partner-onboarding materials. Apply post-NDA detail rules for partner-facing surfaces. Schools see prevention story; franchisees see opex model; investors see TAM/SAM/SOM.
• restricted: full methodology detail and proprietary references. Lives in the Module 13 knowledge base (Supabase kb_* tables) and in Worker code — not in SmartSuite tasks/planners, which are mirror-only under V2.
• trade_secret: never publish externally. Algorithm internals, threshold values, composition functions. Watermark + copy protection. Ledger entry of every external view.

Use the verification checklist below. Anything unchecked is a half-finished change. Half-finished changes are the source of drift.

• Internal: update MEMORY.md with the new fact, decision, or deprecation.
• Investor: only if material to the thesis (algorithm pivot, pricing pivot, capital plan change). Use the same voice as the investor doc suite.
• Partner: if the change affects their experience or contract (pricing, methodology, capacity).
• Public: only after all L2/L3/L4 propagation is verified. Public is always last.

Stop. Do not propagate further. If the change is mid-cascade, pause Make.com scenarios that would touch the affected layer. Disable the affected Worker route if necessary.

Copy the archived predecessor back to its canonical location with a -restored-YYYYMMDD suffix. Do not overwrite the failed new version — archive that too with a -failed-YYYYMMDD suffix. Both versions coexist for forensic review.

End-to-end (V2): assessment intake → LESRI Worker compute → Supabase row write → trigger-driven SmartSuite mirror (F.32) → dashboard read → Worker prescription endpoint output. Verify on Justin Wallace test record first, then any other BETA athletes.

Write a feedback memory entry naming what failed, why it failed, and the rule going forward. Failure is data; it makes the methodology better.