---
name: Terms Sheet - Deployment Kit V1
description: Named-mechanisms glossary for the V1 deployment kit. Defines every concept the kit operates by, organized by category. Companion to PHILOSOPHY.md. Read together to understand the kit; reference individually to look up a specific term. Designed for the operator to teach the kit without needing to be present at every deployment.
type: glossary
---

# Terms Sheet

- **Last reviewed:** 2026-04-28
- **Review cadence:** quarterly + on every kit revision that adds or revises a named mechanism
- **Status:** active

This document defines every named mechanism, process, contract, security, and vocabulary term the V1 deployment kit operates by. The intent: anyone who reads this can name what the kit is doing, identify processes and subprocesses, and teach the kit to others.

PHILOSOPHY.md is the companion. This file is the **what** (named things, defined). PHILOSOPHY.md is the **why** (why those things exist in their specific shape).

## How to read this

Categories below group related terms. Within each category, terms are listed in dependency order (foundational concepts before terms that build on them). An alphabetical index appears at the end.

---

## Category 1: Architecture

### Pod

A self-contained unit with its own governance scaffolding (BACKLOG, decisions/, sessions/, HANDOFF, OPERATING-MODEL). The deployment kit itself is a pod. Every deployed instance is a pod. Sub-platforms within an instance can be pods. Pods compose recursively.

A pod is recognizable by having all of: its own ADR archive (immutable), its own session log directory, its own backlog, its own handoff artifact. A directory that has none of these is not a pod; it is a folder.

### Self-fractal

The property that the kit operates by the same patterns it teaches. The kit is a pod (Category 1, "Pod"). The kit has its own ADRs (decisions/), its own session logs (sessions/), its own BACKLOG, its own HANDOFF, its own OPERATING-MODEL-shaped governance. The kit demonstrates the operating model by being one.

This matters because: a kit that taught patterns it did not itself follow would be hypocritical and weak; a kit that demonstrates the patterns shows what mature looks like in practice, not just in theory.

### Polymorphic single kit

The V1 architecture: one kit, many landings, each landing customized via the localization question set. Distinct from the V2 vision (recursive kit-of-kits) where a meta-kit generates target-specific kits.

V1 ships polymorphic-single because building V2 requires observing how V1 fails in real deployments first. ADR-0001 records the decision.

### Continuous rescaffolding

The V1.1 property that distinguishes this kit from one-shot deployments: the kit lands with a first scaffold (intense, opinionated) and continuously rescaffolds as context grows. Validate findings, session logs, calendar cadence, sponsor changes, regulatory shifts, function-mode shifts, and kit version bumps all trigger rescaffolds.

The kit gets stronger with use, not weaker. Subsequent scaffolds are typically lighter (10-30 min) than the first (30-90 min) because most context is already captured; they target the surfaces where context shifted.

ADR-0005 records the V1.1 architectural shift. PHILOSOPHY.md "Why continuous rescaffolding (not deploy-once)" explains the rationale.

### Bootstrap

Phase 1 of the deploy skill's orchestration. The kit loads BOOTSTRAP-BRIEF.md, orients the operator on what the kit is and what the deployment will produce, and states intent before beginning discovery. Bootstrap is short (a few minutes); its job is to establish shared context.

### Discovery

Phase 2 of the deploy skill's orchestration; also the operating mode of the architect-discovery skill. The kit asks recursively, spawns follow-ups, explains its purpose progressively, and captures honest unknowns as rescaffold triggers. First-scaffold discovery typically runs 30-90 minutes; rescaffold-mode discovery is a targeted subset.

### Initial scaffold

The first time the kit renders templates against gathered context. Intense (full template set; full ADR scaffolding; full validate pass). Subsequent scaffolds (rescaffolds) are lighter and targeted.

The first-scaffold test (BOOTSTRAP-BRIEF Section XVI) is binary: passes if the deployed instance can read the brief, engage discovery, produce an initial scaffold with eight layers classified, refuse to overclaim completeness, and begin operating with a confirmed rescaffold trigger queue.

### Rescaffold

Phase 5 of the deploy skill; also the operating mode of the architect-rescaffold skill. Triggered by validate findings, session-log evidence, calendar cadence, sponsor change, regulatory activation, function-mode shift, kit version bump, or org-local-skill-repo update. Targets only the affected scope; archives the prior MATURITY-SCORECARD; produces a new one; logs the cycle in a session log.

### Rescaffold trigger

A captured event that warrants revisiting some scope of the deployed instance. Lives in `BACKLOG.md`'s "Rescaffold triggers" section or in a dedicated `RESCAFFOLD-TRIGGERS.md` file. Validate emits triggers as part of its scorecard output; honest unknowns from prior scaffolds become triggers when their resolution conditions are met.

### Function-mode

The user's primary working stance, captured in Q1: `building`, `operating`, `deciding`, `creating`, or `mixed`. Drives the relative weight the deployed instance gives to different layers and skills. A `building` deployment scaffolds full L4 platform-kit; a `deciding` deployment treats L4 as inherited and weights ADR practice heavily; a `creating` deployment weights L4 toward asset library + brand kit + content templates.

ADR-0006 records the function-adaptation behavior. PHILOSOPHY.md "Why the kit adapts to the user's function, not just builders" explains the rationale.

### Organizationally aware

The V1.1 property that makes the deployed instance respect and extend the host organization's existing process rather than replacing it. Three surfaces:

- Skill layer: the kit detects the org-local skill repository and recursively populates skills from there before defaulting to kit-bundled equivalents
- Rhythm layer: Doc Lifecycle cadences align to existing organizational rhythms (standup, weekly review, quarterly planning)
- Tooling layer: inbox-outbox pairs route through existing tooling (Slack channels, Linear projects) rather than introducing new patterns

ADR-0006 records this. PHILOSOPHY.md "Why the kit assimilates the user's work process into the organizational process" explains the rationale.

### Org-local skill repository

A path on the operator's filesystem (or an org-internal location) where the organization keeps its own skill bundle. Q6 detects this. If present, the deploy skill performs recursive skill population from the org-local repo, taking precedence over kit-bundled equivalents.

### Learning-is-the-process

The third cardinal insight (BOOTSTRAP-BRIEF Section I.3): the kit is not "deployed once and operating"; it is "deployed initially and continuously rescaffolding." Learning is not a means to a deployment; learning is the deployment.

PHILOSOPHY.md "Insight 3" introduces the term. The continuous-rescaffolding architecture (ADR-0005) operationalizes it.

### Layered decision architecture (L0-L7)

Eight layers, each a precondition for the next. Skipping a layer creates the retrofit trap (a later decision forces redoing earlier work).

| Layer | Scope |
|-------|-------|
| L0 Strategy | Why this capability exists |
| L1 Brand / posture | How the capability shows up to users |
| L2 Philosophy | Promises and red lines across every component |
| L3 Framework contract | Interfaces and quality bars every component must meet |
| L4 Platform kit | The shared toolkit a function pulls from |
| L5 Instance | The operating instance |
| L6 Per-instance refinement | Integration details inside one instance |
| L7 Cross-platform glue | What crosses instances |

**Function-mode shapes content, not scope.** Per ADR-0006, each layer's SCOPE is universal; what the layer CONTAINS varies per function-mode (Build / Operate / Decide / Create). For the per-mode example decisions, see BOOTSTRAP-BRIEF Section II's full layer table or the microsite's interactive layers grid.

### Retrofit trap

The failure mode where skipping a layer (typically L1 or L7) forces relitigating earlier decisions when the layer becomes load-bearing. The cost compounds because every downstream artifact built on the unspecified layer needs revision.

The kit defeats the retrofit trap by requiring every layer to be classified at landing time, even if the classification is `none` or `N/A-explicit`.

### Kit + mirror pattern

L4 architecture: platform team owns the kit (prompts, evals, guardrails, telemetry, SDK); product teams copy pieces into their own tree with `MIRRORED FROM` headers. One-way sync. Improvements flow kit-to-consumer at re-sync time.

Why one-way: changes flowing backward require platform-team intake review, which becomes a bottleneck. The pattern accepts visible duplication as the price of compounding leverage.

### MIRRORED FROM header

The two-line attribution prepended to every mirrored file:

```
<!-- MIRRORED FROM: {source_relative_path} -->
<!-- MIRRORED AT: YYYY-MM-DD -->
```

A file in `kit/` without this header is locally owned and not subject to mirror sync. The header's presence is the boundary between "we mirror this from upstream" and "we own this locally."

### Mirror chain

When mirrors stack: source kit -> instance kit -> sub-platform kit. Updates at the top cascade down through the chain. The architect-kit-mirror skill reasons about chains, not just pairs.

A real chain example: AI-Architect/skills/architect-audit -> deployment-kit/skills/architect-audit -> {deployed-instance}/kit/skills/architect-audit. Mirror discipline applies at each link.

### Locally-owned component

A file in a kit subtree that does NOT carry a MIRRORED FROM header. Source-of-truth is local; not pulled from upstream; not subject to drift detection. The boundary distinguishes "we extended the kit" (locally owned) from "we mirrored the kit" (subject to re-sync).

---

## Category 2: Maturity and relationships

### Maturity scale

The four-step classification for any layer's state:

- **none** - layer has not been touched
- **stubbed** - placeholder artifact exists with right shape but no real content
- **partial** - artifact exists with content but incomplete or has named gaps
- **mature** - complete, current within cadence, capable replacement could operate from it

L1 has a fifth state, **N/A-explicit**, used when the layer consciously does not apply.

The scale is **never collapsed to binary**. Reporting "L3 exists" or "L3 missing" is the named failure mode "binary existence checks" and is prohibited.

### Evidence (for maturity)

To mark a layer `mature`, the audit must name evidence: last-reviewed date within cadence, recent session log confirming the layer was operated against, OR validate-scoped check that the artifact's content is non-stubbed.

The validate skill refuses to mark `mature` without naming evidence. This is encoded as a refusal condition in skills/validate/SKILL.md.

### Relationship semantics

Every relationship between artifacts (inheritance, mirror, inbox-outbox, handoff, runtime-call, runtime-subscribe) is classified one of two ways:

- **live** - exercised end-to-end at least once with verification within reasonable window
- **declared-but-inactive** - documented but not verified, or verification is stale

**Default assumption is declared-but-inactive until evidence shows otherwise.** A relationship described in present indicative ("inherits", "mirrors", "drains") without a `last verified` date is declared-but-inactive.

### Reasonable window (per relationship type)

The cadence within which a relationship's verification stays current:

| Type | Window |
|------|--------|
| Mirror | within sync cadence (typically biweekly) |
| Inbox-outbox | within drain cadence (typically weekly to biweekly) |
| Handoff (runtime envelope) | within 7 days |
| Cross-platform runtime call | within 7 days |
| Inheritance (static) | once per quarter |
| Runtime auth | within 30 days OR continuous |
| Event subscribe | within 30 days OR continuous |

Outside its window, a relationship demotes to declared-but-inactive even if previously live.

### Drift

The state where a mirror's content lags its source. Detected by the architect-kit-mirror skill's Mode C. Drift triggers demotion of the relationship from live to declared-but-inactive; the layer that depends on the mirror also demotes if its maturity rested on the relationship being live.

---

## Category 3: Decision artifacts

### ADR (Architecture Decision Record)

An immutable record of a 2+-real-options decision. Numbered sequentially per pod. Once accepted, never edited; revision happens by writing a new ADR with `Status: accepted` and updating the old ADR's status to `superseded by ADR-XXXX`.

ADR-worthiness: write one if any two of these are true:

- 2+ real options exist
- Decision is not trivially reversible
- A future operator will wonder "why did we choose this?"
- Cross-team or cross-product implications
- Regulatory, privacy, or cost considerations factor in

### Supersession

The protocol for revising an ADR. Never edit; always write a new ADR. Set new ADR's status to `accepted`; set old ADR's status to `superseded by ADR-{NNNN}`. The old ADR stays on record.

Supersession preserves audit trail; rewriting destroys it.

### Immutability

The property that ADRs are write-once after `Status: accepted`. Enforced by social discipline (the kit refuses to author edits to accepted ADRs) plus by the supersession protocol providing the only legitimate revision path.

Immutability is what makes the ADR archive trustworthy as a decision history.

### LOCALIZATION-ANSWERS.md

The captured-answers artifact written by the deploy skill once the 10 questions have been answered. Source-of-truth for every localized value in the deployed instance. Revision is a supersession event (logged with reason and ADR if a downstream decision changes).

---

## Category 4: Governance scaffolding

### Doc Lifecycle

The frontmatter discipline applied to every governance artifact:

```
Last reviewed: YYYY-MM-DD
Review cadence: quarterly | monthly | annually | on-change | on-event | ad-hoc
Status: active | draft | archived | deprecated | superseded
```

Plus AI-specific fields where applicable: `Model compatibility`, `Owner`, `Reproducibility pin`.

Staleness rule: if `Last reviewed` is older than `cadence * 1.5`, flag the artifact. If older than `cadence * 2`, flag urgently. Drift in governance artifacts is where silent failure accumulates.

### Frontmatter

The YAML block at the top of every governance markdown file. Contains the Doc Lifecycle fields plus artifact-specific fields (`name`, `description`, `type`, `populated_from`, `Owner` where applicable). The frontmatter is the artifact's self-description; tooling reads it for indexing and staleness checks.

### Inbox-Outbox pair

A declared async-coordination channel between two pods. Has typed entries (date, source, type, state, priority, target close), a drain cadence, named owners on both sides, and audit trail.

The pair eliminates meetings that would otherwise surface what a typed-dated entry could surface async. Quarterly audit confirms entries either resolved, escalated to ADR, or moved to BACKLOG.

### Drain

The protocol for processing inbox entries. For each open entry: confirm typed shape; classify next move (acknowledge / actioned-here / escalate-to-ADR / move-to-BACKLOG); update entry state; ping other side's owner if needed.

A drain that produces no state changes is a finding (either no traffic or read-only-glance; both warrant attention).

### BACKLOG

The pod's pending-work artifact. Items added when they surface during sessions, off-ramps fire, or inbox drains park them. Each entry has date added, source, state, priority, target close condition.

Quarterly review pass per Doc Lifecycle.

### HANDOFF (Repo Custody)

The pod's custody-state artifact. Names: repo location, owner, backups, secrets inventory, one-way doors, cross-pod relationships table, files in custody, resumption posture, IP boundary if any, concurrent-actor count.

Updated on any custody change; otherwise quarterly.

### One-way door

An operation that cannot be reversed: training data that cannot be regenerated, production datasets with consent constraints, keys that would take weeks to rotate, contracts that cannot be unsigned. Named explicitly in HANDOFF so future operators know what not to break.

### OPERATING-MODEL.md

The pod's root summary doc. The first document any fresh operator reads. Summarizes maturity across all eight layers, lists L5 platforms, names active ADRs, points to next moves, includes the "What to do if you are new here" read order.

### MATURITY-SCORECARD.md

The pod's full-fidelity audit output. Generated by the validate skill. Per-layer maturity table, L7 six-concern table, per-relationship classification, ADR catalog, behavior-trigger encoding check, concurrent-actor surface review, vocabulary check, failure-mode trigger check, single highest-leverage next move.

### Session log

A dated record of any session that changed governance state, made non-trivial code changes, or made decisions worth preserving. Filed at `sessions/YYYY-MM-DD-{short-purpose}.md`. Required sections: what produced, decisions, findings, state changes, concurrent-actor notes, handoff posture, failure modes encountered, session metadata.

Trivial sessions do not need logs; the architect-handoff skill encodes the threshold.

---

## Category 5: Behavior mechanisms

### Behavior trigger

A "when you see X, do Y" instruction encoded in a doc, skill, checklist, or runbook. Distinct from an aphorism (general principle without a "do this" attached).

The kit prefers behavior triggers over aphorisms because aphorisms degrade silently when the operator's attention is elsewhere; triggers fire on specific pattern matches.

### Refusal condition

A condition under which a skill refuses to proceed. The kit's skills are refusal-encoded for known failure modes:

- deploy refuses to render templates without all 10 answers (silent skip)
- validate refuses to mark a layer mature without evidence
- architect-kit-mirror refuses to push back into source without ADR authorization
- architect-inbox-flow refuses to declare a pair with unnamed owner
- architect-compliance refuses to declare regime posture without named owner per regime
- architect-handoff refuses trivial sessions

Refusal-encoded skills are stronger than guidance-only skills because they catch the failure mode structurally.

### Self-update protocol

The trigger encoded in deploy and other long-running skills: re-read BOOTSTRAP-BRIEF.md at the start of every invocation, even if cached. The brief evolves; cached behavior drifts. Re-reading on activation keeps the deployed instance aligned with the latest standard.

If the brief and skill conflict: the brief wins; the discrepancy surfaces as a kit BACKLOG finding.

### Hard gate

A precondition that absolutely blocks downstream behavior until satisfied. The deploy skill's hard gate: all 10 localization questions must have captured answers meeting acceptance criteria before any template renders.

The hard gate distinguishes from a soft prompt (an ask the operator can decline). Hard gates exist where prior failure modes proved soft prompts were insufficient (see ADR-0003).

### Honest unknown

The captured answer when an operator genuinely cannot answer a localization question: `unknown - {reason}`. The corresponding layer lands as `none` and the unknown surfaces in the audit so it gets scheduled rather than ignored.

Honest unknowns are first-class. Silent skips are the failure mode honest unknowns defeat.

### Default suggestion

A sensible-shape suggestion the deploy skill names for a localization question, which the operator must explicitly accept. Defaults are visible but never silent skip-shortcuts. Stating a default the operator must approve is distinct from the default firing automatically.

ADR-0003 records the policy: defaults inform but never skip.

### Lock-on-write

The concurrent-actor protocol: when two sessions are about to edit the same artifact, the second session pauses, writes a session log explaining the collision, and waits. Per BOOTSTRAP-BRIEF Section IX.

### Concurrent-session protocol

The five disciplines for multiple actors operating on the same instance: session log every state-changing session; update kickoff if next session needs mid-stream pickup; hold inbox-outbox for cross-pod coordination; lock-on-write for live shared state; never commit silently.

---

## Category 6: Failure modes (named seven)

These are the known failure modes the kit is designed to defeat. Each has a "trigger" (how to recognize the moment when you might commit it) and a "correction" (what to do instead).

### Path-to-layer pattern matching

**Failure:** classifying an artifact's layer by where it lives in the folder tree (`/platform/foo.md` therefore L4) without examining what the artifact does.

**Trigger:** you reached a layer classification in less than five seconds.

**Correction:** stop; read the artifact; ask "what decision does this make?"; match to layer scope.

### Binary existence checks

**Failure:** reporting "L3 exists" because a file at the L3 path is non-empty.

**Trigger:** you used the words "exists", "missing", "present", or "yes/no" about a layer's state.

**Correction:** replace with the four-step maturity scale.

### Missing L7 awareness

**Failure:** auditing layers L0-L5 and skipping L7, or treating cross-cutting concerns (consent, identity, alerting) as L4.

**Trigger:** your audit has fewer than eight layer rows OR a row labeled L7 says "N/A" without justification.

**Correction:** add the L7 row; either populate the six concerns or justify N/A explicitly.

### Static inventory vs. assessment

**Failure:** producing a list of what is in the instance without classifying maturity or relationship liveness.

**Trigger:** your output to "audit this" looks like `find . -type f`.

**Correction:** redo as a maturity table with gaps and retrofit risk.

### Overclaimed completeness

**Failure:** declaring an instance "deployed" or "complete" when only stubbed artifacts exist.

**Trigger:** you used the words "deployed", "complete", "done", "shipped", "ready" without per-layer maturity backing.

**Correction:** state maturity per layer first; let "complete" follow only if every applicable layer is mature.

### Floating concept

**Failure:** a concept appears in artifacts (`alignment`, `north star`, `playbook`, `pillar`) without being tied to a layer or relationship.

**Trigger:** you wrote a noun you cannot map to L0-L7 or to a named relationship.

**Correction:** map it or rename it; do not let it float.

### Untested relationship

**Failure:** treating declared inheritance, declared mirror, declared inbox as live without evidence.

**Trigger:** you described a relationship using the present indicative ("inherits", "mirrors", "drains").

**Correction:** demote to "declared to inherit / mirror / drain" until you have observed end-to-end effect.

---

## Category 7: Vocabulary discipline

### Protected vocabulary

Seven words with specific meanings the kit enforces. Used outside their definitions in a way that obscures audit intent, they trigger a vocabulary-consistency finding.

| Word | Defined meaning |
|------|----------------|
| layer | One of L0-L7 as defined in Category 1 |
| maturity | The four-step scale (none / stubbed / partial / mature) |
| live | Relationship whose effect is verified end-to-end |
| declared-but-inactive | Relationship existing on paper without verification |
| ADR | Immutable record of 2+-real-options decision |
| mirror | One-way-synced copy with MIRRORED FROM header |
| pod | Self-contained governance unit |

Everyday-language uses ("the lead is live in our queue") are not findings unless they create ambiguity in an audit context.

### Floating concept (vocabulary failure mode)

When a noun appears in artifacts without mapping to an L0-L7 layer or named relationship. The most common shape: marketing-flavored terms (`alignment`, `north star`, `playbook`) sneaking into governance artifacts.

The validate skill scans for floating concepts. Each is a finding to either map or rename.

---

## Category 8: Skills (kit-native)

The kit ships 11 skills it authored plus 3 mirrored from AI-Architect plus 29 imported (25 Cowork + 4 security). The 11 kit-native skills + 3 mirrored AI-Architect skills are the operating-model-essential set.

### deploy

The deployment driver. Reads BOOTSTRAP-BRIEF, asks 10 mandatory questions, populates templates, runs validate before declaring complete. Refuses silent skips. Encoded in `skills/deploy/SKILL.md`; sequence in `skills/deploy/SEQUENCE.md`.

### validate

Post-deployment audit. Produces MATURITY-SCORECARD; identifies single highest-leverage next move. Refuses to mark layers mature without evidence. Encoded in `skills/validate/SKILL.md`; per-check rules in `skills/validate/RUBRIC.md`.

### architect-kit-mirror

Manages mirror discipline. Four operating modes: first sync, routine re-sync, drift detection, conflict resolution. Reasons about mirror chains. Refuses bidirectional sync without ADR authorization.

### architect-handoff

Writes session logs and updates kickoff docs. Refuses trivial sessions; insists on logs for state-changing sessions.

### architect-inbox-flow

Declares and drains inbox-outbox pairs. Refuses pair declaration without named owners on both sides.

### architect-compliance

Maps deployed instance to regulatory regimes (GDPR, SOC 2, HIPAA, etc.). Identifies L2/L3 gaps; scaffolds evidence runbooks.

### architect-audit (mirrored from AI-Architect)

L0-L7 layer audit. Used by validate during the audit pass.

### architect-adr (mirrored from AI-Architect)

ADR scaffolder. Used to write decisions during operation.

### architect-lifecycle (mirrored from AI-Architect)

Doc Lifecycle staleness checks. Used to add frontmatter and audit cadence compliance.

---

## Category 9: Tests

### Iron Man test

The success threshold for a landing. A landing has succeeded when the deployed instance can:

1. Read BOOTSTRAP-BRIEF
2. Answer the 10 localization questions
3. Produce a populated mature instance with all eight layers classified, relationships declared, ADRs catalogued, maturity scorecard filled in
4. Refuse to declare any layer "complete" without evidence
5. Begin operating on the function it was deployed for

If any step is skipped or stubbed, the landing has failed. Land again or escalate.

The Iron Man test is binary: pass or fail. Designed to defeat the "shell of intent" landings where deployment looked complete but operated weakly.

### Audit standard

The mandatory output shape for any audit of a deployed instance: per-layer maturity table, per-relationship classification, ADR catalog, behavior-trigger encoding check, single highest-leverage next move.

The validate skill produces this; the MATURITY-SCORECARD is its persistent form.

### Reproducibility quadruple

For any AI-producing instance, the four version-pin fields emitted on every request:

- model_version
- prompt_version
- tool_set_version
- data_snapshot_version

Two of four is not reproducible. Pin all four or pin none and own the gap explicitly. The reproducibility quadruple is the floor of the L3 telemetry schema.

### Five-question decision framework

Before adopting any practice, run five questions; failure on any one is a flag:

1. Does this serve the customer (internal or external)?
2. Does this respect privacy?
3. Is this the simplest approach that works?
4. Could a capable replacement operate this from the artifacts alone?
5. Does the fully-loaded cost (human + AI + compute + review overhead) stay proportional to the value?

Questions 4 and 5 are the hero-dependency guard and the economics guard; together they catch the two most common failure shapes: practices that look impressive but only the original author can run, and practices that consume more attention than they produce.

---

## Category 10: Ecosystem

### Operator

The human directing the kit. Drops the kit into a fresh environment, answers the 10 questions, reviews the MATURITY-SCORECARD, decides which next moves to execute. The operator is not always present; the kit is designed to operate correctly without supervision after landing.

### Deployed instance

The pod the kit produces in a target environment. Has all the governance scaffolding the kit teaches (OPERATING-MODEL, BACKLOG, decisions, sessions, HANDOFF), populated for the localization answers, ready to operate the function.

### Source library

The original AI-Architect personal-practice library where the methodology lives. The kit's BOOTSTRAP-BRIEF is derived from `AI-Architect/fundamentals.md` v1.2; the three architect-* skills are mirrored from `AI-Architect/skills/`. The source library is operator-side; the kit ships self-contained so the deployed instance never needs to reach back.

### Layer-team

A team that operates a specific layer of the deployed instance. L4 platform team owns the platform kit; L5 product teams own instances; L7 cross-cutting teams own consent flow / identity / alerting / monitoring. Each layer-team has named ownership in the relevant dossier or HANDOFF table.

### Recursive Skill Optimization & Scaffolding Engine

The V2 vision (named in AI-Architect/BACKLOG.md). A meta-tool that takes V1's polymorphic-single-kit pattern and generalizes it: given a source methodology + an environment profile + scaffolding rules, produce an adapted kit per target. V2 cannot be built without observing V1 in real deployments first; the recursion's optimization rules need real-world evidence.

V1 ships the inputs V2 will eventually consume.

---

## Alphabetical index

Every term, alphabetical, with its category number for fast lookup:

- ADR (Architecture Decision Record) - Category 3
- Architect-adr - Category 8
- Architect-audit - Category 8
- Architect-compliance - Category 8
- Architect-handoff - Category 8
- Architect-inbox-flow - Category 8
- Architect-kit-mirror - Category 8
- Architect-lifecycle - Category 8
- Audit standard - Category 9
- BACKLOG - Category 4
- Behavior trigger - Category 5
- Binary existence checks (failure mode) - Category 6
- Concurrent-session protocol - Category 5
- declared-but-inactive (relationship status) - Category 2
- Default suggestion - Category 5
- deploy (skill) - Category 8
- Deployed instance - Category 10
- Doc Lifecycle - Category 4
- Drain - Category 4
- Drift - Category 2
- Evidence (for maturity) - Category 2
- Five-question decision framework - Category 9
- Floating concept (failure mode + vocabulary discipline) - Category 6, 7
- Frontmatter - Category 4
- HANDOFF (Repo Custody) - Category 4
- Hard gate - Category 5
- Honest unknown - Category 5
- Immutability - Category 3
- Inbox-Outbox pair - Category 4
- Iron Man test - Category 9
- Kit + mirror pattern - Category 1
- Layer-team - Category 10
- Layered decision architecture (L0-L7) - Category 1
- live (relationship status) - Category 2
- Localized (LOCALIZATION-ANSWERS.md) - Category 3
- Locally-owned component - Category 1
- Lock-on-write - Category 5
- mature (maturity scale) - Category 2
- Maturity scale - Category 2
- MATURITY-SCORECARD.md - Category 4
- Mirror chain - Category 1
- MIRRORED FROM header - Category 1
- Missing L7 awareness (failure mode) - Category 6
- N/A-explicit (L1) - Category 2
- none (maturity scale) - Category 2
- One-way door - Category 4
- OPERATING-MODEL.md - Category 4
- Operator - Category 10
- Overclaimed completeness (failure mode) - Category 6
- partial (maturity scale) - Category 2
- Path-to-layer pattern matching (failure mode) - Category 6
- Pod - Category 1
- Polymorphic single kit - Category 1
- Protected vocabulary - Category 7
- Reasonable window (per relationship type) - Category 2
- Recursive Skill Optimization & Scaffolding Engine - Category 10
- Refusal condition - Category 5
- Relationship semantics - Category 2
- Reproducibility quadruple - Category 9
- Retrofit trap - Category 1
- Self-fractal - Category 1
- Self-update protocol - Category 5
- Session log - Category 4
- Source library - Category 10
- Static inventory vs. assessment (failure mode) - Category 6
- stubbed (maturity scale) - Category 2
- Supersession - Category 3
- Untested relationship (failure mode) - Category 6
- validate (skill) - Category 8

## Cross-references

- `BOOTSTRAP-BRIEF.md` - the operating-model standard the deployed instance follows
- `QUESTIONS.md` - the 10 mandatory localization questions
- `PHILOSOPHY.md` - the why behind the named mechanisms in this glossary
- `KICKOFF.md` - the paste-and-run prompt for Cowork
- `templates/` - the populatable templates each layer uses
- `examples/martech-mature-instance/` - the worked example showing every term in use
- `decisions/ADR-0001-polymorphic-single-kit.md` - the V1 architecture decision
- `decisions/ADR-0002-self-contained-export.md` - the self-containment constraint
- `decisions/ADR-0003-mandatory-localization-questions.md` - the hard-gate decision
- `skills/` - the 43 skills (25 Cowork + 3 AI-Architect mirrored + 4 security + 11 kit-native)
