Architecture outlives implementation vocabulary

Last quarter's stack was a popular agent framework. This quarter it is a vendor orchestration product with a different tool-calling shape. Next quarter a new model family ships with new context limits and new failure modes. Teams that anchored architecture in those words rebuild "the product" every time vocabulary turns over.

White Paper Principle 9 offers a different anchor. Architecture outlives implementation vocabulary. Judgment structure persists: cognitive unit maps, library placement, memory forms, authority boundaries, deterministic gates. Implementation vocabulary is replaceable machinery.

This page is comfort and discipline for teams mid-migration. If contracts are clear, a model swap is remeasurement and substitution. If architecture lived in prompt docs tied to a vendor SDK, migration feels like starting over because it is.

Helpful context: A category, not a mechanism explains why product labels mislead. The model is not the system separates substrate from architecture. Lessons from software architecture draws the parallel to functions settling computation.

What churns versus what persists

Implementation vocabulary includes model brand names, context window sizes, tool-calling syntax, retrieval product labels, and framework class names that appear in import statements. All of it changes on vendor schedules.

Architecture includes the outcome sentence, the judgment map, named cognitive units with decision sentences, library organization, memory form distinctions (six forms of memory), authority diagram, deterministic shell responsibilities, and evaluation identities with promotion rules.

When the Meal Companion moves to a new model generation, the following persist. Decision sentences: JudgeWeeklyVariety still assesses meaningful variation across the week. Closed enforcement: allergy validation remains deterministic code, not prompt hope. Library placement: domain library entries stay in the meal-planning library, judge entries stay in the judge library. Human gates: purchase approval remains human even if proposals improve. Agent goal and loop structure: plan, critique, patch, accept, with review stop conditions.

The following may change as policy or substrate: default model for a given identity version, retrieval mechanics inside a cognitive unit profile, orchestration code details that call declared contracts, wrapper chains tuned for cost or reliability, and prompt wording inside identity versioned with remeasurement. Confusing the second list for the first is how teams lose institutional knowledge every eighteen months.

The judgment map is the asset

Organizational memory often lives in slide decks and demo repos that rot when key people leave. A maintained cognitive unit map tied to suites is a transferable asset.

New engineers learn which judgments exist before they learn which model is fashionable. Incident response starts from named edges and figures, not from grepping chain definitions. Product discussion references AssessMealPracticality instead of "the busy night thing in the big prompt."

Principle 9 is not anti-tooling. Use frameworks when they respect encapsulated contracts. Reject frameworks that require architecture to be expressed only in their native vocabulary with no export path to stable names.

Architecture should outlive implementation vocabulary.

Thoughtware White Paper · Pr. 9

Documentation habits that survive churn

Write outcome and judgment documentation without vendor product names in the primary spec. Reference models in policy tables and version records, not in the definition of what the product is.

Version identity when template bodies or decision sentences change. Track substrate changes on a schedule with remeasurement even when diffs are empty. Evaluation part of architecture makes substrate shifts visible instead of mystical.

Invest in libraries and contracts as core IP. Framework glue belongs at the edges. If removing a vendor SDK deletes the judgment map, the map was never architecture. It was configuration.

What this looks like in practice

A migration project starts from the persisted layer: export the cognitive unit catalog with decision sentences and suite pointers, confirm deterministic shell tests still pass unchanged, remeasure each identity version on labeled cases under the new model pairing, promote or hold library entries based on figures rather than demo sentiment, and update orchestration adapters while call sites still invoke the same contracts.

Tuesday busy-evening behaviour may improve or regress. The team knows which cognitive unit changed behaviour because identity stayed stable. Fixes target AssessMealPracticality v3, not "the new stack."

Contrast with a team whose spec says "LangChain agent with GPT-X." Migration means rewriting prompts embedded in framework tutorials. Allergy logic lives in three chains. Evaluation is anecdotal. Every migration is a rewrite because architecture was never separated from vocabulary.

Relationship to maturity

Maturity moves settled work out of runtime strengthens persistence. Closed work migrates to code. Patterned work migrates to expertise with guards. What remains in runtime deliberation shrinks while names stay stable.

Maturity without stable architecture produces hard-coded shortcuts tied to vendor features. Stable architecture without maturity produces eternal full deliberation paths. Principle 9 and Principle 8 work together across product generations.

Common mistakes

Architecture diagrams that are model logos. Pretty slides with no decision sentences.

Renaming cognitive units every quarter. Identity churn destroys suite history.

Framework-first specs. Judgment map lives only inside vendor UI exports.

Treating prompts as the architecture. Templates are implementation inside identity, versioned and measurable, not the diagram itself.

Migration checklist in prose

Teams mid-migration can answer five questions without opening vendor documentation: What outcome does the product owe? Which named cognitive units own which open decisions? Where does closed work live in code? Which human nodes persist by authority design? Which suite identities must remeasure after substrate change?

If any answer references only a framework class or model nickname, architecture has not yet been extracted. Extraction work belongs in the same program as migration, not after it. Principle 9 saves calendar time when remeasurement plans reference stable names executives already approved.

Product marketing will rename features every quarter. Architecture documentation remains boring on purpose: decision sentences, library placement, authority diagram, promotion rules. Boring documentation survives reorganizations. Clever nicknames do not. When a reorganization happens and the original team disbands, the surviving asset is the cognitive unit catalog with its suite history, not the slide deck that introduced the feature under last quarter's brand name.

Onboarding and executive communication

New hires read judgment maps before SDK tutorials. Maps explain why AssessMealPracticality exists separately from ComposeWeek. SDK tutorials explain how to invoke edges. Reversing the order produces engineers who paste orchestration examples without understanding decision boundaries. Onboarding exercises can trace one household request through named edges without implementing new code. Trace exercises build vocabulary stability across team churn, which is the human benefit of Principle 9 when models and vendors change underneath.

Executives often ask for model upgrades for market positioning. Architecture teams respond with outcome stability stories: same household outcome, same judgment map, remeasured edges, unchanged human gates. That framing reduces fear that migration reopens product definition from zero. When vocabulary churn is external, stable maps also reduce contractor onboarding cost. Vendors rotate. Judgment maps remain.

Pair Principle 9 with category, not mechanism. Category vocabulary survives vendor relabeling. Mechanism vocabulary does not.

What to do next

Document outcomes and cognitive unit maps without vendor product names in primary specs. Version identity when template bodies change and schedule substrate remeasurement when models update. Invest in libraries and contracts rather than in framework-specific glue as core IP. Read maturity notes for what leaves runtime deliberation over time.

When executive pressure arrives to "switch to the new model," respond with a remeasurement plan tied to named identities. That response is Principle 9 in action.

Read next: Maturity moves settled work out of runtime.