ADR-015: T2S (Transcript-to-Spec) Protocol

Status: Accepted Version: 1.0 Date: 2025-12-21 Supersedes: N/A Related ADRs: ADR-003, ADR-014 Related PRDs: N/A

Context

SEA-Forge™ operates on a foundation of formal specifications. However, domain knowledge often originates as unstructured material:

• Conversation transcripts
• Design notes
• Meeting recordings
• Research papers
• Philosophical reasoning

We need a formalized methodology for extracting architecture specifications from unstructured sources while eliminating ambiguity, narrative drift, and accidental complexity.

Decision

Adopt the T2S (Transcript-to-Spec) protocol as the canonical extraction pipeline for converting unstructured intent into executable architecture specifications.

Definition

T2S (Transcript-to-Spec) is the method of turning messy, chronological “what happened / what we meant” text into a clean, domain-agnostic system specification.

The Eight Stages

T2S is executed explicitly and sequentially:

Stage 1: Extract Primitives

Identify the core building blocks from the source:

• Nouns: entities, artifacts, roles, systems
• Verbs: actions, transformations, validations
• Conceptual objects: constraints, invariants, contracts

Stage 2: Translate Metaphors → Mechanisms

Keep metaphors as helpful labels, but translate them into implementable mechanics:

• “File system as semantic state machine” → “Directory path selects context + dependency set”
• “Semantic ledger / Spec DNA” → “Versioned ontology + invariants”
• “Self-correcting organism” → “Closed-loop feedback → model refactor → regeneration”

Stage 3: Declare Invariants (Anti-Technical-Debt Rules)

Pull out the non-negotiables and restate them as enforceable constraints:

• “Treat prompts exactly like code” → “Prompt artifacts must be linted/versioned/tested”
• “No drift” → “Regenerate downstream artifacts from the spec whenever strategy changes”

Stage 4: Identify the Execution Model

Determine the system’s operational pattern:

• Pipeline
• DAG (Directed Acyclic Graph)
• Compiler stages
• Feedback loops
• State machines
• Event-driven systems

Stage 5: Define Contracts (Inputs/Outputs)

Each unit gets a signature:

• Inputs: Context, dependencies, configuration
• Logic: Instructions, transformations
• Outputs: Artifacts, signals, state changes

Stage 6: Insert Quality Gates

Turn “make it good” into explicit gates that fail fast:

• Validator prompts
• Audit checks
• Isomorphism validation
• Drift detection

Stage 7: Extract Governance & Evolution Model

Capture how the system changes safely over time:

• Feedback loops
• Drift correction mechanisms
• Controlled mutation
• Review/rollback procedures
• Append-only evolution logs

Stage 8: Produce Spec-Ready Building Blocks

Output the structured specification:

• Principles
• Components
• Interfaces
• Workflows
• Test strategy
• Operations/runbooks

Key Invariants of T2S

• Faithfulness: Be faithful to the source’s intent
• Normalization: Remove ambiguity, narrative drift, and accidental complexity
• Domain-Agnostic: Output should be portable to other domains
• Implementation-Ready: Output should be actionable, not philosophical
• Anti-Debt: Explicitly eliminate technical debt by construction

Rationale

Why T2S Matters for SEA-Forge™

1. Knowledge Capture: Domain experts communicate in natural language, not DSLs
2. Traceability: Every spec can trace back to source conversations
3. Evolution: As understanding deepens, T2S can be re-applied to updated sources
4. Consistency: A formalized extraction method prevents ad-hoc interpretation
5. Scalability: T2S can be applied by humans or AI agents following the same protocol

The Closed Loop

T2S creates a closed loop with the rest of SEA-Forge™:

1
Transcript/Source → T2S → Spec → Implementation → Validation → Evolution → New Transcript

The spec is not an endpoint — it’s a waypoint in a continuous refinement cycle.

Alternatives Considered

Manual Spec Writing

Rejected — Introduces interpretation variance; loses traceability to source.

AI-Only Extraction

Rejected — Needs human review for invariant identification and governance decisions.

Document-First (Skip T2S)

Rejected — Unstructured documents contain hidden complexity that causes downstream drift.

Constraints

• MUST execute T2S explicitly and sequentially through all eight stages
• MUST preserve faithfulness to source intent
• MUST remove ambiguity, narrative drift, and accidental complexity
• MUST produce domain-agnostic, implementation-ready output
• MUST support human review for invariant declaration
• MUST NOT skip stages or perform ad-hoc interpretation

Quality Attributes

• Unified methodology for knowledge extraction
• Traceable specifications
• Reduced interpretation drift
• AI-assistable process
• Domain-agnostic outputs

Bounded Contexts Impacted

• Semantic Core
• Specification Pipeline
• Knowledge Layer
• Architectural Governance

Consequences

Positive

• Unified methodology for knowledge extraction
• Traceable specifications
• Reduced interpretation drift
• AI-assistable process
• Domain-agnostic outputs

Negative

• Requires discipline to follow all eight stages
• Source material must be sufficiently detailed
• Human judgment still required for invariant declaration

Additional Notes

Invocation Prompt

The following prompt can be used to invoke T2S on any source:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
## T2S Invocation

Apply your **T2S (Transcript-to-Spec)** process to the attached source.

Treat the source as raw, unstructured intent (transcript / essay / design notes / conversation).

Perform T2S explicitly and sequentially:

1. **Extract primitives** — core nouns, verbs, roles, artifacts, and conceptual objects
2. **Translate metaphors into mechanisms** — restate metaphorical language as concrete, implementable system behavior
3. **Declare invariants (anti-technical-debt rules)** — identify non-negotiable constraints implied by the source
4. **Identify the execution model** — pipeline, DAG, compiler stages, feedback loops, or state machines
5. **Define contracts** — inputs, outputs, responsibilities per component or stage
6. **Insert quality gates and validation mechanisms** — tests, audits, isomorphism checks, drift detection
7. **Extract governance and evolution model** — how the system changes safely over time
8. **Produce spec-ready building blocks** — structured so they can be assembled into a full architecture spec

Be faithful to the source's intent, but remove ambiguity, narrative drift, and accidental complexity.

Output should be **domain-agnostic**, **implementation-ready**, and **explicitly anti-technical-debt**.

Variants

Fast T2S (Extraction Only):

Apply T2S but stop after: primitives extraction, metaphors → mechanisms, invariants. Output only structured bullet points suitable for later spec synthesis.

Full T2S → Architecture Spec:

Apply T2S, then synthesize results into a full architecture spec structured like: Core intent, Non-negotiable principles, System decomposition, Execution model, Contracts, Quality gates, Governance & evolution, Portability.

Related Specifications

• REF-012: Invariant Regime Specification

✅ MVP (core methodology for specification extraction)