blueprint chapterThe Codices

Codex 0 · Chapter 21 — Institutional Memory and the Institutional Lifecycle

Chapter 21 of the institutional specification.

Authority rank
2
Version
v2.0
Adopted
unrecorded
Held by
Stewardship Office
System
SYS-03

Source · docs/codices/CODEX-0/21-memory-and-lifecycle.md · registered by rule

Specifies what Anabasis remembers permanently, in what form a decision is recorded, the fourteen stages a piece of work moves through from discovery to retirement, and which questions the institution's accumulated data may answer, at what resolution, and to whom.

21.0 Purpose

21.0.1 An organization does not fail because it lacks information. It fails because the information it had is gone: the reasoning behind a decision leaves with the people who made it, the record of what was tried is never written down, and each generation re-litigates choices the last generation already settled. Over the hundred-year horizon of Codex 1 Article VII, this is the dominant risk to the institution's competence, not a secondary concern.

21.0.2 This chapter fixes three things against that risk: a memory layer that outlives every person who contributes to it (§21.2), a decision-record form adequate to explain a past choice to someone who was not there (§21.3), and a lifecycle that gives every piece of work — a program, a system, a partnership, a Registry entry — an honest account of what stage it is in and how it ends (§21.4). It closes with the discipline that keeps accumulated institutional knowledge inside the privacy doctrine rather than becoming a surveillance instrument (§21.5).

21.0.3 This chapter amends the decision-record procedure of Codex 9 (§21.3) and is read alongside Chapter 06 (the Knowledge Graph, which is a different layer: capability structure, not institutional acts) and Chapter 16 (Reporting, whose aggregation thresholds this chapter inherits rather than restates).

21.1 Scope and non-scope

21.1.1 In scope: what the institutional memory layer holds and how it is written and preserved (§21.2); the decision-record form and its reconciliation with existing records (§21.3); the fourteen-stage lifecycle and its mapping to Registry status (§21.4); and the classification of institutional-intelligence questions the accumulated record may or may not answer (§21.5).

21.1.2 Out of scope: the Knowledge Graph's node and edge schema (Chapter 06), which models capability structure, not institutional acts; the annual report's contents and cadence (Chapter 16), which this chapter's memory layer feeds but does not replace; the amendment procedure itself (Codex 9), which this chapter amends only at the decision-record form (§21.3); and the technical storage mechanism for any of the above, which is an engineering concern (Chapter 17) once this chapter's obligations are fixed.

21.1.3 This chapter governs institutional acts: things a decision-making body, an author, or an owner did in an institutional capacity and that other people are entitled to rely on. It does not govern, and explicitly excludes, personal activity, private deliberation, and anything a person did that was not itself an institutional act (§21.2.6).

21.2 The institutional memory layer

21.2.1 What must be preserved permanently and searchably

21.2.1.1 The following are preserved permanently, in full, and are searchable by every role entitled to see them:

  1. 1Every Codex and every Standard, at every version, including superseded text (§21.2.3).
  2. 2Every procedure that governs how work is done (workflows, Chapter 09; the amendment procedure, Codex 9; the Standards' conformance checklists).
  3. 3Every decision record (§21.3), at every institutional decision-making body.
  4. 4Every research paper and index published by Research Institute (ENT-13, ENT-14).
  5. 5Every product, program, or curriculum shipped, at the version it shipped.
  6. 6Every lesson — in the plain sense of "what did we learn from this" — recorded as part of a decision record's result field (§21.3.9) or a Registry entry's retirement account (§21.4.14).
  7. 7Every financial model used to make a capital decision, at the version relied upon.
  8. 8Every partnership and its governing agreement's institutional terms (not its confidential commercial detail, which is retained under Chapter 15's own rules but is not part of the searchable memory layer's public text).
  9. 9The record of every decision made by a decision-making body (Codex 9's Bodies), meaning the decision itself and its record, never the deliberation that produced it (§21.2.6).
  10. 10Every annual report (Chapter 16 §16.5), at the version published.

21.2.1.2 "Searchable" means findable by a person entitled to see it without requiring them to know in advance which year, division, or system produced it. A memory layer that only the person who wrote something can locate again is not a memory layer; it is a personal archive.

21.2.2 Append-only

21.2.2.1 The memory layer is append-only. Nothing preserved under §21.2.1 is deleted because it is old, wrong, embarrassing, or superseded.

21.2.2.2 A superseded item is struck in place and carries a pointer to the decision record, Codex clause, or later version that replaced it (§0.2's citation permanence is the model this chapter generalizes). A reader who lands on the superseded item is one link away from the current position.

21.2.3.3 Deletion from the memory layer is permitted only where a superior legal or Codex obligation requires it (for example, severance of personal content on departure under §04.8.4), and even then the fact that something existed and was removed, and why, is itself retained.

21.2.3 Permanence beyond any person

21.2.3.1 Preservation under this section does not depend on any individual remaining at the institution. A record authored, decided, or owned by a person who has since departed remains fully preserved, fully attributed, and fully searchable exactly as it would be were they still present.

21.2.3.2 An owner's departure is a Registry field to be reassigned (§0.6.5); it is never grounds to remove, thin, or re-attribute the historical record of what that person decided or authored while they held the role.

21.2.4 Institutional acts, not personal activity

21.2.4.1 The memory layer records what the institution did — decided, published, shipped, agreed, taught, learned — in a form another person could act on decades later. It does not record who did what, minute by minute, in the course of doing it. The distinction is the same one Chapter 16 draws between capability movement and engagement (§16.2.1.2): the layer measures the institutional record, not the labor that produced it.

21.2.5 What is deliberately excluded

21.2.5.1 The following are never entered into the institutional memory layer, regardless of how useful they might later seem:

  1. 1Private drafts — a document not yet reviewed, approved, or adopted by the body that owns that kind of decision. A draft belongs to its author's private working state until it is either adopted (and becomes the institutional act, §21.2.1) or abandoned (and is simply not preserved).
  2. 2AI conversation transcripts — a person's exchange with an agent (Chapter 13) working through a problem, drafting language, or asking questions. The agent's output, if adopted into an institutional act, is preserved as that act; the conversation that produced it is not.
  3. 3Personal notes — a person's own working notes, however substantive, unless and until that person publishes them through a reviewed channel that makes them an institutional act (a publication, a decision record, a curriculum unit).
  4. 4Meeting content that is not a decision of a decision-making body — discussion, disagreement, brainstorming, and the back-and-forth that precedes a decision. Only the decision itself, in the form of §21.3, is preserved.

21.2.5.2 The reason is stated plainly: an institution that preserves what people said in private, in draft, or in the course of thinking something through has stopped keeping institutional memory and started keeping surveillance. Codex 1 Article V's prohibition on optimizing for what people do rather than what they demonstrate (§16.2.1.2) applies with equal force here — the memory layer exists to answer "what did the institution decide and why," never "what was everyone doing while they decided it."

21.2.5.3 This exclusion is symmetric with §06.9's prohibition on private and engagement-scoped content becoming a graph node: the same organizing principle — institution-wide, permanent, queryable structures never hold personal or deliberative content — governs both layers, applied here to institutional acts rather than to capability structure.

21.2.6 Worked example — the 2034 executive

21.2.6.1 An executive in 2034 asks: "why did we change the certification model?" The memory layer must return, in full and without requiring special access beyond the executive's ordinary role scope:

  1. 1The original proposal that initiated the change, naming who proposed it and to which body.
  2. 2The evidence reviewed in reaching the decision (§21.3.4).
  3. 3The review record — which body reviewed it, under which decision right (Codex 9's table), and its assent or veto.
  4. 4The implementation plan adopted, including its owner and timeline.
  5. 5The outcome metrics defined for the change (§21.3.5) and, if the review date has passed, the recorded result (§21.3.9).
  6. 6Every later revision of the model, each connected to the original by the same superseding-pointer discipline as a Codex clause (§0.2), so the 2034 executive can trace the full chain from the original decision to the model currently in force.

21.2.6.2 The memory layer must not return who said what in the meeting where the change was discussed, whose private notes argued against it, or any AI-assisted drafting that preceded the final proposal. Those never entered the layer (§21.2.5), and the 2034 executive has no more claim to them than a member of the public.

21.3 The nine-field decision record

21.3.1 This section amends the decision-record procedure of Codex 9 (DECISIONS/, step 2 of the amendment procedure). Every decision record, whether it amends a Codex or records a decision of any other decision-making body named in Codex 9, is written in nine fields. A record missing a field is incomplete and does not satisfy Codex 9's requirement that a decision be recorded.

21.3.2 Decision. A single, plainly stated sentence naming what was decided. Adequate: "The certification model moves from a single capstone assessment to three staged assessments, effective the next enrolment cohort." Inadequate: a restatement of the problem, a description of the process, or a decision stated as a direction of travel ("we will explore staged assessment") rather than a decision.

21.3.3 Reasoning. The argument connecting the evidence to the decision, in enough detail that a reader who disagrees with the decision can identify exactly which premise they dispute. Adequate: names the specific problem the prior state caused and why the chosen decision addresses it. Inadequate: an assertion of benefit with no chain from evidence to conclusion ("this will improve outcomes").

21.3.4 Alternatives considered. Every option seriously weighed, including the option of doing nothing where that was genuinely on the table. This field carries the first hard rule (§21.3.10).

21.3.5 Evidence reviewed. The specific data, research, prior decision records, or reports the decision drew on, cited by name or ID (a Chapter 16 metric, a Publication ID, a prior decision record number) rather than described vaguely. Adequate: "Capability movement rate for the single-capstone cohort, 2031–2033 (§16.3), and DIV-01's faculty judgement consistency metric for the same period." Inadequate: "based on feedback and experience."

21.3.6 Expected outcomes. What the decision is predicted to change, stated as something that can later be checked true or false against a named metric or observable condition. Adequate: "capability movement rate for certified cohorts increases; assessment pass integrity (§16.4.1) does not decline." Inadequate: an outcome with no way to later confirm or disconfirm it ("a better experience for scholars").

21.3.7 Owner. The named person or role accountable for implementation and for writing the result field at the review date. A decision record without a named owner has no one accountable for §21.3.9 and is incomplete.

21.3.8 Date. The date the decision was made and, where different, the date it takes effect.

21.3.9 Review schedule. A specific future date, not a vague interval, by which the result field must be written. "Reviewed periodically" is not a review schedule.

21.3.10 Result. Written at the review date, stating plainly what actually happened against the expected outcomes (§21.3.6), whether the decision achieved what it intended, was neutral, or made things worse. This field carries the second hard rule (§21.3.12).

21.3.11 Hard rule one — a genuine alternative

21.3.11.1 The alternatives-considered field must name at least one alternative that was genuinely viable — an option a reasonable, informed party could have chosen and that was rejected on stated grounds, not a strawman invented to make the chosen decision look inevitable.

21.3.11.2 A decision record with no viable alternative recorded is incomplete, regardless of how thorough its other fields are. A record consisting only of "we considered doing nothing, and rejected it" where doing something different was plainly also available fails this rule.

21.3.12 Hard rule two — the result is written on schedule, whatever it says

21.3.12.1 The result field is written at the review date whether or not it flatters the decision. A decision that failed is recorded as having failed, in the same plain terms Chapter 16 §16.2.3 requires of a metric: the honest reading is the one recorded, not the one that avoids an uncomfortable conclusion.

21.3.12.2 A decision record whose review date has passed and whose result field is unwritten is overdue and is listed as overdue wherever decision records are surfaced (the Steward's review, §04.4.17; the annual report's decision-record accounting, §16.5.2.1(5)). It is not silently left blank.

21.3.12.3 An unwritten result is named here as the single most common failure of institutional memory: an organization is far more likely to forget to check whether a decision worked than to fail to make the decision at all. The overdue flag exists specifically because this failure mode is common enough to require a standing, visible check rather than trust that it will be caught informally.

21.3.13 Reconciling decision records 0001–0005

21.3.13.1 DECISIONS/0001 through 0005 predate the nine-field form and do not carry a result field. They are not retroactively rewritten to invent a result field that was never contemporaneously reasoned through — inventing a result after the fact would itself violate the honesty this section requires.

21.3.13.2 Instead, each of 00010005 is assigned a review schedule at the next occasion its subject is materially revisited (an amendment to the Codex or Standard it established, or the next annual Codex review cycle under Codex 9's "Review cadence," whichever comes first), and its result field is appended at that time, dated to when it was actually written, not backdated to the original decision date.

21.3.13.3 Until a result is appended under §21.3.13.2, 00010005 are marked in the decision-record index as pre-form, not overdue — the overdue status (§21.3.12.2) applies only to records created under this section with a missed review schedule of their own.

21.4 The fourteen-stage lifecycle

21.4.1 Every piece of institutional work — a product, a system, a program, a partnership, a piece of research, a Registry entry — moves through the same named stages. A stage may be short, but it is never skipped: a Registry entry that claims to be past a stage without having produced that stage's output and passed its gate is misrepresenting its own state, which §0.5 forbids.

21.4.2 The thirteen stages that carry work from an unmet need to an institutionalized capability, each with what it produces and the gate that ends it:

  1. 1Discover — produces a named problem or opportunity, evidenced rather than assumed. Gate: the problem is stated in terms a second person can verify is real (a metric, a request, an observed gap), not merely asserted.
  2. 2Research — produces a body of evidence about the problem and what is known to address it (Chapter 06 §06.8.3's research-linkage discipline applies here). Gate: the evidence is reviewed and cited, not anecdotal.
  3. 3Design — produces a specific proposed approach, including what it will and will not do. Gate: the design names its Registry entry per §0.6.1, with all eight fields answered, before implementation.
  4. 4Prototype — produces a working, limited-scope version sufficient to test the design's core assumption. Gate: the assumption is either confirmed or falsified with evidence, not opinion.
  5. 5Validate — produces evidence that the prototype, at small scale, produces the intended effect for real people or real work. Gate: a decision record (§21.3) naming the validation result and the decision to proceed, adjust, or stop.
  6. 6Build — produces the full, production version. Gate: passes STD-Q conformance (Standards §5.1) before it ships.
  7. 7Deploy — produces the thing in service, reaching its intended users. Gate: the Registry status moves to built or partial with named gaps (§0.6.5).
  8. 8Measure — produces the metrics defined for it (Chapter 16), on the cadence that chapter fixes. Gate: at least one full reporting cycle has run and produced a real figure, not a projection.
  9. 9Improve — produces revisions in response to what measurement showed. Gate: each material revision is its own decision record or, for a meaning-changing revision, a versioned change under the same discipline as Chapter 06 §06.6.1.
  10. 10Standardize — produces a Standard, procedure, or documented pattern that lets the capability be repeated correctly by someone who did not build the original. Gate: a second team or person can execute the pattern from the documentation alone, without asking the original author.
  11. 11Teach — produces the capability transferred into curriculum, onboarding, or another durable teaching form, so it survives the departure of everyone who built it. Gate: someone who was not present for stages 1–9 has demonstrably learned it from the teaching artifact alone.
  12. 12Scale — produces the capability operating at multiples of its original scope without a proportional increase in the people required to run it (Chapter 18's expansion doctrine governs the mechanics). Gate: the scale-up is evidenced by the relevant Chapter 16 metric, not asserted.
  13. 13Preserve — produces the memory-layer entry required by §21.2.1: the thing's history, decisions, and lessons are searchable and permanent. Gate: the entry exists and is findable by a person who was not involved in building the thing.

21.4.3 Retire or Supersede is the fourteenth stage, added to the thirteen above. It produces a plain account of why the thing ended or was replaced, what replaced it if anything, and what of it is preserved (per §21.2.2's struck-in-place rule) versus decommissioned. Gate: the Registry entry is marked ended, with a pointer to what superseded it if applicable, rather than left showing a status that no longer describes reality.

21.4.4 An institution that has thirteen stages for starting things and none for ending them accumulates: systems nobody uses, commitments nobody reviews, programs that outlived their purpose kept alive by the absence of a mechanism to end them rather than by continuing merit. That accumulation compounds until it consumes the capacity that should go to new work, which is its own form of institutional collapse. The fourteenth stage exists because ending things correctly is as much a discipline as starting them.

21.4.5 The lifecycle stages map onto the Registry's three statuses (reserved, partial, built, per Codex 0 §99) as follows:

Registry statusLifecycle stages it covers
reservedDiscover, Research, Design
partialPrototype, Validate, Build, Deploy, Measure, Improve
builtStandardize, Teach, Scale, Preserve

21.4.6 This mapping lets a Registry entry carry a stage in addition to a status: two partial entries are not equivalent if one is at Build and the other at Improve, and the Registry should name the stage, not only the status, wherever precision matters to a reader deciding whether to depend on the entry.

21.4.7 A Registry entry marked built that has not reached Standardize and Teach is overclaiming: it may function, but the institution has not yet secured the capability against the departure of the people who built it, which is the entire purpose of those two stages (§21.4.8).

21.4.8 Standardize and Teach are named here as the two stages most often skipped, because skipping them produces no immediate visible failure — the thing keeps working as long as its original builders remain. They are also the two stages that make capability compound rather than merely accumulate: a capability that has been standardized and taught can be repeated and built upon by someone new; a capability that has not is a dependency on specific people, which is precisely the fragility Chapter 18's expansion doctrine and this chapter's memory layer both exist to remove.

21.4.9 Preserve (§21.4.2.13) is satisfied specifically by the existence of a memory-layer entry under §21.2.1 — not by the existence of the thing itself, and not by a Registry row alone. A Registry entry with no corresponding decision record, published account, or preserved history has not completed Preserve regardless of how long it has been in service.

21.5 Institutional intelligence — the question classification

21.5.1 The institution accumulates, across the memory layer, the Knowledge Graph, and the entities of Chapter 07, more than enough data to answer questions no single record was designed to answer. The institution is meant to become progressively wiser as this accumulation grows — that is a stated purpose of preserving the record at all (§21.0.1) — but only within the privacy doctrine already established across Chapter 04 (visibility contracts), Chapter 06 (§06.9, what may never become a node), and Chapter 16 (§16.7, aggregation thresholds). This section classifies the questions such accumulated intelligence is likely to be asked, so that a new question, not listed here, can be classified by the same rule rather than argued afresh each time.

21.5.2 The governing rule. A question about people is classified by asking, in order: (1) does answering it require resolving to a named individual, or does an aggregate answer serve the purpose? (2) if it must resolve to an individual, is that individual the subject of the question, another party being told something about the subject, or neither? (3) does the answer, in the wrong hands, enable ranking, sorting, or surveillance of people against each other, which §04.9.4 already forbids showing? A question that can be answered in aggregate, above the Chapter 16 threshold, without naming anyone, is answered that way even if a named answer would be easier to produce. A question that cannot be answered without exposing one person's standing to another, or without becoming a ranking, is refused regardless of its institutional usefulness.

21.5.3 Classifications.

  • PERMITTED — answerable about named individuals, to roles whose scope already covers that individual under Chapter 04's visibility contract.
  • AGGREGATE ONLY — answerable only above the Chapter 16 §16.7 aggregation threshold, never resolving to a named person, regardless of who is asking.
  • SELF ONLY — answerable to the person themselves, and to nobody else without that person's specific, revocable consent (§04.7).
  • REFUSED — never answered, at any resolution, to anyone, for a stated reason.

21.5.4 The twelve questions, classified:

  1. 1Who needs help. PERMITTED, to the specific role already scoped to that person (a mentor within the mentoring scope, §04.4.4; a faculty member within their assignment, §04.4.5) — because identifying that a specific scholar within an existing relationship needs help is the ordinary function of that relationship, not a new surveillance use. Never permitted to a role with no existing scope over that person.
  2. 2Who should meet each other. PERMITTED as a suggestion delivered to each named person, never as a disclosed pairing or ranking visible to a third party. This is matching, and §21.5.6 states the governing rule for it separately.
  3. 3Which companies need advisors. AGGREGATE ONLY where the question is about the state of the client base generally; PERMITTED, naming a specific organization, to the advisor or division lead already scoped to that engagement (§04.4.7, §04.4.15) — an organization is not an individual person, and Chapter 04's protections attach to people, but a specific company's need is still disclosed only within its existing engagement scope, not broadcast institution-wide.
  4. 4Which students are becoming exceptional. REFUSED as a general, institution-wide answer, because it is a ranking of people against each other, which §04.9.4 forbids showing regardless of audience. A faculty member's own judgement about their own assigned students, formed through ordinary teaching, is not this question; it is PERMITTED within that scope (§04.4.5).
  5. 5Which lessons create the best outcomes. AGGREGATE ONLY. This is a question about curriculum content and its aggregate capability movement (§16.3), never about which students the lesson served; it does not require or permit resolving to any individual.
  6. 6Which mentors have the highest impact. AGGREGATE ONLY, and reported for capacity and program-quality purposes only, following the same rule Chapter 16 already applies to advisor utilization (§16.4.2): never as an individual performance ranking visible to anyone but the mentor themselves reviewing their own record (SELF ONLY for the individual mentor's own figure).
  7. 7Which founders are investment-ready. PERMITTED, to the investor or division role already scoped to that founder's venture (§04.4.10, §04.4.11), because readiness assessment is the ordinary function of the venture pipeline (WF-04); REFUSED as a cross-portfolio ranking shown to investors generally, since that is the ranking §04.9.4 forbids applied to founders instead of scholars.
  8. 8Which research should become curriculum. AGGREGATE AND EDITORIAL — treated as PERMITTED, because it concerns publications and capability structure (Chapter 06 §06.8.3), not identifiable people, and is the ordinary function of Research-to-curriculum workflow (WF-03).
  9. 9Which companies should become case studies. PERMITTED, subject to the organization's own consent to be named (the same consent discipline §04.7 applies to individuals extends to an organization's own commercially sensitive material by contract, Chapter 15) — this is an editorial decision about a willing subject, not a use of data against an unwilling one.
  10. 10Where is capability increasing. AGGREGATE ONLY — this is the institutional metric set of Chapter 16 §16.3 by another name, and is reported exactly as that chapter already specifies, never resolved below its threshold.
  11. 11Where is capability declining. AGGREGATE ONLY, for the same reason as (10), and reported with the same honesty obligation as an unflattering annual-report figure (§16.2.3.2): a decline is published, not obscured because it is a use of the word "intelligence" rather than a metric.
  12. 12What systems are underperforming. AGGREGATE ONLY, at the level of systems and Registry entries (Chapter 16 §16.4.5's platform reliability metric is the model), never at the level of the individual engineer or team member who built or operates the system — an underperforming system is not evidence for a ranking of the people who built it, and is not used as one.
  13. 13What opportunities are emerging. AGGREGATE ONLY, drawn from Chapter 06's research-linkage and Chapter 16's outcome metrics; this question is answered from institutional and market pattern data, never by surfacing a specific person's private goal, plan, or engagement content as the "opportunity."

21.5.5 Where a question above is classified AGGREGATE ONLY but a role believes it needs a named answer for a specific, legitimate purpose already covered by an existing scope (for example, an advisor needing to know which of their own assigned clients needs help, item 1), the named answer is available through that existing scope directly — the AGGREGATE ONLY classification governs the general, cross-scope form of the question, not a scoped party's ordinary access to their own assigned relationships.

21.5.6 Matching is an offer, never an assignment. Where accumulated intelligence produces a suggestion that two people meet, be matched, or be introduced (item 2, and any future question of the same shape), the suggestion is delivered to each named person as something they may accept or decline. It is never delivered as an assignment they must act on, and the fact, existence, or ranking of a match is never disclosed to anyone but the matched parties themselves — not to a manager, a division lead, or an executive reviewing "match quality" in aggregate by name. Aggregate match-quality metrics (does matching work at all, institution-wide) are permitted under the same AGGREGATE ONLY discipline as any other institutional metric; a disclosed ranking of who was matched with whom is not.

21.5.7 No answer is for sale. No answer to any question in §21.5.4, at any classification, is sold, licensed, or otherwise transferred for commercial consideration, per Codex 1's prohibition on monetizing member data (Codex 1, Article V; §04.7.4's consent requirement for AI training draws on the same prohibition). An enterprise or partner may receive an AGGREGATE ONLY answer about its own cohort under the reporting scope already fixed by Chapter 16 §16.8, as a service delivered under its existing agreement — that is reporting, not the sale of institutional intelligence, and does not create a general exception to this rule.

21.6 Interfaces

21.6.1 The memory layer (§21.2) is served by the reporting boundary already named in the Registry — Reporting & Analytics (API-10) for aggregate and institutional-set material, and the Audit boundary (API-11) for the access-transparency guarantees Chapter 04 already promises each person (§04.2.4, §04.8.5).

21.6.2 Decision records under §21.3 are written into DECISIONS/ per Codex 9's existing amendment procedure; this chapter's nine-field form and its two hard rules apply to every record from this chapter's adoption forward, and to 00010005 under the reconciliation rule of §21.3.13.

21.6.3 The lifecycle stages of §21.4 attach to Registry entries (Codex 0 Appendix 99) as an additional, optional stage field alongside the existing status field; no Registry schema change is required beyond adding that field.

21.6.4 The question classifications of §21.5 govern any AI agent (Chapter 13, AGT-05 Analyst and AGT-12 Knowledge Assistant in particular) or dashboard (Chapter 12) whose function is to surface a pattern across more than one person's record; such a system is built to enforce the classification, not merely to be used consistently with it.

21.7 Invariants

21.7.1 Nothing preserved under §21.2.1 is deleted while any part of the institution could still need to trace how a current state came to be, except under the narrow legal-severance exception of §21.2.2.3.

21.7.2 A superseded memory-layer item always carries a resolvable pointer to what replaced it.

21.7.3 Every decision record carries all nine fields of §21.3, including at least one genuine alternative.

21.7.4 A decision record's review date, once passed, always shows either a written result or an overdue flag — never silence.

21.7.5 No lifecycle stage is skipped in a Registry entry's claimed history; a claimed stage always has produced that stage's output and passed its gate.

21.7.6 No question classified AGGREGATE ONLY, SELF ONLY, or REFUSED in §21.5.4 is ever answered at a resolution or to an audience its classification forbids, regardless of who is asking or how the question is worded.

21.8 Prohibitions

21.8.1 No private draft, AI conversation transcript, personal note, or non-decision meeting content is entered into the institutional memory layer (§21.2.5).

21.8.2 No deletion from the memory layer outside the narrow exception of §21.2.2.3.

21.8.3 No decision record without a named, viable alternative (§21.3.11).

21.8.4 No decision record's result field left silently unwritten past its review date without the overdue flag (§21.3.12.2).

21.8.5 No retroactive invention of a result for 00010005 or any other pre-form record (§21.3.13.1).

21.8.6 No Registry entry claims built status, or a lifecycle stage beyond one it has actually completed, without having produced that stage's output and passed its gate.

21.8.7 No disclosed ranking of people against each other, produced from institutional intelligence, shown to anyone (§21.5.4 item 4, item 6, item 7; §21.5.6).

21.8.8 No sale of any answer to any question in §21.5.4, at any classification (§21.5.7).

21.8.9 No AGGREGATE ONLY question answered at individual resolution to circumvent the Chapter 16 threshold by relabeling it "institutional intelligence" rather than "reporting."

21.9 Open questions

21.9.1 The specific technical retention and search implementation of the memory layer — whether it is a distinct store or a view composed from existing entities (Chapter 07), decision records, and Registry data — is undecided and reserved for Chapter 17's engineering treatment.

21.9.2 Whether a Standard (per the Standards' §5 table) should specify the memory layer's conformance checklist in engineering terms, once an implementation is proposed, is open; this chapter states the obligation, not the mechanism.

21.9.3 The exact review cadence for reconciling 00010005 under §21.3.13.2 — whether the next annual Codex review (Codex 9, "Review cadence") is soon enough, or whether a specific nearer date should be set for each — is undecided and left to the Stewardship Office.

21.9.4 Whether additional institutional-intelligence questions beyond the twelve in §21.5.4 should be pre-classified as they are identified, or classified individually as they arise using §21.5.2's governing rule, is open; this chapter assumes the latter is sufficient and does not mandate a standing pre-classification exercise.

21.9.5 Whether an organization (as distinct from a person) has any right analogous to §04.8's data rights over what the memory layer or institutional intelligence says about it — beyond the contractual consent already assumed in §21.5.4 items 3 and 9 — is undecided.

21.10 Governing Codices

Codex 1 (Article V on data use and non-optimization for engagement, Article VII on the hundred-year horizon), Codex 9 (governance, amendment, and the decision-record procedure this chapter amends), Codex 6 (experience, insofar as any surface exposes memory-layer or institutional-intelligence material to a person), Chapter 04 (visibility contracts and consent, which §21.5's classifications inherit), Chapter 06 (the Knowledge Graph's parallel prohibition on personal content becoming structure, §06.9), Chapter 16 (aggregation thresholds and reporting cadence, which this chapter's AGGREGATE ONLY classification and memory-layer reporting both inherit rather than restate).