BriefLoop: Open-Source Loop Engineering for Auditable Business Briefings

1.1 Architecture Charters

The following principles were extracted from failures in real runs. They are engineering constraints, not slogans.

1. Smart components have no authority; authoritative components are deterministic; effective changes pass through people; exceptional actions leave a trace. LLMs and agents may interpret, recommend, decompose, and draft. They may not directly write authoritative state, advance a stage, freeze evidence, pass a gate, or approve delivery. Effects must be executed by the deterministic control plane, confirmed where required by a human, and recorded.
2. What machines can enforce should not be delegated to memory. Rules that can be checked through schemas, validators, gates, transactions, events, or tests must not exist only in prompts or handoff prose.
3. Every field has one writer. Python writes state, ledgers, events, hashes, gates, and archives. LLMs write content drafts. Humans approve preferences and delivery decisions. Derived projections may not overwrite authoritative records.
4. A source is not support; traceability is not proof. Retrieval plans, source candidates, search summaries, and model summaries are discovery material. Whether a source supports a claim must be recorded separately by support strength, source tier, scope, and freshness.
5. Frozen artifacts cannot be silently rewritten, and gaps cannot be hidden. Legitimate change must create a new revision, artifact, event, or explicit supersession, revert, or contamination record. Failed gates, missing evidence, rejected claims, and unresolved human decisions must remain queryable.
6. Conflicts are resolved by declared precedence, not by model persuasion. Fact contracts and deterministic gates outrank style preferences; repairs for the current run outrank cross-run taste memory; changes to objective, audience, time window, source policy, or delivery standard require explicit configuration or a new run.
7. Cross-module invariants must close structurally. When a rule spans transactions, state recomputation, registries, gates, projections, and runtime adapters, it needs one authoritative record and coverage over every writer, recomputer, and reader. The system cannot rely on each path independently remembering the same fact.

1.2 Operating Disciplines

• Product spine: acceleration must not remove accountability. BriefLoop may reuse frozen evidence, avoid repeated reasoning, and parallelize independent work. It may not remove ledgers, gates, approvals, events, snapshots, or archives to run faster.
• Public claims: do not say more than the artifacts can support. Unmeasured capabilities must be labeled unmeasured. Traceability must not be described as semantic proof or demonstrated quality improvement.
• Data boundary: private facts cannot validate a public mechanism. Real business workflows may contribute failure categories and test shapes, but private business facts, customer materials, employer data, and non-public information must not enter the public repository, fixtures, or demos.

1.3 Why Coding Agents Improve Faster

The progress of coding agents comes not only from model capability but also from the closed feedback loops already established in software engineering. Anthropic's distinction between workflows and agents provides an engineering coordinate: fixed, decomposable tasks are better served by explicit inputs, outputs, and programmatic checks, while open-ended paths warrant greater autonomy.E21

Models provide capability; infrastructure provides repeatable feedback. Business briefing rarely has equivalent machinery. Quality defects are difficult to turn into tests, stale data is difficult to locate in the retrieval chain, verbal feedback does not accumulate, and “this section feels wrong” rarely becomes a reusable engineering task. Improvement therefore depends on individual craft and remains difficult to transfer.

1.4 The BriefLoop Thesis

BriefLoop does not attempt to make one model intrinsically smarter. It brings software-engineering accountability infrastructure to business briefing:

The v0.7.1 reference run exposed a decisive failure: the agent completed the content pipeline while almost entirely skipping the control pipeline. It produced eight content artifacts but invoked no decision transactions, ran no gates, and left workflow_state.json at its initial stage. In its postmortem, the agent acknowledged that it had treated the Orchestrator contract as background information rather than an API it was required to execute.

That failure drove BriefLoop to move critical bookkeeping from prompts into transactions. Agents still propose what to do and explain why. The Python control plane determines whether a decision has taken legal effect under the required conditions and artifacts. Important rules must live in schemas, validators, gates, transactions, events, or tests rather than instructions alone.

1.5 Independent Convergence with Harness Engineering

Three 2026 studies of harness optimization and one research synthesis provide external coordinates that are comparable with BriefLoop from different directions, but are not interchangeable with it.

• LIFE-HARNESS treats the runtime interface outside a frozen model as an optimization target, but its findings come from deterministic environments with computable rewards and cannot be extrapolated into gains in open-domain briefing quality.P01
• Self-Harness uses failure mining, bounded modification, and held-in/held-out regression. It supports the proposition that a harness can be improved through engineering; it does not support allowing a candidate modification to approve its own activation.P02
• Meta-Harness further places models, tools, and environments within an end-to-end optimization scope. It strengthens both the case for evaluating the entire operating system and the requirement to keep permissions and acceptance protocols outside the editable loop.P05
• Weng (2026) synthesizes harness components including workflows, context lifecycle, persistent state, tools, subagents, permissions, and evaluation, and systematically discusses evaluator, reward-hacking, and human-oversight risks. It is a research synthesis and technical essay, not experimental evidence for BriefLoop.E19

The chronology also matters. BriefLoop's human-gated Improvement Ledger and per-run snapshots entered v0.7.0 on 2026-06-10, and its Python-owned claim-freeze transaction entered v0.8.3 on 2026-06-16, both before Weng's synthesis. The defensible description is therefore retrospective independent convergence: Weng provides a unifying research language and risk boundary, while BriefLoop's repository history shows an early engineering instance of these principles in open-domain business briefing. Chronology does not substitute for evaluation and does not establish priority or performance superiority.

1.6 From Agent Engineering to Loop Engineering

Loop Engineering is concerned not with writing a better prompt once, but with designing a system that continuously discovers tasks, assigns work, checks outcomes, records state, and decides what happens next. This report borrows the term and attributes the paradigm; it does not treat the technical essay as experimental evidence.E20 BriefLoop applies this method to recurring business briefings: the control units are no longer code diffs, but material claims, evidence spans, support records, FeedbackIssue records, repair tasks, and delivery decisions.

2.1 A Three-Layer Quality Model

BriefLoop separates quality into three layers so that process compliance, clean delivery, and analytical excellence are not conflated.

1. Law: Machine-checkable requirements such as citation presence, source freshness, numerical consistency with the ledger, and absence of internal identifiers in the reader edition. Hashes, events, and gate reports can verify this layer, but only for formalizable defects.
2. Honesty: Whether the reader artifact is clean, readable, and free of internal workflow residue or blank citations. This measures delivery discipline, not analytical depth.
3. Wisdom: Whether the briefing identifies what truly matters, provides insight, and outperforms a single-model baseline. This remains NOT MEASURED. Claim-layer artifacts differ across runs, so causal attribution is not yet valid.

The correct sequence is to stabilize Law first, then Honesty, and only then measure Wisdom against controlled baselines. Content-quality comparisons are heavily confounded while delivery itself remains unstable.

2.2 Correctness, Taste, and Evidence

Correctness can be partly mechanized. Taste must remain human-editable. Evidence lies between them. Models may discover and draft claims, but claim IDs, freeze records, hashes, and support metadata must be owned by the deterministic control plane.

2.3 Governance Domains and Control Surfaces

Four contract categories answer what is governed:

Control surfaces answer who writes, when the result freezes, how it is validated, and what happens on failure. Their theoretical lineage can be understood through workflow patterns, blackboard architectures, and Design by Contract: the first describes control-flow expressiveness, the shared blackboard describes specialized roles collaborating around common state, and contract-based design emphasizes preconditions, postconditions, and invariants.T01 T02 T03 BriefLoop's provenance relations also borrow the W3C PROV vocabulary of entities, activities, agents, and derivation, but the project does not claim full compatibility or conformance testing.T06 Contract categories and control surfaces are not competing architectures: the former describes governance content, while the latter realizes that content as files, single writers, transactions, and failure states. See docs/control-surfaces.md for the complete current inventory.

Northstar is a product-governance and prioritization advisory surface, not a runtime role, architecture authority, Merge Governor, or workspace control plane. It may recommend building, deferring, or rejecting scope based on user evidence, but it cannot write runtime state, execute gates or finalization, approve delivery, merge code, or approve public release. Humans retain authority over subjective tradeoffs, commercial commitments, pilot participation, outcome acceptance, and product decisions that take effect. A change to the current run's objective, reader, time window, source policy, or delivery standard must become an explicit configuration change or a new run.

2.4 The Single-Writer Principle

• Python writes control state, ledgers, events, hashes, gates, transactions, and archives.
• Runtime agents write candidate claims, screening results, claim drafts, brief content, and semantic audit opinions.
• Humans write approvals, audience guidance, delivery decisions, and explicit run direction.

The separation between claim_drafts.json and claim_ledger.json exists to enforce this rule. The model may write drafts without authoritative IDs. Python assigns stable IDs and freezes the ledger. Neither side may opportunistically rewrite the other's artifact.

2.5 The Speed Principle

Speed may come from reusing frozen artifacts, reducing repeated reasoning, and parallelizing independent work. It may not come from weaker records, fewer gates, fewer approvals, or weaker archives. A fast rerun imports and validates an existing fact layer, then resumes from analysis. It still performs writing, audit, gates, finalization, and human delivery. Acceleration comes from reuse, not omission.

3.1 Runtime-State Spine

runtime_manifest.json
→ workflow_state.json
→ artifact_registry.json
→ event_log.jsonl

The Python control plane is the sole authoritative writer. v0.12 binds recovery reads for the Manifest, Workflow, Registry, Event Log, and Finalize Report to the same opened workspace session. POSIX uses descriptor-bound, no-follow reads; Windows uses handle-bound reads with reparse-point handling. Legitimate optional absence remains a typed absence, while unsafe, stale, or non-canonical Registry state projects no value. This design realizes Architecture Charter 7 through a shared fail-closed read boundary, preventing different consumers from reopening paths independently and interpreting the same control file in different ways.

3.2 Evidence-and-Claim Spine

source evidence
→ persistent source evidence
→ input classification
→ candidate_claims.json
→ screened_candidates.json
→ claim_drafts.json
→ freeze transaction
→ claim_ledger.json
→ audited_brief.md
→ audit_report.json
→ source_appendix.md

Runtime agents produce candidates, screening results, claim drafts, and briefing content. Python validates and freezes the boundary between claim_drafts.json and claim_ledger.json. A provenance projection can connect claims, sources, artifacts, decisions, and gate findings, but traceable relations do not establish that a source semantically supports a claim, nor do they establish full W3C PROV compatibility.T06

The claim-freeze transaction proceeds as follows:

1. The claim role writes claim_drafts.json without claim_id. A preassigned ID at any nesting level is rejected.
2. briefloop state freeze-claim-ledger reads validated drafts, assigns CL-#### in deterministic order, writes the authoritative claim_ledger.json, records hashes and freeze metadata, and appends a claim_ledger_frozen event.
3. briefloop state stage-complete --stage claim-ledger requires a matching freeze record. Hash drift, missing freeze metadata, or stale ledger bytes fail closed.
4. Analyst and auditor roles read only the frozen ledger. They may not treat the draft as authoritative input or modify the ledger.

3.3 Gate Spine

CompositeAuditAgent
├── DeterministicAuditAgent
├── QualityHarnessAuditAgent
└── NoOpSemanticAuditAgent
    → gates/auditor_quality_gate_report.json
    → gates/finalize_quality_gate_report.json

The first two audit components are Python implementations and do not call an LLM. The semantic-audit slot remains a placeholder. The runtime Auditor is expected to examine whether wording matches support strength, but the project does not ship a model-based semantic auditor with release authority. Auditor and finalize stages consume their own stage-scoped gate reports. The legacy quality_gate_report.json is a compatibility projection, not frozen authority.

3.4 Memory-and-Improvement Spine

audience_profile.md
→ audience_profile_snapshot.md

improvement/ledger.jsonl
→ improvement/memory.md
→ improvement_memory_snapshot.md

Humans maintain the Audience Profile and approve improvement guidance. Python materializes memory from the ledger, freezes the per-run snapshot, and records effective entries and their SHA-256 in the Runtime Manifest. An approval or revert during a run affects only future runs; it cannot alter already-frozen input for the current run. Each ledger revision links to its predecessor hash.

3.5 Delivery-and-Archive Spine

output/intermediate/finalize_report.json   # single delivery truth
output/delivery/brief.md
output/delivery/<name>.docx
output/source_appendix.md
output/runs/<run_id>/

Finalization first renders reader artifacts in a candidate location and runs reader-clean checks; only a passing candidate is promoted to output/brief.md and output/delivery/. A failure writes a failed finalize_report.json while preserving the previous delivery bundle. A success report records the delivery artifacts bound to the current run and their SHA-256 hashes. Delivery eligibility is not delivery success: the latter also requires a delivery-outcome event bound to the current run. File presence alone is not delivery truth. The archive continues to retain delivery artifacts, intermediate artifacts, control records, and a hash manifest; a historical run may not be overwritten in place.

3.6 Product Layer and Support-Sufficiency Experimental Stack

report_spec.yaml
→ ReportPack / ReportTemplate / PolicyProfile
→ atomic_claim_graph.json
→ evidence_span_registry.json
→ claim_support_matrix.json
→ semantic_assessment_report.json
→ semantic_support_acceptance_ledger.json
→ quality_panel.json / quality_summary.md / quality_panel.html
→ delivery_bundle.zip / audit_bundle.zip

Authority is bounded as follows:

• Specialist roles may draft Atomic Claim Graphs, evidence spans, Claim-Support Matrix rows, and semantic-assessment proposals.
• Python validates only schemas, reference integrity, hash bindings, required-row coverage, and adjudication-record format.
• semantic-support adjudicate records human acceptance or rejection, but the adjudication record does not rewrite the Claim-Support Matrix automatically.
• briefloop new, packs bundle, quality summarize, extract, and sources materialize-pack write only workspace structure or projections. They do not run specialist roles, approve delivery, or prove semantic correctness.
• The experimental WorkBuddy/CodeBuddy path uses two-stage permissions: a checked-in role agent drafts only the artifacts named in the handoff; a command-capable main session must reread the handoff before executing the permitted CLI transaction. Seeing an artifact or a generic-helper narrative cannot substitute for a host-visible record of the exact role invocation and return.

The supported product entrypoints are:

4.1 Stage-Completion Transactions

stage-complete, finalize, and finalize-complete move stage bookkeeping, candidate promotion, and completion decisions from prompt obligations into deterministic execution. A transaction:

• checks that expected artifacts are registered and valid in the trusted interpretation of the Registry;
• updates stage status in workflow_state.json and appends an event to event_log.jsonl;
• enforces stage-specific preconditions, such as a matching freeze record for Claim Ledger completion;
• during finalization, checks the candidate reader artifact before atomic promotion and writes delivery-artifact hashes to finalize_report.json;
• distinguishes eligibility, finalization success, and delivery outcome in completion and delivery projections, rather than inferring success from file presence.

The Orchestrator decides what action to take and why. Python records whether that decision has legally taken effect under the required conditions.

4.2 Claim-Ledger Freeze Transaction

After freezing, analyst and auditor roles may only read the ledger. Any change requires a new run or an explicit contamination, supersession, and repair record.

4.3 Run Integrity and Contamination

workflow_state.json.run_integrity records whether a run remains usable as clean reference evidence. Resetting an executed run, replaying a stage against stale state, or modifying a frozen artifact writes a contamination event and reason. The v0.12 recovery context must read five classes of control input through the same trusted workspace session; supersede marks downstream artifacts stale until they are regenerated. A contaminated run may continue to a constrained delivery, but it may not be presented as an A-grade controlled experiment. Missing, stale, and unsafe inputs must remain visible.

4.4 Immutable Archives

The archive at output/runs/<run_id>/ preserves:

• delivery artifacts such as Markdown and DOCX;
• intermediate artifacts such as the Claim Ledger, gate reports, and audit report;
• control records such as workflow state, Event Log, and Runtime Manifest;
• SHA-256 values for every artifact in the manifest.

The archive is append-only and cannot be rewritten in place.

4.5 Fast-Rerun Import

briefloop state import-fact-layer can copy archived source evidence, input classification, candidate claims, screening results, and the Claim Ledger into a new workspace. The transaction copies original bytes, verifies hashes, records the import relationship, and marks satisfied upstream stages as completed by import. briefloop run --recipe fast-rerun begins at analysis. Finalization still reevaluates freshness against the new workspace's time. A fast rerun reuses the fact layer; it does not reuse the previous brief, audit result, finalization record, or delivery approval.

5.1 From Source to Claim

source discovery
→ persistent source evidence
→ input classification
→ candidate claims
→ screening results
→ claim drafts
→ deterministic freeze
→ Claim Ledger

Only materialized source files and supported entries in source configuration can serve as evidence. source_candidates.yaml is for planning and review. It cannot replace sources.yaml, and its presence does not establish that source discovery is complete. Retrieval plans, search summaries, and model summaries are discovery material, not evidence.

Current source records require at least a source ID, name, type, title, and content. Evidence spans, retrieval time, source tier, and excerpt hashes belong to the support-sufficiency direction. They strengthen traceability but still do not prove automatically that a source semantically supports a claim.

5.2 Claim-Draft Contract

claim_drafts.json is the input to the claim-freeze transaction. Neither a draft entry nor its metadata may contain a preassigned claim_id. The sorted_sequential_v1 algorithm sorts by stable keys and assigns CL-####. Identical freeze input produces identical IDs, but the system does not promise ID stability across freezes when claims are added, removed, or reordered.

This design prevents the model from fabricating authoritative identity. The model owns claim content; the system owns claim identity and freeze status.

5.3 Support-Strength Calibration

The v0.7.4 failure study exposed five recurring problems:

1. Support inflation: a source reports regulatory discussion, while the brief describes formal approval.
2. Authority inflation: a conference item or media report is presented as a government plan or official fact.
3. Claim conflation: a supported core fact and an unverified implication appear in the same sentence.
4. Attribution mismatch: one source is made to carry several conclusions it does not independently support.
5. Forecast-as-evidence: a secondary-market forecast or commentary is used as the basis for a core fact.

These are not missing-source failures. They are calibration failures between evidence and language. The Auditor must examine overstatement, support strength, confidence, evidence relationships, and limitations. Experimental support records may use labels such as explicitly_supported, partially_supported, supportive_but_overextended, attribution_mismatch, needs_primary_source, and unsupported. The labels still require human adjudication and cannot become release authority on their own.

Dynamic knowledge adds four adjacent but distinct calibration risks:

6. Temporal-validity inflation: a fact that was historically true is written as if it remains true at the current freeze point.
7. Version conflation: an original item, correction, update, and republication are treated as independent and equally current evidence.
8. Repetition-as-corroboration: multiple copies of an older report create a numerical majority over one newer primary source.
9. Loss of source fidelity: the model uses its own knowledge to “correct” the input, producing text that may be more factually accurate in the world but is no longer faithful to the source it purports to summarize.P29

Temporal-knowledge research shows that facts may have validity periods, while credibility-aware generation shows that source credibility can be made an explicit signal. Neither result means that a date or a high source tier automatically determines truth.P30 P33 The current exact head can record source published_at and retrieved_at values and apply deterministic freshness checks; the policy-regulatory module also has a local effective_date. It does not provide a general valid_time or as_of model for claims, source-correction, retraction, or supersession relations, or a general conflict finding and resolution state. These four items are therefore architecture requirements and planned evaluations in this edition, not shipped conflict-governance capabilities.

5.4 Boundary of the Source Appendix

During finalization, output/source_appendix.md is generated from claims actually cited by the reader brief. It is embedded into Markdown and DOCX delivery artifacts while an audit copy is retained. The Source Appendix gives readers a route for follow-up. It is not a certificate of factual correctness. It establishes where a claim can be traced, not that the claim has been proven true.

6.1 Stage-Scoped Gates

Stage-scoped reports are authoritative. The legacy quality_gate_report.json is retained only as a compatibility projection. Completion transactions have no --force path around the gates.

6.2 Deterministic Audit Stack

runtime Auditor role
→ CompositeAuditAgent
→ DeterministicAuditAgent
→ QualityHarnessAuditAgent
→ NoOpSemanticAuditAgent
→ audit_report.json

The deterministic audit checks sources, freshness, numbers, dates, safe wording, process residue, and redaction. The Quality Harness audit checks rules around material facts, target relevance, and reader residue. The semantic-audit slot remains a placeholder. A future model-based semantic evaluator still may not overwrite deterministic findings or decide support truth or delivery eligibility by itself.

6.3 Repair Routing

briefloop repair route is a read-only diagnostic command. It maps gate, audit, registry, and workflow findings to the responsible stage and allowed artifact class. It tells the Orchestrator who should repair an issue and what may be changed. It does not create prose, execute repair, or replace a RepairPlan.

6.4 Anti-Goodhart Principle

Precision Is Not Faithfulness shows that optimizing precision alone may reward a system for deleting important but difficult-to-verify content.P08 Before a blocking precision gate is introduced, BriefLoop must ask: What is the cheapest way for the system to pass? If omission is the cheapest strategy, a coverage or omission check must accompany the gate so that silence cannot earn a high score.

6.5 Coverage and Omission Continuity

The current supported gate checks whether high-priority items in screened_candidates.json disappear silently before the Claim Ledger or cited brief. It captures the path in which an item passes screening but is omitted during analysis or editing. It does not provide complete recall over all relevant facts and does not prove that the report has sufficient overall coverage.

7.1 Audience Profile

audience_profile.md is a human-editable workspace file for structural preferences, departmental vocabulary, tone, and durable feedback. A run reads only its frozen audience_profile_snapshot.md. Changes to the live profile during a run affect future runs only. The profile is semantic guidance, not evidence, and has no gate authority.

7.2 Improvement Ledger

improvement/ledger.jsonl is an append-only, revision-chained workspace ledger that requires human approval. Its lifecycle is:

propose
→ human approve
→ Python rebuilds improvement/memory.md
→ next run freezes improvement_memory_snapshot.md
→ revert when necessary

Key invariants are:

• a proposed entry affects no run;
• approval appends state and does not alter the current run;
• materialization occurs at the beginning of the next run;
• reverted entries disappear from the next memory and snapshot;
• materialized_entry_ids and the hash in runtime_manifest.json record exactly which guidance the run consumed.

7.3 Whether Guidance Was Manifested

The experimental guidance_manifestation_report.json can record observable status for approved guidance in an output: explicitly manifested, partially manifested, contradicted, or not observable. Python validates labels and counts them. It does not decide whether a label is semantically correct, modify improvement memory, or block finalization.

The archived BriefLoop-090 experiment can import manifestation ratings from an external evaluator. That measurement is outside the ordinary product path and does not establish improved output quality.

7.4 Memory Surfaces Not Yet Shipped

These surfaces should be introduced only after the core propose-approve-materialize-freeze-revert lifecycle is stable.

7.5 Controlled Harness-Improvement Protocol (Proposed)

The current exact head has event traces, gate findings, FeedbackIssue, RepairPlan, evaluation fixtures, the Improvement Ledger, run snapshots, trusted control reads, and transactional delivery records, but it does not yet form an end-to-end self-improving harness. A future protocol must preserve these authority boundaries:

“Improvement” in BriefLoop therefore does not mean an agent rewriting its own control plane. It means converting production failures into engineering changes that are localizable, proposable, regression-tested, approvable, and reversible. Materiality, analytical taste, and management value still require human judgment. Deterministic gates provide only local, auditable weak-reward surfaces.

8.1 Version Evolution

8.2 Supported

• Default, strict, and human_assisted role topologies, plus Delivery Editor.
• Hermes, Claude Code, and OpenCode runtimes; run generates a handoff and does not replace external role execution.
• Runtime state, a trusted Registry, the Event Log, claim freezing, stage completion, transactional finalization, contamination/supersede records, and immutable archives.
• Audit and finalization stage gates, coverage-and-omission continuity checks, feedback and repair plans, and the Orchestrator control switchboard.
• The Improvement Ledger, audience snapshots, per-run improvement snapshots, and provenance projection.
• Reader delivery bundles under output/delivery/, audit copies of the Source Appendix, delivery truth in finalize_report.json, and a current-run delivery outcome.
• Four-way input governance and market-competition, policy, and regulatory-analysis modules.
• Twenty-five public-safe evaluation cases; 3,710 pytest items are locally collectable at this snapshot.
• The industry-weekly, management-monthly, and document-review product entrypoints.

8.3 Experimental

• Atomic Claim Graph, Evidence Span Registry, Claim-Support Matrix, semantic assessment, and human adjudication.
• Broader Product OS extensions: template rendering, policy-profile gate adaptation, the Quality Panel, and materiality and support-wording diagnostics.
• UTF-8 text evidence-span seeding, persistent source evidence packs, SourceHub Lite, and fast-rerun fact-layer import.
• Paths involving Codex custom agents, source-clone WorkBuddy/CodeBuddy role assets, Feishu, Gmail, PDF, and MinerU.
• Archived experiment tooling for BriefLoop-090 and its frozen historical ID MABW-080.

8.4 Not Shipped

• An end-to-end Issue Candidate system and an approval transaction that safely promotes a candidate into a new harness version.
• A complete semantic-coverage gate, regression harness, and release-eligibility summary with release-blocking authority.
• Demonstrated cross-model output-quality gains, complete fact-checking, private commercial benchmarks, and autonomous learning.
• External runtime evidence that establishes actual WorkBuddy/CodeBuddy role delegation and result quality.
• A primary pipx install briefloop path smoke-tested against a real package-index artifact.
• First-user pilot evidence satisfying the v1.0 requirement.

8.5 v1.0 Evidence Gate

The freeze inventory in docs/control-surfaces.md identifies surfaces eligible for backward-compatibility commitments. v1.0 also requires at least one publicly reproducible first-user evidence record, such as an external fresh clone, first use through WorkBuddy, a pilot checklist, or recurring weekly-report dogfood. At the current exact head, docs/v1-pilot-evidence.md still records Status: not_satisfied. It is a release-readiness evidence ledger, not semantic proof, proof of output quality, delivery approval, or release authority.

BriefLoop-090 completed one synthetic auditable_brief pilot. It can support the narrow statement that guidance patterns differed in one case. It cannot support generalized claims about output quality, management readiness, or delivery quality.

9.1 v0.7.2 Public Solar Integration Run

Two runs over public materials demonstrated that the following mechanisms can close end to end:

• approved guidance can be materialized into frozen per-run improvement memory;
• quality gates blocked stage progression three times and passed after repair;
• the Orchestrator reads a frozen snapshot rather than live mutable workspace memory;
• runtime_manifest.json records effective entry IDs and their hashes.

The run does not prove improved output quality or a causal effect from guidance. Candidate claims, screening results, and Claim Ledger hashes differed between the two runs, so guidance was not the only variable. The run is appropriate as B+ integration evidence, not as an A-grade controlled experiment.

9.2 v0.7.4 Failure Study

An industry-research run produced a complete, readable briefing and preserved the full workflow artifact chain. External review still found support inflation, authority-tier mismatch, claim conflation, attribution mismatch, and forecasts presented as facts.

This did not show that BriefLoop produced a better report. It demonstrated a narrower but important capability. In direct model drafting, an error often survives only in the final text. In BriefLoop, the error can be traced through source summary, candidate claim, screening result, Claim Ledger, audited brief, and reader artifact. The failure was not repaired automatically, but its propagation path was preserved.

9.3 Decoupling Content and Control

The v0.7.1 run showed that a model can complete all content work while skipping almost every control obligation. That failure directly motivated stage-completion, finalization-completion, and claim-freeze transactions. It supports one conclusion: a prompt obligation is not an execution guarantee. An important rule needs a machine-verifiable execution path.

9.4 Evidence Boundaries

9.5 Synthetic Pilot and Product-Layer Reference Bundle

BriefLoop-090 uses one public-safe synthetic case with three conditions: baseline, memory, and prompt-only. It applies blind assessment and hash-bound import. The observation matched the intended pattern: the baseline did not manifest the target guidance, the memory condition was more stable, and prompt-only over-applied the same guidance. This result is specific to one case.

The v0.11.3 product-layer reference bundle demonstrates deterministic same_evidence_reader_quality_regression: the reader artifact contains no internal claim markers, the audit bundle preserves trace records, and the Quality Panel summarizes materiality, template, wording, and trajectory diagnostics. The bundle does not call a model, so it cannot establish model-output quality or delivery approval.

10.1 Harness Adaptation and Optimization

LIFE-HARNESS, Self-Harness, and Meta-Harness jointly show that the harness between a model and its environment can be an independent optimization target.P01 P02 P05 Their tasks, rewards, and acceptance mechanisms, however, cannot be extrapolated directly to open-domain business briefings. BriefLoop therefore adopts only the methodology that failures can be structured, modifications should be bounded, and regression must cover held-out behavior. The active control plane, evaluators, permissions, and approval transactions must remain outside candidate modifications.

Weng's synthesis expands the harness into an operating system composed of workflows, context lifecycle, persistent state, tools, subagents, permissions, and evaluation, and emphasizes that recursive structures, vague evaluation, reward hacking, and long-horizon maintenance objectives remain risks.E19 This report uses it for domain definition and risk synthesis; mechanism and performance claims still return to primary papers, and the synthesis is not presented as a peer-reviewed experiment.

BriefLoop has a supported subset of trajectory regulation. When retries, repair loops, or repeated blocks exceed budget, Python narrows the legal decisions for the current stage to request_human_review and block_run and records the change in the Event Log. This is control-state narrowing, not automated repair.

10.2 Multi-Turn Feedback and Regression

DRA Multi-Turn finds that process-level feedback can produce meaningful single-turn gains, but later revision can regress constraints that were previously satisfied.P06 This supports BriefLoop's targeted repair, frozen snapshots, and external gates. It also explains why same-evidence regression must ask both whether the target defect disappeared and whether previously passing behavior was preserved. The study does not provide an estimate of BriefLoop's own quality improvement.

10.3 Auditable Human-Agent Collaboration

CHAP describes human–multi-agent collaboration through workspaces, tasks, artifacts, and append-only evidence logs.P07 CHAP focuses on a communication protocol; BriefLoop focuses on governance and release accountability inside business briefing. Both require collaborative results to land in inspectable artifacts rather than exist only in transient conversation. This report does not claim protocol or schema compatibility.

10.4 Evaluation Method

FActScore decomposes long-form text into atomic facts, while ALCE separates citation quality from general fluency. Together they show why “has a citation” and “is fully supported” must be evaluated separately.P12 P13 Precision Is Not Faithfulness further warns that a single precision metric may reward a system for saying less, so a precision gate needs a continuity constraint.P08 ResearchLoop provides an adjacent-system comparison for an externalized evidence gate and persistent claim binding.P20 BriefLoop keeps freezing, hashing, coverage checks, stage state, and delivery hygiene in a non-model control plane while leaving semantic judgment as a proposal or an input to human adjudication. It does not claim that atomization or provenance itself establishes truth.

10.5 Multi-Agent Frameworks

AutoGen, CAMEL, and MetaGPT respectively represent conversational agents, role-playing collaboration, and SOP-encoded pipelines.P09 P10 P11 EvoMAS frames multi-agent-system generation as execution-feedback-driven evolution over a structured configuration space and reports performance and executability results on its benchmark.P21 These works study how agents can be organized; BriefLoop's distinction is who has authority to make a result take effect. In this report, EvoMAS supports only the proposition that candidate topologies or configurations can be searched. It does not support a claim that BriefLoop has implemented automatic architecture evolution. In engineering practice, multiple agents are warranted only when context isolation, parallel exploration, or specialization provides a real benefit.E10

10.6 Memory and Preference

Self-Refine and Reflexion show how model self-feedback, linguistic feedback, and episodic memory can affect later outputs or trials.P16 P17 Hermes Agent's persistent-memory documentation provides a human-readable USER.md/MEMORY.md file surface with optional write approval.E22 BriefLoop borrows the readable file surface, not its authority model: audience guidance also passes through a workspace ledger, human approval, per-run freezing, hash chaining, and a manifest of effective entries. Live memory cannot silently alter the current run, preference cannot override fact gates, and projections cannot write back to the source ledger.

10.7 Enterprise Knowledge-Work Agents

This section retains only first-party engineering materials that support a specific architectural argument: the workflow/agent distinction, the boundary for when multi-agent systems are useful, attribution of the Loop Engineering term, a persistent-memory surface, and the Tax AI production loop. Other product launches, aggregation pages, and duplicate cases are excluded from the formal bibliography. Engineering articles can describe patterns of practice; they cannot establish that BriefLoop is implemented correctly, produces higher quality, or is production-ready.

11.1 Known Boundaries

The current exact head does not claim to provide:

• automatic proof of semantic truth or complete fact-checking;
• automatic detection or adjudication of all context-memory, inter-context, and intra-memory knowledge conflicts, including dynamic facts, source corrections, version supersession, retractions, disputed facts, and source-fidelity conflicts;
• demonstrated improvement in briefing content quality, management value, or cross-model stability;
• autonomous repair execution, autonomous modification of the active harness, or self-approval of policy for future runs;
• management-ready deliverables by default;
• proof of actual delegation from file presence, a generic-helper narrative, or the presence of role assets alone;
• stable production readiness for WorkBuddy/CodeBuddy, Codex, Gmail, Feishu, PDF, or PyPI paths;
• satisfaction of the v1.0 first-user evidence gate;
• an end-to-end self-improving harness.

The precise capability boundary is narrower. Material claims can be connected to registered sources, artifacts, and control records. Optional support records and semantic-assessment proposals can be observed and human-adjudicated. Sources can carry publication and retrieval times and undergo freshness checks. These surfaces provide traceability, limited temporal signals, and support-sufficiency records; they do not provide general valid time, source-supersession relations, complete conflict detection, or truth proof.

The current version does not automatically cluster validator-confirmed weaknesses, does not ship an approval/promotion transaction for harness candidates, and has not shown that a modified harness avoids regression on held-out briefing cases. The Improvement Ledger manages human-approved reader guidance. It does not authorize agents to change code, contracts, gates, policies, or control state consumed by future runs. The v0.12 advance is to close the boundaries around reads, recovery, finalization, and delegation more reliably, not to grant models more authority.

11.2 v1.0 Focus

The priority for v1.0 should be to freeze the product promise and obtain first-user evidence, not expand the experimental surface. The product layer already provides three workspace entrypoints, report specification, a five-step authoring path, state projections, reader and audit bundles, and the Quality Panel, but docs/v1-pilot-evidence.md still records not_satisfied. The next requirement is for a non-maintainer to complete a reproducible run in a fresh environment and leave evidence of success, confusion, failure, repair, and remaining limitations, rather than for the maintainer to infer usability on the user's behalf.

11.3 Support-Sufficiency Direction

Existing experimental surfaces include the Atomic Claim Graph, Evidence Span Registry, Claim-Support Matrix, semantic-assessment proposals, human adjudication, persistent source evidence packs, and the Quality Panel. The remaining path is:

blocking coverage gate
→ held-in/held-out regression acceptance protocol
→ regression harness with release authority
→ release-eligibility summary
→ Issue Candidate system

A semantic model may propose support labels, conflict types, candidate supersession relations, source differences, and uncertainty explanations. It may not directly determine which dynamic fact is true, silently discard competing sources, or authorize release merely from source count, model confidence, or agreement with parametric memory. It also may not decide repair ownership, archive grade, future-run policy, or release eligibility. Release authority remains in schemas, hashes, policy, human adjudication, and deterministic blocking rules.

11.4 From Failure to Improvement

A future Issue Candidate system should follow this path:

report failure
→ claim-level trace
→ structured issue
→ evaluation target
→ scoped repair
→ same-evidence regression
→ human review
→ updated release eligibility

Not every correction should enter the engineering queue automatically. Further harness modification requires the editable scope to be declared in advance, evaluators and permission control to remain outside the editable loop, held-in cases to confirm the target fix, held-out cases to test side effects, and an approved version to affect future runs only. EvoMAS shows that a multi-agent topology can be searched within a structured configuration space using execution traces.P21 For BriefLoop, the only acceptable future path is “generate a candidate configuration → deterministic schema and invariant validation → held-in and held-out regression → human approval → recorded activation as a new version,” not an in-run agent directly rewriting its own authority.

11.5 Non-Goals

BriefLoop does not use one global semantic score as release authority, let a model reviewer decide final support truth, ask Python to pretend it has semantic judgment, or weaken ledgers, Event Logs, archives, human delivery, and frozen-artifact rules in the name of speed.

The most accurate public statement is:

BriefLoop puts the claims, evidence, and delivery decisions in business briefings into an auditable engineering loop. It does not prove truth or eliminate hallucination.