Tally
The logging-loop custodian
StatusBuildIn build
Where it stands. In build: its routing, sweep and check mechanisms run today, invoked each session rather than standing on their own yet.
01What it does
01
Keeps the learning loop honest
Work is logged where it happens, and every log names who reads it and when, so nothing captured goes unread.
02
A log nobody drains is a finding
An unread log becomes something Tally raises, not a quiet loss. Each tool keeps its own corpus; Tally audits the loop across them.
02Its place on the control plane
Tally proposes and never writes: it raises what goes unread and hands the loop back to whoever owns it. It sits on the propose plane beside Lathe; both are run by hand today.
03Who it works with
A pairing here means two tools actually exchange something, and the thing they exchange is named.
- HelmGates (Helm's doors are clients of)Helm's corpus=tally log door delegates through Tally's validating gate
- Forge, Mason, LatheGates (coordinators serving lanes it rules)The delivery coordinators for apps/substrates, hubs/sites, and agentic systems respectively
- ConcordConsumes (audited by)Concord audits Tally's own note ↔ protocol ↔ member-table triple like any mapped pair
- ConsoleFeedsThe logging-activity panel renders lane state per Tally's Convention v1
- Every corpus-bearing toolGatesEvery logging door is a client of Tally's gate, though most still write via their own named door pending full per-door delegation
The rest of the Tools
ConsoleThe control roomConcordThe coherence toolGimbalThe allocation optimiserGaugeThe runtime verifierHelmThe orchestratorStewardThe estate operatorMasonThe public-face builderCompassThe demand-intake analyserLatheThe tool-genesis toolManifoldThe model-provider switchLatchThe identity substrateFathomThe live-DB read harnessPrismThe retrieval substrateWardThe credential brokerCourierThe outbound doorSounderThe feedback triageFoilThe adjudication surface