---
name: Philosophy - Deployment Kit V1
description: The why behind the V1 deployment kit. Why specific mechanisms exist in their specific shape. Companion to TERMS.md (which defines the what). Designed for the operator to understand and teach the kit; reads as a coherent argument from cardinal insight to operational discipline. Repeatable hundreds of times without operator supervision is the design constraint.
type: philosophy
---

# Philosophy

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

This is the why. TERMS.md defines what every named mechanism IS; this document explains why those mechanisms exist in their specific shape, and how they compose into a system that can land hundreds of times in fresh environments without the creator watching.

Read top-to-bottom on first pass. Reference individual sections when teaching specific patterns.

## The three cardinal insights

Everything in the kit derives from three ideas. If you teach nothing else, teach these.

### Insight 1: Make implicit decisions explicit. Name the layers. Inherit instead of reinventing.

Most organizational dysfunction in technical systems comes from upstream decisions that were made informally, never written down, and then relitigated by every downstream actor in slightly different ways. The fix is mechanical: name the layers; write the decisions; inherit them; require new work to either inherit or supersede with rationale.

This is why L0-L7 exist as named layers, why ADRs are immutable, why every artifact carries Doc Lifecycle frontmatter, why Inbox-Outbox pairs replace meetings. The pattern is universal: implicit becomes explicit; explicit becomes referenceable; referenceable becomes inheritable.

### Insight 2: The marginal cost of completeness has compressed.

Practices that were rationally skipped in 2020 (eval baselines, ADRs on consequential decisions, frontmatter on every artifact, reproducibility pinning, layered tests) cost a fraction now of what they used to cost when AI assistance was unavailable. The cost of *omitting* them has not compressed: a silent regression still takes weeks to debug, a relitigated decision still consumes meeting hours, a stale prompt still erodes customer trust.

The economics flipped. The argument for adopting any practice in this kit is not "do this because it is correct" but "do this because the math no longer says skipping is cheaper."

### Insight 3: Learning is the process. The first scaffold is intense; later ones adapt.

Most kits, frameworks, and methodologies operate as one-shot artifacts: deploy once, configure once, then run unchanged. This pattern fails predictably: the deployment context shifts, the operator's understanding deepens, the ecosystem evolves, and the original configuration becomes wrong. Worse, the kit does not know it has become wrong because nothing in its design re-examines its own posture.

This kit operates differently. **Learning is not a means to a deployment; learning is the deployment.** The kit lands with an initial scaffold (thorough, intense, opinionated), then continuously rescaffolds as context grows. Every validate run is a rescaffold trigger. Every session log is context that may invalidate prior layer maturity. Every new platform added is a structural shift the kit revisits.

The first scaffold answers what it can answer with the context available at landing. Subsequent scaffolds incorporate what the deployment learned about itself: which questions had honest unknowns that have since resolved; which layers were `partial` and have matured; which relationships were `declared-but-inactive` and are now `live`; which red lines proved insufficient under real adversarial pressure.

The kit is not "deployed once and operated"; it is "deployed initially, continuously rescaffolds, and matures with the function it serves." Subsequent scaffolds are lighter than the first because most context is now captured; they target the surfaces where context has actually shifted.

This is why the question gate is recursive, not fixed; why validate produces rescaffold triggers, not just reports; why the deploy skill has multiple modes (bootstrap, discovery, scaffold, operate, rescaffold) rather than a single one-shot landing flow.

## Self-fractal: the kit operates by what it teaches

The deployment kit is a pod. It 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 is load-bearing because:

- A kit that taught patterns it did not itself follow would be hypocritical. Operators would notice and discount it.
- A kit that demonstrates the patterns shows what mature looks like in practice, not just in theory. The deployed instance can mirror the kit's structure as a literal example of "what to build."
- The kit is the simplest test case for its own validate skill. If the kit's pod cannot pass validate, the validate skill is wrong; if the kit's pod passes, validate works on at least one case.

The self-fractal property compounds: the kit demonstrates the kit-mirror pattern by being the source of mirror chains. The kit demonstrates ADR practice by writing ADR-0001, ADR-0002, ADR-0003 for its own design decisions. The kit demonstrates session-log discipline by logging its own build chunks (Chunks A, B, C, D+E, F).

When you teach the kit to others, point at the kit's own structure as the canonical example. "Here is what we mean by pod. Here is what we mean by ADR archive. Here is what we mean by session log discipline." The kit is its own training material.

## Why polymorphic single kit, not recursive engine yet

V1 ships one kit; many landings; each landing customized via the localization question set. V2 (vision) is a recursive engine: a meta-kit generates target-specific kits.

V1 is single-kit because:

- Building V2 requires observing how V1 fails in real deployments first. The recursion's optimization rules need real-world evidence; without that, the rules would be guesswork.
- V1 produces the artifacts V2 will consume: a working worked example, a failure-mode catalog, a validation rubric, a 10-question localization schema. Building V1 well is the prerequisite for V2.
- V1 must ship in days, not weeks; V2 cannot.

ADR-0001 records this decision in its full form. The principle to teach: the meta-tool is the natural V2 of any successful single-tool. Build the single tool first; observe failures; then generalize.

## Why self-contained export

The kit is fully self-contained on export. Every cross-reference inside the kit resolves inside the kit. The kit ships with no external dependencies: no fetches from operator-personal paths, no API calls to source libraries, no assumptions about the host environment beyond a Cowork-shaped skill loader.

This is non-negotiable because:

- The deployed instance has no guaranteed access to the operator's filesystem, internal network, or original source library. The kit must work as if dropped onto an air-gapped system.
- IP boundary: shipping personal-side paths into employer environments would contaminate the boundary. Self-containment respects the boundary by construction.
- Survives operator-side renames, restructures, library migrations. The kit does not break when the operator moves files around.

The tradeoff: source-material updates require a new kit version, not auto-propagation. ADR-0002 records this. The mitigation: dated versions; quarterly cadence on the kit's own Doc Lifecycle; v1.x patch releases for source-side updates that warrant propagation.

## Why questions are recursive, not fixed

The kit asks questions extensively. The first scaffold has a base set of around ten orientation questions; subsequent scaffolds ask whatever the gathered context surfaces as a new gap. The questions are recursive: an answer can spawn follow-up questions; a follow-up can spawn its own; the kit explains its purpose progressively as it asks.

This shape exists because the original "fixed 10 mandatory questions" framing was wrong. It encoded the right discipline (refuse silent skips; demand concrete answers; surface honest unknowns) at the wrong altitude (treated landing as a one-shot gate rather than an opening conversation). The discipline carries forward; the altitude changes.

ADR-0004 records the new model (and supersedes ADR-0003 which encoded the fixed-10 framing). The principle to teach: structural enforcement of question discipline carries through every scaffold, not just the first. The first scaffold establishes the orientation base; later scaffolds add depth, surface what previous scaffolds missed, and adapt to changes in the function the kit serves.

The honest-unknown affordance still applies and now applies recursively. An unknown at first scaffold becomes a finding for the next scaffold to revisit, which may itself surface follow-up unknowns. The kit accepts that some questions can only be answered after the function has operated for a while; the kit returns to those questions when context permits.

A first-scaffold landing is not "the deployment is complete." It is "the deployment has begun." Maturity arrives through operation; the kit's job is to keep asking, keep adapting, keep rescaffolding.

## Why immutable ADRs

ADRs are write-once after `Status: accepted`. Revision happens by writing a new ADR with `Status: accepted` and updating the old ADR's status to `superseded by ADR-{NNNN}`.

Immutability is what makes the ADR archive trustworthy as a decision history. If old ADRs could be edited, the archive would not be reliable evidence of what we decided when. Future operators (including future-you) need to know the rationale at the time the decision was made, not the rationale that survived editing.

Supersession preserves the archive while permitting revision. The old ADR stays on record; the new ADR carries its own date and rationale. A reader can trace the decision lineage backwards.

The principle to teach: write-once-then-supersede is the cheapest way to maintain audit trail. The cost is one extra file per revision; the value is irreducible decision history.

## Why one-way mirror

The kit-mirror pattern is one-way by default. Source-of-truth lives at the kit; consumers mirror; improvements flow source-to-consumer at sync time. Bidirectional sync requires an explicit ADR authorizing it.

One-way exists because:

- Bidirectional sync introduces governance complexity (review SLAs, conflict resolution, whose changes win). The complexity becomes a bottleneck.
- One-way preserves the boundary between "we own this" and "we mirror this." A locally-owned file can be edited freely; a mirrored file follows mirror discipline. The boundary is enforced by the MIRRORED FROM header's presence.
- Visible duplication is the price; compounding leverage is the payoff. Each consumer adapts the kit to local needs while staying upgrade-compatible at re-sync.

The principle to teach: when in doubt about sync direction, default one-way; introduce bidirectionality only when the cost of duplication clearly exceeds the cost of governance complexity.

## Why mandatory L7 awareness

L7 (cross-platform glue) is the most-commonly missed layer. Junior actors stop at L5 and treat anything cross-cutting as L4. They are different. L4 is the kit (what each instance pulls from). L7 is the glue (what crosses between instances).

The kit defeats the omission failure mode by structure, not by discipline:

- Q8 in QUESTIONS.md is mandatory and has six concerns; every concern must be answered with one of `exists-mature`, `exists-partial`, `declared-not-built`, `none-applicable`. `unknown` is prohibited.
- The L7 template has six concern sections; the deploy skill renders all six.
- The validate skill scans for fewer-than-six concern rows and flags as a finding.

The principle to teach: the layers most-commonly missed need the most rigorous structural enforcement. L7's rigor is asymmetric to its deployment-time cost: a few minutes of question-answering at landing prevents the retrofit trap that would emerge months later when a cross-cutting concern ships partial.

## Why named owners (refusal of "the team")

Skills refuse to declare ownership as "the team." Owners must be named: a role, a person, an oncall rotation. Specifically:

- architect-inbox-flow refuses to declare an inbox-outbox pair without a named owner on both sides
- architect-compliance refuses to declare regime posture without a named owner per regime
- L5 dossiers and L7 concern artifacts include `Owner` fields; validate flags missing or generic owners

The "team" anti-pattern is the silent failure mode where ownership diffuses across many people and effectively belongs to none. When something breaks, escalation routes through "let me find someone who owns this," which is the start of an incident, not its resolution.

Named owners (a role like "Compliance Engineering oncall lead" or a specific person) make escalation paths concrete. The principle to teach: ownership without a name is decorative; ownership with a name is operational.

## Why "live" requires evidence

A relationship's default classification is `declared-but-inactive`. To classify as `live`, the audit must name the verification event (last-verified date, last drill, recent end-to-end trace).

This exists because untested relationships are a named failure mode. The artifact arrows are drawn; the inheritance is documented; the inbox path is named. None of that proves the relationship works. A relationship that has not been exercised end-to-end is not load-bearing yet.

The principle to teach: trust the verification, not the documentation. Documentation can describe a system that has never worked; verification can only happen against a system that does. When you teach the kit, anchor every "this works" claim to a recent date when it was verified.

## Why behavior triggers, not aphorisms

The kit prefers "when you see X, do Y" instructions over general principles. Compare:

- Aphorism: "Always respect the L2 red lines."
- Behavior trigger: "When you see a guardrail trip in telemetry with `tier: red-line-1`, alert {{trust_team}} via the on-call PagerDuty schedule within 30 minutes."

Aphorisms degrade silently when attention is elsewhere. They fail in two directions: the operator forgets the principle, or the operator remembers the principle but cannot translate it to a specific situation. Behavior triggers fire on pattern matches; the operator does not need to remember; the trigger reminds.

The kit encodes triggers in:

- Skills (every skill has "When to invoke" rules tied to operator-spoken phrases)
- BOOTSTRAP-BRIEF Section V (concrete trigger-and-action pairs)
- Failure-mode descriptions (each names the trigger for the failure plus the correction)

The principle to teach: any standard worth following is worth encoding as a pattern-match-plus-action. Aphorisms are seeds; triggers are the standing rules. Make standing rules; do not rely on remembered seeds.

## Why the Iron Man test

The Iron Man test is binary: pass all five steps or the landing has failed. There is no 90% pass; either the deployed instance can read the brief, answer the questions, produce the populated mature instance, refuse to overclaim, and begin operating, or it cannot.

Binary success criteria exist because:

- Soft success criteria ("mostly worked") permit the "shell of intent" failure mode prior kits exhibited. Operators feel they landed; the deployed instance does not actually operate the standard.
- The five Iron Man steps are the load-bearing minimums. Skipping any one drops the standard below operational threshold. There is no version of "deployed but cannot answer the 10 questions" that operates correctly.

The risk: the binary criterion can feel harsh on first deployments. The mitigation: when the test fails, the kit refuses to declare complete and surfaces the gap; the operator knows precisely what to fix. Binary failure is more recoverable than ambiguous partial-success.

The principle to teach: when a standard's value depends on universal compliance (every component implements the contract, every layer reaches maturity, every cross-cutting concern is named), pass criteria must be binary. Partial-credit on universal-compliance standards eats the standard.

## Why the kit adapts to the user's function, not just builders

Most deployment kits in technical contexts assume the user is building something. This kit serves a wider range of functions: operators running business processes, decision-makers who need governance over decisions, creators producing content and campaigns, ops people running services, analysts producing artifacts. Not every user is building software; every user is doing **something** with a structure worth naming.

The kit asks "what is your function?" early and adapts the rest of its behavior to the answer. Specifically:

- **Builders** get the L4 platform-kit + L5 instance dossier shapes weighted heavily; eval baselines and reproducibility gates are first-class.
- **Operators** (running an existing process; not building new) get L0 strategy, L7 cross-platform glue, and inbox-outbox pairs weighted heavily; the eval baseline is lighter because the process predates the AI surfacing.
- **Decision-makers** get ADR practice and Doc Lifecycle weighted heavily; the platform-kit layer is often inherited rather than scaffolded.
- **Creators** get content-template discipline, asset-handoff drains, and brand-voice guidelines weighted heavily; the L0 strategy is often "this voice in this channel for this audience" rather than "ship this capability."

The kit's templates remain the same; their relative weight in the deployment changes. The discovery skill (the recursive question driver) reads the function answer and shapes the conversation accordingly. A landing for an operator does not waste time scaffolding eval harnesses for prompts that do not exist; a landing for a creator does not pretend the metric is engineering throughput when it is reach, resonance, or brand fit.

The principle to teach: an operating model is not "for builders." It is for any function with structure worth governing. The kit assumes a function exists; the kit does not assume the function is software development.

## Why the kit assimilates the user's work process into the organizational process

Every user already has a work process. The kit does not replace it; the kit integrates it. Specifically:

- The kit asks about the user's existing rhythms (daily standup, weekly review, quarterly planning) and aligns Doc Lifecycle cadences to them
- The kit asks about the user's existing tools (Slack, Linear, Confluence, Airtable) and writes inbox-outbox pairs that route through those tools rather than introducing new ones
- The kit asks about the user's existing governance (ADRs, design docs, RFCs, OKRs) and either inherits the existing ADR location or scaffolds one that complements rather than replaces
- The kit detects the organization's local skill repository (if it has one) and recursively populates the deployed instance's skill set from there before reaching for kit-bundled defaults

The principle: the kit is **organizationally aware**. A landing that pretends the org has no existing process is rejected by the org's own actors as foreign and ignored. A landing that builds on what exists, names it explicitly, and extends it where useful is adopted because it makes the existing process legible without replacing it.

The first scaffold detects what exists; later scaffolds tighten the integration. The kit's value is partly in what it adds and partly in how it surfaces and respects what already operates.

## Why continuous rescaffolding (not deploy-once)

The kit lands with a first scaffold: thorough, intense, opinionated. Subsequent scaffolds are different in kind from the first.

Triggers for rescaffold:

- A validate run produces findings whose resolution requires layer-level changes (an L4 mirror sync drift; an L7 concern that became `unknown` post-incident)
- A session log surfaces context the first scaffold could not have known (a new platform added, a regulatory regime triggered, a sponsor change)
- A localization answer is revised (the user updated their function, the metric shifted, the platform kit posture changed)
- Calendar cadence (quarterly minimum even if no event triggers)
- A new skill becomes available (org skill repository updated; kit V1.x patch released)

Each rescaffold is a supersession event in the same way an ADR revision is. The new scaffold's posture is logged; the prior scaffold's state stays on record (in session logs and prior MATURITY-SCORECARD versions). The kit can trace its own learning.

Subsequent scaffolds are typically lighter than the first because the orientation work is done; they target the surfaces where context has actually shifted. A rescaffold may touch only one or two layers; the rest are validated as still-current and skipped.

This is what "learning is the process" means operationally: every scaffold encodes the kit's current understanding; every operation gathers more context; every validate run surfaces what the next scaffold needs to address. The kit gets stronger with use, not just deployment.

The principle to teach: a kit that does not rescaffold ages out within months because the world it describes drifts from the world that exists. Continuous rescaffolding is what turns a kit into a living standard.

## Why pods, not folders

A pod is a self-contained unit with its own governance scaffolding (BACKLOG, decisions/, sessions/, HANDOFF, OPERATING-MODEL). A folder is just a folder.

The pod abstraction matters because:

- Pods compose. A deployment is a pod; a sub-platform within the deployment is a pod; the kit itself is a pod. Each level operates by the same governance shape, recursively.
- Pods are independently auditable. The validate skill can be run against any pod and produce a meaningful scorecard, regardless of how deeply nested.
- Pods are independently transferrable. A pod can be handed off, archived, or split without coordination overhead because its governance scaffolding makes its state legible to any capable operator.

The folder anti-pattern: a directory of artifacts without governance scaffolding. Such directories require oral history to understand; they do not transfer; they cannot be audited as a unit; they accrete cruft.

The principle to teach: any unit you want to operate, transfer, or audit independently is a pod. Make it one explicitly: add the BACKLOG, the decisions/, the sessions/, the HANDOFF. The governance scaffolding is what makes a folder a pod.

## How the kit accomplishes 100% of intent in a new environment

Five mechanisms compose to produce reliable landings without operator supervision after deployment:

### 1. The hard gate

Forces operator engagement at the only moment it matters: when localization values are being captured. After the gate, the operator can step away; the kit operates by captured answers.

### 2. The worked example

The deployed instance has a literal reference for "what good looks like." When validate runs and produces findings, the deployed instance can compare its current state against the worked example and identify specific gaps without needing operator interpretation.

### 3. The refusal-encoded skills

Each kit-native skill encodes specific refusal conditions. The deployed instance cannot "accidentally" violate the standard because the skills refuse the violation rather than warning about it. The operator does not need to be present to enforce the standard; the skills do.

### 4. The failure-mode catalog

The seven named failure modes give the deployed instance a named set of patterns to detect. When the validate skill scans, it knows what shapes to look for. The catalog is the kit's institutional memory of what goes wrong; the deployed instance inherits this memory.

### 5. The self-update protocol

Long-running skills re-read BOOTSTRAP-BRIEF.md at the start of every invocation. The standard cannot drift silently because the skills re-anchor on each use. If the brief evolves (a new failure mode is named, a new behavior trigger added), the deployed instance picks it up at next session-start.

Together: the operator interacts at landing; the skills enforce the standard during operation; the deployed instance audits itself against the worked example; failure modes are named and detected; the standard re-anchors continuously.

The kit accomplishes 100% of its intent because intent is fully encoded into the kit's own behavior. Nothing is left to operator memory.

## How the kit builds out its ecosystem

A landed instance is a pod. The pod's existence enables further pod creation (sub-platforms, downstream consumers, adjacent functions). The kit equips the deployed instance to spawn this ecosystem:

### 1. Templates as pod templates

The L5 template can be re-applied to add new platforms. Each new L5 dossier follows the same shape; cross-platform participation declarations slot into the existing L7-glue artifact.

### 2. Kit-mirror as ecosystem mechanism

The deployed instance can become a source kit for downstream sub-platforms. The architect-kit-mirror skill handles mirror chains; downstream consumers mirror from the deployed instance the way the deployed instance mirrors from the source kit.

### 3. Inbox-outbox as cross-pod coordination

The architect-inbox-flow skill declares pairs as new pods come online. Each new pod adds inbox-outbox pairs to relevant adjacent pods; coordination scales without meetings.

### 4. ADR practice as decision-archive

As the ecosystem grows, decisions multiply. The architect-adr skill scaffolds ADRs at the right pod scope (instance ADR, cluster ADR, portfolio ADR). The archive serves the ecosystem's collective memory.

### 5. Validate as ecosystem-wide audit

The validate skill can run against any pod. As the ecosystem grows, periodic validate passes across pods produce ecosystem-level maturity reports. The MATURITY-SCORECARD shape composes: a portfolio scorecard rolls up cluster scorecards which roll up instance scorecards.

The kit provides the ecosystem-building primitives; the deployed instance uses them; the ecosystem scales by repeated application of the same patterns.

## How the kit is repeatable hundreds of times without supervision

The design constraint behind every mechanism. Five properties make repeatability work:

### 1. Polymorphism via localization, not customization

Each landing differs only in the 10 captured answers. The kit's structure (templates, skills, brief) is invariant. Operators do not customize the kit per landing; they answer the questions and the kit customizes itself. This means the operator does not need to remember per-landing differences.

### 2. Self-containment

No external dependencies. The kit lands on any environment; no per-environment setup; no operator-side configuration outside the 10 questions.

### 3. Refusal-encoded skills

The kit refuses violations of its own standard. The operator cannot create weak landings even by trying; the skills will not let them. This makes the kit operator-mistake-tolerant.

### 4. Self-fractal as quality assurance

The kit's own pod is the simplest test case for the kit's own skills. Every kit revision is implicitly tested by the kit being able to re-pass its own validate. This catches drift without explicit testing infrastructure.

### 5. Doc Lifecycle as drift detection

Every artifact carries Last-reviewed and Review-cadence frontmatter. Stale artifacts surface in the audit. The kit's own staleness is visible to anyone running validate against it.

Together: localization handles per-environment variation; self-containment removes environmental dependencies; refusal-encoded skills make operator-mistakes-recoverable; self-fractal QA catches drift; Doc Lifecycle surfaces staleness. The kit can land hundreds of times because no specific landing requires the creator's attention.

## How to teach this

Three levels, each appropriate for a different audience.

### Level 1 (executive / sponsor): the two cardinal insights + the Iron Man test

Anyone who needs to understand why the kit exists and what success looks like. Five-minute explanation.

- Insight 1: implicit decisions cost more than explicit ones; name the layers
- Insight 2: completeness used to be expensive; it is not anymore
- Iron Man test: deployed instance can read the brief, answer 10 questions, produce a populated mature instance, refuse to overclaim, begin operating. Pass or fail; no in-between.

### Level 2 (operator who will run deployments): plus L0-L7 layers + the seven failure modes + the kit-mirror pattern + the localization gate

Anyone who will land the kit in fresh environments. 30-minute explanation plus a guided first deployment.

- The eight layers and what each captures
- The seven named failure modes and their triggers
- The kit-mirror pattern and why one-way
- The 10-question gate and why mandatory
- Walking through the worked example end-to-end as the canonical "what good looks like"

### Level 3 (operator who will adapt or extend the kit): plus full TERMS.md + this PHILOSOPHY.md + the kit's own ADRs + Recursive Engine V2 vision

Anyone who will modify the kit, build new skills, or eventually own the V2 transition. Multi-session learning; expect them to deeply read the kit's own pod (its ADRs, its session logs, its BACKLOG) to understand how the kit governs itself.

- Every term in TERMS.md, alphabetical
- Every philosophical position in this document
- Why each kit-side ADR (ADR-0001, ADR-0002, ADR-0003) decided as it did
- The V2 vision (Recursive Skill Optimization & Scaffolding Engine in AI-Architect/BACKLOG.md) and what V1 produces as inputs to V2

### Teaching artifacts the kit ships for each level

- Level 1: BOOTSTRAP-BRIEF Section I (cardinal concepts) + Section XVI (Iron Man test)
- Level 2: BOOTSTRAP-BRIEF Sections I-XV + the worked example + this document's "Why mandatory localization questions" + "Why mandatory L7 awareness" + "Why one-way mirror"
- Level 3: TERMS.md + PHILOSOPHY.md + decisions/ADR-0001 through ADR-0003 + sessions/ (build chunk session logs as worked examples of session-log discipline)

## What to teach about the limits

Teach honestly about what V1 does not yet do.

### V1 cannot self-evolve.

The kit does not learn from each deployment. Patterns the operator notices across deployments stay operator-side until V2's recursive engine consumes them. V1 produces the inputs V2 needs; V2 is where compounding lives.

### V1 cannot deploy itself recursively.

The kit deploys instances; it does not deploy other kits. Mirror chains exist (kit -> instance -> sub-platform) but each link is a separate deployment event. V2 generalizes this.

### V1 assumes a Cowork-shaped runtime.

Skills ship in Cowork SKILL.md format. Other runtimes (Claude Code, Codex, Cursor, etc.) require format adaptation. The mechanism for adaptation is V2's environment-profile concept; V1 is single-target.

### V1's Iron Man test is binary.

Some deployment contexts may want a softer threshold (e.g., "land at 70% mature; mature the rest in next two sprints"). V1 does not support this; the binary criterion is by design. V1.x may revisit if real deployments produce evidence the binary is too strict.

### V1's filter-rule scope is narrow.

The 5 excluded skills (scotland-trip-researcher, arch-design-advisor, arch-scout, owner-design-mgr, tx-real-estate) were filtered for the MarTech-shaped first deployment. Other deployment shapes may need different filters. V1 does not yet have a filter-rules-per-deployment mechanism; V2 generalizes.

Teach these limits not as caveats but as roadmap. They are the things V1 explicitly does not try to do because doing them would require V2-shaped infrastructure that does not exist yet. V1's value is not what it does not do; V1's value is what it does, reliably and repeatably.

## Cross-references

- `TERMS.md` - the named-mechanisms glossary; the what to this document's why
- `BOOTSTRAP-BRIEF.md` - the operating-model standard the deployed instance follows
- `QUESTIONS.md` - the 10 mandatory localization questions
- `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
- `sessions/` - kit build session logs (chunks A, B, C, D+E, F) as worked examples of session-log discipline
- `skills/` - the 43 skills (25 Cowork + 3 AI-Architect mirrored + 4 security + 11 kit-native)
