v1.13.0

What's Changed

• Improve flagship presentation assets by @HarperZ9 in #2
• Use the Project Telos flagship card as the repo banner by @HarperZ9 in #3
• feat(lanes): closed proof-lane vocabulary with witnessed over-routing rejection by @HarperZ9 in #4
• Browser-evidence pipeline (parallel-session work, preserved + integrated) by @HarperZ9 in #6
• Context capsules: core, CLI, HTTP/MCP exposure (parallel-session work) by @HarperZ9 in #7
• feat: domain lanes, supervision-grade routing receipts, and vocabulary-gap receipts by @HarperZ9 in #5
• Durable deadlines for human-in-the-loop approval gates by @HarperZ9 in #8
• Style: spectrum banner + feature-first README header by @HarperZ9 in #9
• Release v1.13.0 by @HarperZ9 in #10
• CI: shadow-proof the release wheel verification by @HarperZ9 in #11
• CI: release roster pin 24 -> 28 by @HarperZ9 in #12

New Contributors

• @HarperZ9 made their first contribution in #2

Full Changelog: v1.12.0...v1.13.0

v1.12.0: per-task context

A run already plans on context from a brain (the ContextProvider seam). This routes that seam down to every task, so each agent in a parallel or looped plan gets fresh, task-specific context, not one snapshot taken once before planning.

• Per-task context: with a ContextProvider, the dispatcher pulls context(task.instruction) for each task before it runs, caps it (like upstream data), injects it into the task's prompt, witnesses it as a context entry, and chains the task to it, so the record shows exactly what context shaped each task. The default NullContextProvider returns nothing, so this is a no-op until a brain is plugged in, and Forum stands alone.
• Peer-composition holds: Forum times, routes, and witnesses (its lane); the brain assesses and supplies (its lane); the injected context is verified (witnessed) and fresh (pulled per task). Forum never generates it. The pull is synchronous per task, so a brain doing heavy I/O serializes the wave; it is meant to be fast and offline.

Pure standard library. 249 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.11.0: the delivery ladder, verified tightening

Model output tends to be word-dense, and the reader wants the shortest path to the answer. This release measures that and, when asked, tightens it without dropping any request term, on the same verified ladder Forum uses for intent and routing.

• Delivery floor: forum.delivery.assess(text) measures concision deterministically (sentence length, filler ratio) and flags a dense or padded answer. Witnessed every run, zero-dependency. A floor on concision, not a judgment of cohesion.
• Verified tightening: opt in with Orchestrator(reviser=...). When the floor flags, Forum pulls a tighter version from the Reviser seam and accepts it only if it is strictly shorter AND still covers the request's terms (forum.intent.coverage). That guard is lexical, not semantic: an accepted revision drops no request term, but meaning is not proven preserved. A failing revision, or a crashing reviser, is recorded and discarded; the original stands. The default NullReviser keeps Forum standing alone.
• The accepted revision is witnessed as the delivered result, and the summary and forum bench report delivery checks and revisions.

Pure standard library core; the reviser is a model behind the seam, its output verified deterministically. 244 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.10.0: efficiency, bounded prompts + weighed record

Efficiency is a verifiable quality, because waste is measurable. Forum is already cheap-first (route before a model, judge only when flagged, resume reuses work, budgets cap runs, the content store dedups). This release closes the one waste path the engine introduced and makes efficiency visible.

• Bounded upstream injection: a data edge no longer injects an unbounded upstream output into the downstream prompt. Each injected upstream is capped (dispatch_plan(max_upstream_chars=...), default 8192) with a witnessed truncation marker; the full output stays in the upstream's result entry, so the record loses nothing and only the prompt shrinks. Bounds the growth that compounds down a deep plan.
• A weighed record: summarize reports payload_bytes (the UTF-8 byte weight of distinct witnessed payloads, an efficiency signal not a token count). forum bench shows whether a change made a run leaner; the CLI summary surfaces checkpoints, resumes, and payload weight.

Pure standard library, deterministic, no model in the loop. 230 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.9.0: phased checkpoints + resumable runs

A long run that crashes, hits a budget, or is stopped should not start over. Because every step is already witnessed durably, the ledger is the resume state.

• Resume: dispatch_plan(plan, ledger, executor, resume=True) (and Orchestrator.submit_plan(plan, resume=True)) reuses every task that already has a witnessed successful result and re-runs only the missing or failed ones. A resume entry records which tasks were reused. Resume reuses the verified record; it never regenerates it with a model.
• Phased checkpoints: checkpoint_each_wave=True witnesses a checkpoint entry (the Merkle root so far) and syncs the ledger after each wave, a re-checkable savepoint and the durability point for batched storage (v1.8).
• The summary and forum bench report checkpoints and resumes.

Pure standard library, deterministic. 223 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.8.0: opt-in batched fsync

The durable ledger fsyncs every append, the strongest guarantee and the right default. For a high-throughput run where that per-append fsync is the bottleneck, this release adds an opt-in way to batch it, with the tradeoff stated plainly.

• FileStorage(dir, fsync_each=False): appends are written and flushed to the OS (so they survive a process crash) but not fsynced per call, for throughput. Call ledger.sync() to fsync the logs at a point of your choosing (a phase boundary, the run's end). The default stays fsync_each=True.
• Ledger.sync() / Storage.sync(): a new seam to force buffered writes down. No-op for in-memory and for the default mode; the durability control for batched mode.
• Honest tradeoff: a crash before sync() can lose the un-fsynced tail; the log stays append-only and the torn-trailing-line tolerance still applies, so what survives still verifies and replays. Power-loss durability rests on the OS honoring fsync; the process-crash guarantee is unconditional.

Pure standard library. 218 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.7.0: the verification seam

The peer of the ContextProvider seam (v1.1): where context feeds organized knowledge in before a run, a VerifierProvider checks the answer after it.

• VerifierProvider: a one-method seam, verify(request, answer) -> Verification | None. A peer flagship (the index brain), a proof-checker, or a test runner can implement it; Forum witnesses the verdict as a verification entry chained to the answer. The verdict carries ok (True verified, False refuted, None could-not-decide), a detail, and the verifier's source. The default NullVerifier abstains, so Forum stands alone, zero-dependency.
• Witnessed, not blocking: a refuted answer is recorded; what to do about it is policy. A verifier that crashes is witnessed as could-not-decide, never fatal, so external code can never sink an answer the run already produced. The summary and forum bench report verifications and refutations.

Pure standard library. 212 tests, plus 2 gated real-model tests.

Install: pip install forum-engine

v1.6.0: typed DAG edges (the DAG flows data)

A plan is a DAG, but a dependency used to mean only "runs after." A downstream task could not see what it was building on. This release makes the edges carry data and gives them a type.

• Typed edges: a dependency is a data edge by default (the downstream receives the upstream's witnessed output) or an order edge (run-after, no data flow), declared as {"id": "T1", "type": "order"} in a plan or Task(..., order_deps=frozenset({"T1"})) in code. Both constrain scheduling; only data edges carry output.
• Witnessed data flow: a task's data-upstream outputs are fed into its instruction; the task entry records data_from (which upstreams it consumed) and the plan entry records every typed edge. The witnessed instruction stays the original, so the record is stable and the sent prompt is reconstructable. A failed upstream is never fed downstream. Escalation retries get the same upstream context.
• API-compatible, with a deliberate behavior change: a plain dependency id is a data edge, so existing plans now flow data downstream instead of dropping it.

Pure standard library, deterministic. 205 tests, plus 2 gated real-model tests.

Install: pip install forum-engine (now on PyPI).

v1.4.0: did the run answer the question?

Forum validates each task against its own instruction, but a run can pass every task and still drift from the original request. This release witnesses that gap.

• Witnessed intent check: a completed submit() appends an intent_check entry, chained to the answer, with a deterministic coverage of the request's content words by the answer, the terms it missed, and whether that falls below a configurable threshold (Orchestrator(intent_threshold=...)). The payload names its own method (lexical_coverage). It is a lexical floor, not a semantic verdict: low coverage flags a run for a closer look, it does not block the run or declare the answer wrong. A grounded model intent-judge is the next rung above this floor.
• In the summary and A/B: forum ledger summary and forum bench now report intent checks and how many were flagged, so a prompt or model change that makes runs drift more or less is measured from the record.

Honest about its limits: a correct but paraphrased answer can still flag (the lexical floor's known blind spot). examples/run_intent.py demonstrates exactly that case.

Pure standard library, deterministic and reproducible. 186 tests, plus 2 gated real-model tests.

Install from the attached wheel: pip install forum_engine-1.4.0-py3-none-any.whl

v1.3.0: reading the record

A witnessed run is only worth as much as what you can learn from it. This release turns the raw ledger into something you can read at a glance and compare across runs, while trusting nothing but the record itself. It is what lets the project measure its own improvement instead of asserting it.

• Run summary: forum ledger summary [--json] (and forum.report.summarize(ledger)) aggregates a witnessed run into counts (requests, plans, tasks, task results and failures, verdict pass and fail, escalations, budget stops, contexts, answers), model calls per model with a scalar total, the Merkle checkpoint, and the verify result. It reads only what was witnessed, so the summary is exactly as trustworthy as the ledger beneath it.
• Ledger A/B: forum bench A B [--json] (and forum.report.compare(a, b)) reports the delta between two runs, so you can prove a change actually helped (fewer model calls, fewer failures, fewer escalations) from the record rather than claiming it.

Pure standard library, zero runtime dependencies. 170 tests, plus 2 gated real-model tests. Summary and A/B run in examples/run_summary.py.

Install from the attached wheel: pip install forum_engine-1.3.0-py3-none-any.whl