---
name: Recursion Patterns - V1 Build Observations
description: Captures the patterns observed during the V1 (and V1.1) build that are inputs the V2 recursive engine will need. Distinguishes parametric patterns (substitute and ship) from structural patterns (require different shape per environment); names which questions are locked-by-architecture vs. locked-by-content; documents mirror-chain reasoning, multi-file skill handling, and format-target observations. Written while build context is fresh; addendum after first real deployment lands.
type: meta-observation
---

# Recursion Patterns

- **Last reviewed:** 2026-05-01
- **Review cadence:** on-event (refresh after each new deployment lands; addendum on V1.x patches; major revision when V2 begins)
- **Status:** active (V1.1; will receive addenda as deployments land)

This document captures patterns observed during the V1 + V1.1 build of the deployment kit. Its purpose: serve as input to the V2 Recursive Skill Optimization & Scaffolding Engine when V2 work begins. The patterns named here are what V2 will need to generalize, parametrize, or handle as structural variation.

This is **not** a how-to for V2; it is an observation log for V2's design phase. V2 will be its own ADR + project plan; this document feeds it.

## Why this document exists

Every successful methodology kit has a moment when it becomes worth generalizing across many target environments rather than landing manually one at a time. V2 (the Recursive Skill Optimization & Scaffolding Engine, named in `AI-Architect/BACKLOG.md`) is that moment for this kit. V2 cannot be designed without evidence from V1+V1.1 deployments; this document captures the build-side evidence so V2 has it ready when needed.

The trigger for V2 design (per `AI-Architect/BACKLOG.md`): activate when extrapolation events compound (currently 0 deployments; trigger threshold 3+).

## Section 1: Parametric patterns (substitute and ship)

These are patterns that V2 can handle by simple parameter substitution. Same shape; different values.

### Placeholder tokens

The V1 worked example uses `{{cutting_edge_saas_company}}`, `{{platform_team_name}}`, `{{exec_vp_revops}}`, `{{idp_name}}`, etc. Every token has a semantic flavor + reads concrete + substitutes cleanly. V2 can take the worked example and re-render with different token values per target environment.

Pattern: any noun that the operator's localization answer determines is parametric. Names of orgs, teams, people, tools, vendors, regimes.

### ADR template

The ADR shape (Date, Status, Reversibility, Deciders, Scope, Context, Decision, Options, Rationale, Consequences, Reproducibility note, Cross-references) is universal across deployments. Every ADR substitutes specific content into the same shape.

V2 implication: the ADR template is one of the most stable parts of the kit. V2 can treat it as a fixed asset; the variation across deployments is the content of individual ADRs, not the template shape.

### Session log template

Same observation as ADR template. The session-log shape (What this session was, What was produced, Decisions made, Findings, State changes, Concurrent-actor notes, Handoff posture, Failure modes encountered, Session metadata, Cross-references) is universal. V2 inherits.

### Skeleton of every layer template

The L0-L7 layer templates each have: frontmatter, maturity self-assessment table, content sections that map to localization-question answers, inheritance and dependencies section, cross-references section. The skeleton is universal; the content sections vary per layer.

V2 implication: the skeleton is parametric; the per-layer content slots are where structural variation enters.

### The 10-question orientation base set

The base set (Q1 function identity + function-mode; Q2 sponsor + metric; Q3 customer / disclosure / voice; Q4 red lines / PII / HITL; Q5 framework contract; Q6 platform-kit posture + org-local-skill-repo; Q7 instances; Q8 cross-platform glue; Q9 compliance + tooling; Q10 governance + rhythms) reads cleanly across deployment shapes. Operators in Cowork, Airtable+Hyperagent, Codex, Cursor would all answer these.

V2 implication: the base set is parametric across target environments. Follow-up questions are where structural variation enters.

### Maturity scale + relationship classification

The four-step maturity scale (none / stubbed / partial / mature) and the two-step relationship semantics (live / declared-but-inactive) are universal. Every deployment uses these.

V2 implication: the audit vocabulary is parametric.

### The seven named failure modes

Path-to-layer pattern matching, binary existence checks, missing L7 awareness, static inventory vs. assessment, overclaimed completeness, floating concepts, untested relationships. These are universal across functions and target environments.

V2 implication: the failure-mode catalog is parametric. New failure modes may surface in deployments and add to the catalog (V1.1 added "lax post-landing operation" and "fixed-question-set rigidity" as observations); V2 inherits the catalog and can extend.

## Section 2: Structural patterns (require different shape per environment)

These are patterns where parameter substitution is insufficient; the shape itself varies.

### L1 N/A vs. populated

For internal functions (`internal-tool`, `internal-platform`, `external-api`), L1 is N/A-explicit. For customer-facing functions, L1 is populated with disclosure posture + voice + attribution. The branching is structural; parameter substitution cannot produce N/A from a populated template or vice versa.

V2 implication: V2 cannot just substitute values into L1; V2 must select between the N/A-explicit branch and the populated branch based on Q1 function-type.

### L4 platform-kit posture branching

The L4 template has five branches (greenfield / partial-internal / mature-internal-mirror / mature-external-mirror / mirror-this-kit). Q6's posture answer selects which branch renders; the other four do not appear in the deployed instance's L4 artifact.

V2 implication: structural selection by Q6 token. V2 must implement branch-selection logic, not just substitution.

### Function-mode template weighting

A `building` deployment renders L4 in full; a `deciding` deployment renders L4 as inherited or N/A; a `creating` deployment weights L4 toward asset library + brand kit + content templates with light L3 unless the operation is regulated. The templates are the same; their relative emphasis differs.

V2 implication: V2 needs a weighting layer that emphasizes templates per function-mode. Not just rendering; selective emphasis. Likely implemented as per-function-mode template profiles.

### Number of L5 instances

The worked example has three platforms (mql-enrichment-service, mql-router, sdr-handoff-helper). A different deployment might have one platform; another might have ten. The template per L5 dossier is parametric; the count and the inter-instance handoff topology is structural.

V2 implication: Q7's answer determines the L5 cardinality and the handoff envelope topology. V2 cannot fix one shape; must adapt to the count.

### Compliance regime structural variation

GDPR vs. SOC 2 vs. HIPAA vs. FedRAMP each impose different obligations on L2 + L3 + L7. The compliance posture artifact's content varies non-trivially across regimes; not a simple substitution.

V2 implication: V2 must include regime-specific obligation libraries (the architect-compliance skill's domain). Each regime is a structural variation of the L2 compliance section.

### Org-local skill repository handling

Whether an org has a local skill repository or not changes the deploy skill's behavior at Phase 3 substantially. With one: recursive population, mirror posture, precedence rules. Without: kit-bundled defaults only. Parameter substitution cannot produce both behaviors from one path.

V2 implication: Q6's org-local-skill-repository answer selects between two structurally different deploy paths. V2 must handle both.

### Format-target translation

Cowork SKILL.md format (`name:` + `description:` only) vs. Claude Code SKILL.md format (`name:` + `description:` + `triggers:` list) vs. eventual Codex / Cursor / other formats. The skill content is parametric; the wrapper shape is structural.

V2 implication: V2 must include a format-target translation layer that wraps the same skill content in the right shape per target. Not just substitution; structural transformation.

## Section 3: Question-locked-by-architecture vs. question-locked-by-content

The 10 base-set questions split into two classes that V2's recursion rules must distinguish.

### Question-locked-by-architecture

These questions parameterize the entire deployed instance's structure, not just one artifact's content:

- Q1 function-type and function-mode: drives L1 N/A-vs-populated; drives template weighting
- Q6 platform-kit posture: drives L4 branch selection
- Q6 org-local-skill-repository: drives Phase 3 deploy-skill behavior selection
- Q7 instance count + scope: drives L5 cardinality and handoff topology
- Q9 regulatory regimes: drives L2 + L3 + L7 compliance shape
- Q10 governance shape: drives instance root, ADR location, frontmatter conventions
- Q10 organizational rhythms: drives Doc Lifecycle cadence alignment

Recursion rule for these: structural selection logic; not substitution.

### Question-locked-by-content

These questions populate fields within already-determined shapes:

- Q2 sponsor + metric: content for L0 strategy artifact
- Q3 customer + disclosure + voice: content for L1 (when L1 is populated)
- Q4 red lines + PII + HITL: content for L2 philosophy
- Q5 framework contract numerics: content for L3 telemetry + cost ceiling

Recursion rule for these: parametric substitution.

V2 implication: V2 must classify each base-set question and apply the appropriate rule. Mixing the two produces wrong outputs (substituting into a structural decision; or selecting between branches based on content variation).

## Section 4: Mirror-chain reasoning

V1 surfaced that mirror is a recursive concept. Real chains exist:

- Source kit (`AI-Architect/skills/architect-audit/`) -> deployment kit (`deployment-kit/skills/architect-audit/`)
- Deployment kit -> deployed instance (`{instance}/kit/skills/architect-audit/`)
- Deployed instance -> sub-platform within the instance (`{instance}/platforms/{platform}/skills/`)

A change at the top of the chain cascades down through the chain. Each link has its own sync cadence and conflict-resolution path.

V1.1 added a sixth posture to L4 (org-local-skill-repository takes precedence over kit-bundled), which extends the chain another link.

V2 implication: V2's recursion rules must reason about chains, not just pairs. When V2 generates a target-specific kit, the chain becomes: V2 source library -> generated kit -> deployed instance -> sub-platform. V2 itself is at the top of the chain.

## Section 5: Multi-file skill handling

V1 inventory showed eight skills with 3+ files (xlsx 54, docx 61, pptx 59, skill-creator 18, pdf 12, canvas-art-styles 9, airtable-scripting 7, game-artist 3) plus ~14 skills with `references/` subfolders. V1's Chunk F preserved directory structure during copy.

V1.1 adds the org-local-skill-repository recursive population (Q6 + ADR-0006). The deploy skill must handle multi-file org-local skills the same way (preserve directory structure; handle precedence per-file, not per-skill).

V2 implication: V2's engine cannot assume one-skill-equals-one-file. Skill-scope is the directory, not the SKILL.md file. Mirror-chain reasoning applies at directory granularity.

## Section 6: Cardinal-insight evolution

V1 had two cardinal insights: "make implicit decisions explicit" and "marginal cost of completeness compressed." V1.1 added the third: "learning is the process; first scaffold is intense, later ones adapt."

V1.1's third insight changes the kit's lifecycle from one-shot to continuous. This is more than a parameter; it is an architectural property.

V2 implication: cardinal insights have force. V2 should not assume V1+V1.1 captured all the insights that matter. Future V1.x patches may add new insights as deployments surface them. V2 must handle insight-evolution as a parametric input (here are the cardinal insights at this version; recurse against them).

## Section 7: Failure modes encountered during V1 + V1.1 build

Failure modes that surfaced during the build itself, caught by the discipline encoded in BOOTSTRAP-BRIEF Section XI, and corrected:

### V1 build (Chunks A-F)

- **Static-inventory-vs-assessment risk** (Chunk A): initial SKILL-INVENTORY listed skills without ship/skip decisions. Caught and rewritten.
- **Path-to-layer pattern matching risk** (Chunk A): initial scope inferred the skill universe from `AI-Architect/skills/` folder rather than the operator's actual reachable knowledge set. Caught when operator surfaced the 50-skill Cowork panel.
- **Overclaimed completeness risk** (Chunk C): initial MATURITY-SCORECARD draft marked L4 as `mature` despite simulated 14-day mirror drift. Caught; demoted to `partial`.
- **Floating concept** (Chunk C): initial handoff-protocol draft mentioned "envelope versioning" without tying to a specific schema. Caught; named the schema.

### V1.1 build (this revision)

- **Wrong-altitude discipline encoding**: V1's fixed-10 question gate was the right discipline (no silent skips, concrete answers, honest unknowns) at the wrong altitude (one-shot rather than recursive). The discipline carries forward; the altitude moves. Caught when the operator framed the recursive question discipline.
- **V1 vs. V2 burden misallocation**: V1 framing put adaptation in V2's column; "learning is the process" is a property V1 needs, not a feature V2 adds. Caught when the operator surfaced the third cardinal insight.

V2 implication: the failure-mode catalog evolves. V1.1 added two failure-mode-equivalent observations (wrong-altitude discipline, V1-V2 burden misallocation); V2 will likely surface more.

## Section 8: What V2 specifically inherits

The minimum V2 needs from V1+V1.1 to begin design work:

1. **The kit's structure**: BOOTSTRAP-BRIEF + QUESTIONS + templates + worked example + skills as the base assets V2 takes as input
2. **The maturity + relationship vocabulary**: V2's audits use the same scale
3. **The named failure modes**: V2's recursion rules respect these as classes-of-failure-to-detect
4. **The parametric vs. structural classification** (Sections 1-2 of this document)
5. **The question-locked classification** (Section 3)
6. **The mirror-chain reasoning** (Section 4)
7. **The multi-file skill handling rules** (Section 5)
8. **The continuous-rescaffolding property** (Insight 3): V2's generated kits inherit this; V2's own engine should rescaffold against deployment evidence

What V2 must add (not inherited from V1+V1.1):

- An environment-profile schema (per-target environment variables; YAML or similar)
- A scaffolding-rule library (per pattern in Sections 1-2, the rule that handles it)
- An optimization loop (generate kit; deploy; observe; refine rules; iterate)
- A target-format translation layer (Section 2 last item)
- A regime-obligation library (Section 2 compliance item)

## Section 9: Open questions for V2 design

Things this document does not yet answer; V2 design will address:

- Does V2 generate complete kits per target (full zip), or kit-patches against a base kit (smaller delta)?
- Does V2 update its scaffolding rules continuously (each deployment teaches the engine) or in batched releases (engine v2.1, v2.2)?
- Does V2 itself rescaffold? (Per Insight 3, probably yes; but the recursion goes one level deeper, which raises governance complexity)
- Does V2 ship as a skill bundle inside Cowork (matching V1 distribution shape), or as a standalone tool?
- How does V2 handle insights that surface mid-deployment (a new cardinal insight emerges; existing deployments need to absorb it)?
- How does V2 handle target environments that did not exist at V2 design time (e.g., a new agent runtime ships)? Plug-in architecture for new format-targets?

These are V2's design questions, not V1.1's. They are listed here so V2 design has them ready.

## Cross-references

- `BOOTSTRAP-BRIEF.md` Section I (cardinal insights)
- `QUESTIONS.md` (the orientation base set + recursive follow-up patterns)
- `templates/README.md` (rendering order + question-to-template maps)
- `decisions/ADR-0001-polymorphic-single-kit.md` (V1 architecture; defers V2)
- `decisions/ADR-0004-recursive-question-discipline.md` (V1.1 question discipline)
- `decisions/ADR-0005-continuous-rescaffolding.md` (V1.1 architectural shift; defers V2 to a different role)
- `decisions/ADR-0006-function-adaptation.md` (V1.1 adaptation behaviors)
- `BACKLOG.md` Recursive Engine V2 prerequisites entries
- `AI-Architect/BACKLOG.md` Recursive Skill Optimization & Scaffolding Engine entry
