feat(substrate): prove a live evidence-to-context loop under an agent

[Sinity]

Outcome

A work-generating agent emits structured evidence into Polylogue while it runs, can query that evidence immediately, and later consumes an evidence-backed context/resume artifact that materially improves continuation of the same work.

That repeated bidirectional use, not the existence of more archive machinery, is the closure condition for moving Polylogue from a downstream evidence archive toward an in-loop substrate.

Current reality

Polylogue already has substantial archive, query, lineage, assertion, recovery, context-pack, MCP, and evidence-ref machinery. It can continuously ingest and reconstruct work from several providers.

The missing outcome is narrower and more important:

• no production first-class provider-neutral work-event write leg is established;
• Hermes work topology is not yet reconstructed from the strongest available state/runtime evidence;
• hook-event materialization has advanced, but complete query projection and coverage are not proven;
• inbound OTLP remains primarily disposable runtime telemetry rather than durable work evidence;
• context/recovery surfaces exist, but repeated in-loop use that changes real work has not been demonstrated.

Do not interpret this issue as permission to build a new general event architecture before testing a terminal loop.

Minimum proving loop

Use one real agent/runtime and one real project task:

1. Emit: the runtime records a bounded typed set of work events through Polylogue's current source/admission authority.
2. Query: events, lineage, tool outcomes, decisions/caveats, and raw support are immediately queryable with truthful coverage.
3. Compile: Polylogue produces a compact evidence-backed resume/context artifact.
4. Consume: a fresh agent invocation receives that artifact before acting.
5. Measure: compare the resulting continuation against a raw-transcript or ordinary-handoff baseline.

The first implementation may be intentionally narrow. Generalization follows observed failures, not the other way around.

Acceptance criteria

• A non-synthetic agent run emits provider-neutral typed work evidence during execution through the current canonical source/write authority, with deterministic idempotency and no parallel source of truth.
• The emitted run is queryable before the original runtime session ends, including evidence refs and explicit unsupported/missing coverage.
• A compact context/resume artifact is generated from that evidence and consumed by a fresh continuation invocation.
• The trial records whether the artifact recovered non-obvious state, changed the next action, prevented duplicated work, or introduced misleading context.
• At least three real resumptions use the loop; one must include a failure, retry, delegation, or context boundary.
• A baseline comparison shows the marginal value or honestly records that the current loop has little value.
• All public claims distinguish operational archive/forensics capabilities from still-experimental in-loop exocortex behavior.

Tracker authority

• GitHub: this public terminal outcome and its falsifiable proof.
• Beads public parent: polylogue-rii (public_parent).
• Internal delivery children: polylogue-rii.1 owns the live work-event write leg; polylogue-rii.2 owns remaining hook/OTLP evidence projection. These implement this issue and do not need separate public issues.
• Hermes-specific outcome: polylogue-fs1, represented publicly by feat(hermes): ingest work structure and produce evidence-backed run forensics #2460.
• Effective-context correctness: polylogue-4ts.5, represented publicly by feat: compaction boundary-range columns + effective-context derivation #2478.

Sequencing rule

Before admitting a broad new abstraction, record the specific failure from a real proving-loop trial that requires it. Parser-only vocabulary, projection-only tables, or a generalized orchestration layer are not closure by themselves.

Non-goals

• No claim that Polylogue already functions as a meaningful personal exocortex.
• No mutable runtime task authority inside Polylogue.
• No requirement to store every projection as a durable table.
• No large cross-provider framework before one narrow loop has repeated terminal value.
• No closure based only on fixtures, unit tests, or a synthetic demo.

[Sinity]

Triage assessment — automated backlog pass (2026-06-27)

This is a grounded re-assessment (read against current master, not just the checkbox state), captured so the finding is not lost.

Readiness	~5% already in code
Remaining scope	tier L (S<1 PR · M=multi-commit PR · L=multi-PR · XL=program)
Independent?	False
Conflict risk	high (shared-file edit risk vs other backlog issues)
Depends on	none

Assessment & remaining work

Define an agent-work intake contract (event envelope covering session start, prompt, tool call/result, subagent spawn, run end) as a new module under polylogue/sources/intake/ and wire it into the existing ingest pipeline in polylogue/pipeline/ with content-hash idempotency. Add an opt-in materialization path in polylogue/daemon/otlp_receiver.py that parses received agent spans and routes them through the new intake contract into source.db/index.db rather than only ops.db, gated on a config flag. Generalize polylogue/sources/live/ hook intake to emit through the same shared contract so Claude Code hooks and new push sources share one writer. Add an E2E fixture test (push synthetic event stream → archive → query confirms sessions/events in index.db).

Primary files

• polylogue/daemon/otlp_receiver.py
• polylogue/sources/live/
• polylogue/storage/sqlite/archive_tiers/source.py
• polylogue/storage/sqlite/archive_tiers/index.py
• polylogue/daemon/http.py
• polylogue/pipeline/

---

Generated by a parallel triage of the open backlog. Treat readiness % and "already done" claims as a starting map — verify against source/tests before acting; later merges may have moved things.