---
name: Question Discipline
description: The kit operates by extensive recursive questioning, not a fixed gate. This document defines the first-scaffold orientation base set (around ten questions covering the eight layers + governance shape + function adaptation), the follow-up patterns that recursive question discipline produces, and the rescaffold question patterns for subsequent scaffolds. Supersedes the prior fixed-10 framing.
type: standard
---

# Question Discipline

- **Last reviewed:** 2026-05-01
- **Review cadence:** on-event (refresh when a question consistently produces unproductive answers, when a new layer pattern requires localization, when rescaffold experience shows a base-set question is missing or redundant)
- **Status:** active (V1.1; supersedes the V1 fixed-10 framing)

## What changed from V1

The V1 framing was "10 mandatory localization questions; refuse to land until all are answered." That was the right discipline at the wrong altitude. The questions are not a one-shot gate; they are the orientation base set for the first scaffold, and the kit asks extensively and recursively from that base both at first scaffold and on every subsequent rescaffold.

Specifically:

- **V1 framing:** 10 questions, fixed; gate refuses landing until all answered; defaults inform but do not skip
- **V1.1 framing:** ~10 orientation base questions at first scaffold; recursive follow-ups freely as discovery surfaces new gaps; rescaffold cycles ask whatever the surfaced triggers require; defaults still inform; honest unknowns still first-class

ADR-0004 records this supersession of ADR-0003. The discipline carries forward; the altitude moves from "one-shot gate" to "ongoing conversation."

## How the kit asks questions

Three modes, each with its own posture.

### Mode A: First-scaffold discovery

The first time the kit lands in an environment. The discovery skill drives.

- Asks the orientation base set (below) one question at a time
- Explains its purpose progressively as it asks (the kit names what each answer will shape; this is teaching while asking)
- Spawns follow-up questions when an answer reveals another gap (e.g., a Q1 answer that names a customer-facing function spawns L1-disclosure follow-ups)
- Captures honest unknowns as `unknown - {reason}` with rescaffold trigger appended
- Ends with a populated initial scaffold and a rescaffold trigger queue

Typical first-scaffold runtime: 30 to 90 minutes depending on function complexity and how many follow-ups the base set spawns.

### Mode B: Operating-mode follow-ups

After the first scaffold, the kit continues asking opportunistically. Every session is potentially an opportunity to ask a follow-up that closes an open gap.

- A finding in a session log that names a previously-unknown answer triggers a follow-up
- A drained inbox entry that requires a decision triggers an ADR-scaffolding question set
- A new platform coming online triggers L7 participation questions
- A regulatory review triggers compliance follow-ups

These do not require a dedicated rescaffold session; they fold into operating-mode work.

### Mode C: Rescaffold-mode questions

When a rescaffold trigger fires, the kit revisits the affected scope with targeted questions:

- An L4 mirror sync drift triggers Q6-equivalent (kit posture) and L4-template-derived follow-ups
- An L7 concern moving to `unknown` triggers Q8-equivalent (cross-platform) follow-ups
- A sponsor change triggers Q1, Q2, Q10-equivalent (function identity, sponsor, governance shape)
- A regulatory regime activation triggers Q4, Q5, Q9-equivalent (red lines, framework contract, compliance)

Rescaffold-mode questions are a subset of the base set plus targeted follow-ups; not the full base set re-asked.

## The first-scaffold orientation base set

Around ten questions covering the eight layers, governance shape, and function adaptation. The base set is **not exhaustive**; the discovery skill spawns follow-ups freely. It is the orientation surface from which extensive questioning proceeds.

For each base question: the question text, the acceptance criteria for a real answer (concrete tokens or values), the default suggestion if any, and the follow-up patterns the question commonly spawns.

If the operator genuinely cannot answer a question, the captured answer is `unknown - {reason}` and the layer lands as `none` with a rescaffold trigger.

---

### Q1. Function identity (and function-mode adaptation)

**Question.** What is the function being deployed? Give it a name, a one-sentence purpose, a type, and your function-mode (what you primarily do).

**Acceptance criteria.**

- Name (kebab-case token)
- One-sentence purpose
- Type from this set:
  - `internal-tool` - used by employees only
  - `customer-facing-ai` - produces output users see
  - `b2b-platform` - sells to other businesses
  - `b2c-product` - sells to end consumers
  - `internal-platform` - serves other internal teams
  - `external-api` - third parties consume programmatically
  - `mixed` - explicit combination, name the dominant type
- Function-mode (the user's primary working stance) from this set:
  - `building` - actively constructing new capability (eval baselines, reproducibility gates load-bearing)
  - `operating` - running an existing process; not building (L0 + L7 + inbox-outbox load-bearing)
  - `deciding` - decision-rich function; ADR practice load-bearing (lighter on platform-kit work)
  - `creating` - content-driven; producing a series, a campaign, or pieces moving from draft to publish; brand-voice + review/approval + rights-handling load-bearing
  - `mixed` - name the dominant mode plus the secondary

**What gets locked.** L0 instance name; type drives default L1 posture; function-mode drives the relative weight of templates and skills the deployment leans on.

**Default suggestion.** None - must be answered.

**Common follow-ups.**

- For `customer-facing-ai` or `b2b-platform`: customer segment specifics, surface inventory (Interface, dashboard, email, etc.)
- For `building`: existing eval coverage, prompt library shape
- For `operating`: current process owner, existing rhythms (daily standup, weekly review)
- For `mixed`: which mode dominates this scaffold; the other gets follow-up later

---

### Q2. Sponsor and success metric

**Question.** Who sponsors the function inside the organization? Where does the funding come from? What is the single most-important success metric?

**Acceptance criteria.**

- Named sponsor (role or person)
- Funding source (department, cost center, project budget)
- One quantifiable success metric (a number; "high engagement" is not a metric; "MAU growth >= 12% QoQ" is)
- Tiebreak rule if multiple metrics genuinely tie

**What gets locked.** L0 strategy; the sponsor is the escalation path; the metric is the L0 north star that L3 eval thresholds derive from.

**Default suggestion.** None - must be answered. This is the question prior kits were laxest on; weakest landings traced back to it.

**Common follow-ups.**

- Where is the metric measured (dashboard path, query, manual report)?
- Cadence of metric review with sponsor (weekly, monthly, quarterly)?
- Has the metric changed in the last quarter (signal that L0 may be unstable)?

---

### Q3. Customer, disclosure, and voice

**Question.** Who uses the function's output? How does it disclose itself as AI (or not)? What tone does it carry?

**Acceptance criteria.**

- Customer segment description (one to two sentences)
- Disclosure posture: `visible` / `invisible` / `branded` / `attributed` / `n/a-internal`
- Tone shorthand (3 to 5 adjectives, or a named-style reference)

**What gets locked.** L1 brand posture. For internal functions answering `n/a-internal`, the kit lands L1 as `N/A-explicit`, not as `none`.

**Default suggestion.** For `internal-tool` types from Q1, default disclosure is `n/a-internal` with explicit marking. Operator must accept or override.

**Common follow-ups.**

- What surfaces does the output appear on (Interface, Slack message, email, record field)?
- Is there an existing brand voice guide to inherit from?
- Decline copy: what does the function say when it cannot answer?

---

### Q4. Red lines and human-in-loop

**Question.** What does every output of this function never do? How is PII handled? Where is the human reviewer placed in the loop?

**Acceptance criteria.**

- At least three concrete named red lines (specific behaviors, not vague principles)
- PII rule: `pii-prohibited` / `pii-redacted` / `pii-tenant-only` / `pii-permitted`
- HITL placement: `input-gate` / `mid-loop` / `output-gate` / `sample-review` / `none`

**What gets locked.** L2 philosophy; drives every guardrail definition downstream and the L3 contract on PII handling.

**Default suggestion.** None - must be answered.

**Common follow-ups.**

- For each red line: enforcement mechanism (input guardrail, prompt instruction, output check, post-hoc audit)?
- For `sample-review`: what percentage; who reviews; how is review captured?
- For PII rules: detection mechanism (regex, ML classifier, policy-based)?

---

### Q5. Framework contract

**Question.** What technical contract does every component implement? Eval methodology, per-call cost ceiling, minimum telemetry, auth model.

**Acceptance criteria.**

- Eval methodology: `llm-judge` / `human` / `synthetic` / `hybrid` / `none-yet` (with closes-by date)
- Per-call cost ceiling in dollars (a number)
- Minimum telemetry fields (the reproducibility quadruple is the floor)
- Auth model: `none` / `api-key` / `oauth` / `mtls` / `tenant-scoped-jwt` / etc.

**What gets locked.** L3 framework contract; every L5 instance inherits from it.

**Default suggestion.** Eval default `none-yet` with closes-by inside 60 days. Cost ceiling default = the 90th-percentile from comparable workloads. Telemetry default = the reproducibility quadruple. Auth default = the org's standard SSO-derived pattern.

**Common follow-ups.**

- For `none-yet`: who builds the eval, by when, against what dataset?
- For cost ceiling: how is breach detected; what is the action?
- For telemetry: where does it land; retention?

---

### Q6. Platform kit posture (and organizationally-aware skill discovery)

**Question.** Is there an existing platform kit you draw from? If yes, where is it; what's the mirror direction? Does the organization have a local skill repository the deployed instance should populate from before defaulting to kit-bundled skills?

**Acceptance criteria.**

- Posture: `greenfield` / `partial-internal` / `mature-internal-mirror` / `mature-external-mirror` / `mirror-this-kit`
- For mirror postures: source path
- Organizational skill repository: `exists at {path}` / `does not exist` / `unknown`

**What gets locked.** L4 platform kit posture; drives whether deploy scaffolds, mirrors, or extends. The org-skill-repository answer drives the recursive skill population at landing.

**Default suggestion.** For first deployments in a fresh environment: `greenfield`. For org-skill-repo: `unknown` with rescaffold trigger to investigate.

**Common follow-ups.**

- For mirror postures: re-sync cadence; conflict resolution path; existing kit-mirror discipline?
- For org-skill-repo `exists at {path}`: which skills there are relevant; should they take precedence over kit-bundled equivalents; what's the mirror direction (org repo -> deployed instance, one-way pull)?
- For greenfield + org-skill-repo `does not exist`: the deployed instance becomes the seed for an org skill repo (V2 question; surface as future opportunity)

---

### Q7. Instances in scope

**Question.** What L5 instances does this deployment cover? Enumerate them with one-line purpose each.

**Acceptance criteria.**

- A list of one or more named instances
- Each has a kebab-case name and a one-sentence purpose
- If "one instance, this function is the instance," answer that explicitly
- If "many instances, scope unclear," the kit forces a scoping conversation

**What gets locked.** L5 scope; determines how many instance dossiers the deploy skill creates.

**Default suggestion.** None - must be answered.

**Common follow-ups.**

- For multi-instance: do instances pass envelopes (handoff protocol active)?
- For multi-instance: which instances participate in which L7 concerns?
- For "scope unclear": what are the candidate instances we should include; what are the exclusion criteria?

---

### Q8. Cross-platform glue (L7)

**Question.** What crosses instances? Specifically: shared memory, shared identity, handoff protocol, consent flow, alerting fabric, monitoring base.

**Acceptance criteria.**

- Per concern: `exists-mature` / `exists-partial` / `declared-not-built` / `none-applicable`
- For `exists-mature` or `exists-partial`: named owner
- For `none-applicable`: one-sentence justification
- `unknown` is **prohibited** at first scaffold; rescaffold-mode may resolve previous unknowns

**What gets locked.** L7 cross-platform glue; the audit table will report L7 with the same six rows the operator answered.

**Default suggestion.** For each concern: `none-applicable` only with justification; otherwise `declared-not-built`.

**Common follow-ups.**

- For `exists-mature`: last-verified-live date; recent drill evidence
- For `exists-partial`: gap; closes-by
- For `declared-not-built`: closes-by; owner who will build

---

### Q9. Compliance and tooling stack

**Question.** What regulatory regimes apply? What is the existing tooling stack the deployed instance must operate within?

**Acceptance criteria.**

- Regimes from `gdpr` / `ccpa` / `hipaa` / `soc2` / `iso-27001` / `fedramp` / `pci-dss` / `none-applicable` (with reason)
- Cloud(s) named
- Observability platform named
- Serving infrastructure named
- Ticketing / comms named

**What gets locked.** Cross-cutting context for ADRs, telemetry destination, audit trail decisions.

**Default suggestion.** None - must be answered.

**Common follow-ups.**

- For each regime: existing compliance evidence pattern; auditor cadence
- For tooling: existing rhythms (which Slack channels, which Linear projects, which dashboards)
- For tooling: any expected migrations in the next 6-12 months

---

### Q10. Governance shape and existing process integration

**Question.** Where does the deployed instance live? What governance conventions are already in use? How does the function integrate into the existing organizational process (rhythms, meetings, decision flows)?

**Acceptance criteria.**

- Instance root path or notional location
- ADR convention (existing or kit-default)
- Frontmatter conventions
- Concurrent-actor count
- IP boundary
- Existing organizational rhythms: which rituals (standup, weekly review, quarterly planning) the kit's Doc Lifecycle cadences should align to

**What gets locked.** Governance scaffolding; assimilation into organizational process.

**Default suggestion.** Concurrent-actor count default = 1; IP boundary default = `none-stated`. Operator must accept or override.

**Common follow-ups.**

- Existing ADR location and naming convention?
- Existing decision rituals (RFCs, design docs, OKR-driven planning)?
- How are inbox-outbox patterns handled today (Slack channels, shared docs, meetings)?

---

## Captured-answers structure

The discovery skill writes captured answers to `examples/{instance-name}/LOCALIZATION-ANSWERS.md` (or `{instance_root}/LOCALIZATION-ANSWERS.md` in real deployments). The structure includes:

- Each base-question's answer
- Each follow-up question's answer (organized under the base question that spawned it)
- Each honest unknown with rescaffold trigger
- A revision log table tracking how answers evolved across scaffolds

The file is append-only for revisions; prior answers stay on record in the revision log so the deployed instance can trace its own learning.

## Failure modes the question discipline is designed against

These remain unchanged from V1:

- **Path-to-layer pattern matching** - Q1 forces explicit type so the kit does not infer L1 posture from the function's folder location
- **Binary existence checks** - Q6 and Q8 use multi-step posture sets, not yes/no
- **Missing L7 awareness** - Q8 is mandatory and refuses `unknown` at first scaffold
- **Static inventory vs. assessment** - Q5 demands concrete numerics, not field lists
- **Overclaimed completeness** - Q5's `none-yet` for eval is acceptable only with closes-by date
- **Floating concepts** - Q3 tone and Q4 red lines must be concrete, not abstract aspirations
- **Untested relationships** - Q8 `exists-mature` requires named owner

V1.1 adds:

- **Lax post-landing operation** - the V1 framing implied "land cleanly and operate"; V1.1 makes explicit that operating mode includes ongoing question-asking and rescaffold awareness
- **Fixed-question-set rigidity** - V1 made follow-ups feel out-of-band; V1.1 makes them first-class

## Refresh triggers for this document

Update this question set when:

- A first-scaffold landing produces a question consistently answered with unproductive `unknown - we have not thought about this` responses (the question may be wrong-altitude)
- Rescaffold experience shows a base-set question is consistently re-asked because conditions evolve faster than once-per-deployment is enough (consider promoting to per-quarter cadence)
- A new layer pattern emerges that needs base-set localization
- The fundamentals brief revises a layer's scope and the question set must mirror it
- Quarterly minimum

## Cross-references inside the kit

- `BOOTSTRAP-BRIEF.md` - the standard the deployed instance operates by; this question set sources from it
- `templates/` - the layer templates the deploy and rescaffold skills populate from these answers
- `examples/martech-mature-instance/LOCALIZATION-ANSWERS.md` - the worked example's captured answers
- `skills/architect-discovery/SKILL.md` - the recursive question-asking skill that drives Mode A and Mode C
- `skills/deploy/SKILL.md` - the multi-phase orchestrator that invokes discovery
- `skills/architect-rescaffold/SKILL.md` - the skill that drives rescaffold-mode question patterns
- `decisions/ADR-0004-recursive-question-discipline.md` - the V1.1 supersession of ADR-0003
- `decisions/ADR-0006-function-adaptation.md` - the function-mode adaptation in Q1
