Echo Module (EM)

1 · Purpose & Scope

This document turns the Architecture & Design (Phase 3) into an actual build sequence. It answers: in what order, gated by what completion criteria, tested how, documented how, versioned how. It does not revisit interface contracts — those are Phase 3's, settled. Phase 4 is execution.

2 · Milestone Structure

Eleven milestones, each gated on the previous. Full task-level detail lives in the companion Work Breakdown Structure (§9) — this is the shape, not the checklist.

Ordering rationale: data model first (nothing compiles without it), then Source (nothing to fuse), then Fuser (the strongest evidence, and Gate/Calibrator both consume its output), then Gate (needs a FusedState to evaluate), then Calibrator (adjusts Fuser's weights — conceptually downstream of both), then ProvenanceStore and Router (functionally independent of each other, placed last among components since neither blocks the others), then integration and release.

3 · Definition of Done — Binding on Every Milestone

This is the literal enforcement of the Charter's "no placeholders, mock data, or non-functional features" principle — a checklist every milestone must pass, not a value statement.

• Protocol/type fully implemented — no pass, NotImplementedError, or TODO left unflagged.
• Any unavoidable placeholder is explicitly flagged in code with a tracked issue and a removal owner/deadline (Charter §5) — otherwise, zero placeholders.
• Tests specified for that component in Architecture §13 are written and passing.
• Type-checked cleanly (mypy) — no # type: ignore without a one-line justification comment.
• Docstrings complete, citing the exact Charter/Architecture section and reference implementation being formalized.
• A runnable toy example exists in examples/ — fresh code, never copied from a source repo (Charter §6 clean-room policy).
• CHANGELOG updated.
• Any new dependency justified in one line in the commit/PR — the plugin model (Architecture §11) is meant to keep the core small.

4 · Testing Strategy

Per Architecture §13, not generic best-practice filler:

• Fuser — property-based, not just example-based: renormalization sums to 1 over available sources, output invariant to source order, single-source input returns that value unchanged.
• Calibrator — one dedicated regression test asserting OutcomeEvidence cannot be constructed from a corroboration-count or confirmation-flag shape. This test is the anti-pattern guardrail (ADR-0002) — if it can be made to pass with corroboration-shaped input, the guardrail has failed, full stop.
• Gate — fixture-based threshold/override/hysteresis tests, plus one dedicated test asserting no code path exists from GateDecision to ActionAuthorization without an explicit external call (ADR-0003's regression test).
• Source — every reference implementation proves its fallback() returns FALLBACK status, never LIVE, and that a live reading numerically equal to the fallback value is still distinguishable by status field.

5 · Documentation Approach

Docs-as-you-go, not deferred to M9. Every milestone that ships a component ships that component's contract page in the same milestone — M9 is a consolidation and quickstart pass, not the first time documentation gets written. ADRs are written at decision time; the five already recorded (Architecture §14) predate any code, which is the intended order for future ones too.

6 · Versioning & Release

Semantic versioning from the first commit. 0.1.0-dev at M0, incrementing through M1-M9 as a pre-1.0 series (the API may still shift during active component build-out). 1.0.0 is tagged only at M10, once every v1-scoped component (Strategy §2) is complete, tested, and documented — not before. Changelog follows the Keep a Changelog convention.

7 · CI/CD

GitHub Actions, configured at M0 before any component code exists: lint (ruff) + type-check (mypy) + test (pytest) on every push, from the very first commit — not retrofitted once there's code worth breaking. A separate release workflow triggers on version tags. Dependency scanning added at M0 per Risk Register R7.

8 · Repository Structure

echo-module/
├── src/echo_module/
│   ├── __init__.py
│   ├── models.py          # Architecture §3 — core data model
│   ├── source.py          # §4
│   ├── fuser.py            # §5
│   ├── calibrator.py      # §6
│   ├── provenance.py      # §7
│   ├── gate.py             # §8
│   └── router.py           # §9
├── examples/               # fresh toy code only — never source-repo code
├── tests/
├── docs/
│   └── adr/                # ADR-0001 through 0005, and future ones
├── pyproject.toml
├── CHANGELOG.md
├── CONTRIBUTING.md
├── README.md
└── LICENSE                 # choice open — see Risk Register R8, blocks M0

9 · Companion Tracking Artifacts

Three living spreadsheets, updated through Phase 4 rather than written once:

10 · Success Criteria

1. This plan is reviewed and approved by JB.
2. v1.0.0 is released with zero unflagged placeholders anywhere in the codebase — a literal, auditable claim per the M10 DoD audit, not a general impression.
3. The NLnet application is submitted, referencing shipped, working code — not a roadmap.

11 · Governance & Amendment

JB is the sole approving authority. Material changes to milestone order, Definition of Done criteria, or v1 component scope require an explicit, versioned revision here — consistent with every prior phase document.

Echo Module Development & Implementation Plan v1.0 · Draft · Companion to Charter v1.1, Strategy Plan v1.0, and Architecture & Design v1.0