Echo Module (EM)

Strategy Plan · Version 1.0 · Draft · Owner: Jean-Baptiste Decorzent

STATUS: DRAFT — PENDING APPROVAL

Table of contents

1 · Purpose & Relationship to Prior Phases 2 · Component Scope for v1 3 · Access Model — v1 Scope 4 · Entity & Ownership 5 · Funding & Go-to-Market Sequencing 6 · Capacity & Pace — a Binding Constraint 7 · Reference Implementations Carried Into Phase 3 8 · Success Criteria — Gate to Phase 3 9 · Governance & Amendment

1 · Purpose & Relationship to Prior Phases

The Charter (v1.1) defined what Echo Module is and deferred several decisions explicitly to this document: which components ship, in what form, under what entity, funded how, and at what pace. The Phase 1 audit (EM_Candidate_Matrix.md, five Claude Code sessions across all five source repos) supplied the evidence those decisions are made against. This Strategy Plan makes them. It does not specify interfaces, schemas, or code — that is Phase 3 (Architecture & Design). Nothing here proceeds to Phase 3 until this document is approved.

What changed between Charter and Strategy

The Charter named six candidate components and deferred entity/access/funding sequencing pending evidence. Phase 1 supplied that evidence unevenly — some components emerged strongly confirmed, one emerged as the audit's clearest single finding, one emerged as a real but rare pattern, and one emerged as the weakest-evidenced component in the entire program. This Strategy Plan's central job is to let that unevenness actually shape what gets built first, rather than treating all six as equally ready.

2 · Component Scope for v1

Four components ship with high confidence. One ships with a structural guardrail built into its interface. One is deliberately split, shipping only its better-evidenced half.

Component	v1 disposition	Basis
SHIP Source	Full, high confidence	Real in 3/4 systems. Interface must accommodate three distinct structural shapes — co-located fetch+score, split Fetcher/Scorer, agentic/prompt-orchestrated — not assume one. Fallback values must be distinguishable from live values (an explicit `is_fallback`/`source_status` field), per TRAXON's `emtech:latest` finding.
SHIP Fuser	Numeric-weighted mode only	The single strongest evidence in the whole audit — haiva and TRAXON independently converged on the identical renormalize-over-available-sources formula. LLM-mediated sub-mode (sona's temporal synthesis) stays documented, not built into v1: one independent confirmation, one explicit negative finding in a fourth system — insufficient evidence to commit v1 engineering time to it.
SHIP Gate	Full, high confidence	Most production-ready, most convergently-designed component — real in all 4 systems. Binding v1 requirement, not optional: crossing the inform-vs-act boundary must require deliberate, structurally-enforced friction (an explicit, separately-logged authorization object with its own audit trail), never a single boolean flag — per TRAXON's composition-boundary finding, where every individual Gate was conformant and the wired system still wasn't.
GUARDRAIL Calibrator	Ship both proven strategies, with a type-level defense	Real, but rare — 2/4 genuine passes (haiva's clinician-instrument-verified batch refit; TRAXON's trade-outcome-verified continuous shrinkage), against a confirmed, recurring anti-pattern ("confidence accretion on corroboration") that appeared in the other two systems and even inside the two systems that got it right. v1's interface must require an explicit, separately-typed `outcome_verified` input to compute any weight adjustment — a corroboration-only signal must not type-check as Calibrator input. This is a deliberate design response to evidence, not a generic best practice.
SPLIT ProvenanceStore	Attribution-half only in v1; correctness-half deferred to v2	The weakest-evidenced component in the entire program. Attribution (which Source contributed what, when) is real in 3-4 systems — ship it. Correctness-tracking (was it right, once known) is confirmed working in exactly 1 of 4 systems, with the highest remaining engineering cost of any component. Building the least-proven, most-expensive component first is the wrong order given §6. Ship attribution-only, document correctness-tracking as an explicit v2 target, revisit once v1 has real usage to justify the investment.
SHIP Router	Shapes 1 and 3 only	Stakes-proportional escalation (3 independent systems) and cost-gated second opinion (2 independent + 1 corroborating) are the only two of six catalogued shapes with cross-domain confirmation strong enough for v1. Shapes 2/4/5/6 (reliability-fallback, static tiers, persisted-preference, cadence-based) stay documented as candidate variants in Phase 3's design notes — real, but single-system evidence, not built into v1's core interface.

3 · Access Model — v1 Scope

Layer 1 only. No hosted API, no embedded license commitment in v1.

An open-source core release is bounded — shipped, then iterated on JB's own schedule. A hosted API is an unbounded, ongoing operational commitment: uptime, support, security patching, someone available when it breaks. An embedded/commercial license requires a sales motion and contract capacity neither Phase 1 nor this plan has budgeted for. Layers 2 and 3 remain directional intent, exactly as the Charter stated — revisited only once Layer 1 has real adoption evidence to justify the additional, continuous commitment they require, not on a fixed calendar date.

4 · Entity & Ownership

POLEarth SA — selected as EM's entity, per JB's decision.

Current state unchanged from the Charter: JB holds director and signature rights in POLEarth, not shareholding. POLEarth's shareholders have not yet been engaged in conversation about EM. This Strategy Plan does not resolve when that conversation begins — that remains explicitly JB's call, consistent with the Charter's own recorded reasoning (having something demonstrably solid to show before opening the conversation is the stronger position). Worth JB confirming directly: does selecting POLEarth now change that timing, or does the plan still wait for v1 to exist first? Not assumed either way here.

5 · Funding & Go-to-Market Sequencing

Step	Action	Notes
1	NLnet / NGI Zero application — lead move	Equity-free, €5,000–€50,000, no entity or track record required — can proceed in parallel with, or ahead of, the POLEarth conversation (§4), fully decoupled from it. Frame around data sovereignty/portability: LWE's no-captivity ethics, sona's user-owned narrative principle — the Charter's own access-model philosophy, not a repositioning.
2	OSS release of the Layer 1 core (§2 scope)	The deliverable the NLnet application is written against.
3	Digital Public Goods Registry listing	Near-zero cost, real credibility signal for future funders (Botnar-style DPG-seeking philanthropies, UNICEF).
4	Monitor UNICEF Venture Fund	Only relevant once a thematic call matches EM's domain — not itself a scheduling dependency.
5	Wellcome Prize and other InnerEcho-specific opportunities	Tracked separately — these belong to haiva/sona directly, not to EM's own funding path. Do not conflate the two in reporting or planning.

6 · Capacity & Pace — a Binding Constraint, Not a Footnote

This section is load-bearing for every decision above, not a closing remark

This plan assumes founder bandwidth that is not indefinitely available. Every narrowing decision in §2 and §3 — four components shipped with confidence rather than six, one access layer rather than three, one funding lead rather than a scattershot list — is deliberately scoped down because of that constraint, not despite it.

Stated plainly: Phase 1 gave real evidence the underlying idea is sound. The biggest remaining risk to EM is not that the premise is wrong — it's starting a sixth ambitious build on top of five already-unfinished ones, on a schedule that has run 12–18 hours a day, seven days a week, for over two years without pause. v1's job is to be finishable, not maximal. Any future scope addition to this plan — a component moved from "guardrail/split" to "full," a second access layer, a new funding track — should be checked against actual, current capacity at the time, not against enthusiasm at the time of writing.

7 · Reference Implementations Carried Into Phase 3

The concrete artifacts Architecture & Design (Phase 3) formalizes an interface against — not reference material to consult, but the actual basis for the spec:

Component	Reference implementation	Why this one
Fuser	haiva `signal_fusion.py` + TRAXON `conviction_score.py`	Independently converged on the identical formula — cite both, not one
Gate	TRAXON `ks36_monitor.py` + haiva `compute_crisis_level`	Structural inform-vs-act guarantee (return type incapable of expressing approval) plus the most complete threshold/override/hysteresis shape
Calibrator	TRAXON `calibration.py` + haiva `calibrate_formulas.py`	The two genuine outcome-verified passes — continuous and batch-cutover strategies, both valid
Source	LWE `chrome-extension\` job scraper	Most rigorous three-criteria satisfaction found, six independent fallback layers
Point-in-time / no-lookahead discipline	TRAXON `temporal_context.py`	Only system with an explicit, structurally-enforced no-lookahead guarantee
Human-review-of-Gate-output UI	LWE `reconciliation.py` detect→store→human-resolve→re-score loop	The one fully-wired end-to-end instance found in the whole audit

8 · Success Criteria — Gate to Phase 3

This Strategy Plan is reviewed and approved by JB.
The NLnet application is submitted — or a documented decision not to, with reasoning.
The v1 component scope (§2) is treated as binding: Phase 3's Architecture document does not silently expand scope back toward all six components at full strength without an explicit, versioned revision to this plan.

9 · Governance & Amendment

JB is the sole approving authority for this Strategy Plan and any amendment to it, consistent with the Charter's own governance model. Material changes to v1 scope (§2), access model (§3), or entity (§4) require an explicit, versioned revision — not an informal decision made mid-build.

Version	Date	Status	Notes
1.0	September 2026	Draft — pending approval	Initial Strategy Plan, drafted following completion of the Phase 1 audit and agreement on component scope, access model, entity, funding sequencing, and the capacity constraint.

Echo Module Strategy Plan v1.0 · Draft · Companion to Charter v1.1 and EM_Candidate_Matrix.md