Evidence
Understand the current work, examine a dated finding or run a public example. These are different kinds of evidence.
Consumption Engine: product and implementation
The product brief explains who the software serves, what its current components do and how a corrected source changes a task result.
The preservation prototype keeps original documents, extracted text and source records. Catalogs, research summaries and passage search help locate the material again.
Source records establish where material came from. Accuracy and rights to redistribute it require separate review.
The retrieval prototype returns source references, passages and qualifications. It checks for changed or missing evidence and excludes claims marked as withdrawn or superseded.
The checks confirm that a passage appears in its source. A reviewer must assess whether it supports the conclusion.
A task record links the selected evidence, output, check results and recorded review decisions to the specific files used.
Record validation is separate from evaluating the output. It does not verify the identity of the reviewer.
Read the product and implementation brief, Original September 23 inspection note
September 30 local reports: ingestion and evidence delivery, and procedure reuse and the selection study. Both retain their original results and limits.
The private Consumption Engine runtime remains in development. The public fixture replay provides a separate, standard-library-only way to inspect the published evidence contract. It does not claim to reproduce the private runtime.
Public synthetic examples
Both use a bounded synthetic example. They do not reproduce the private runtime or its studies.
Follow the change from three retries to two and inspect the fixed records. This is an interactive presentation of saved data, not a live engine run.
Explore the recordingRun the public package to check correction, stale-snapshot refusal, preserved history and archive replay in a fresh directory. Other expected refusal states are manually specified in its oracle projection.
Run the public fixtureLatest reported work
Source-linked instructions helped agents follow synthetic project rules. A later real-task comparison did not establish a benefit from a compiled guide. The new report follows both results and the next research question.
Synthetic project rules. The real-task comparison. The next question. Separate simulation work.
Historical local test: September 24, 2026
A fictional import policy connects source checks to a configuration change, explicit refusals and replay from saved data. The recorded cases and inputs are available to inspect. Manual annotations, a private runtime and same-machine recovery define the scope.
The separate recorded interactive example presents the public fixture's correction. It is a presentation of fixed data, not a live engine run.
Consumption Engine: how the work is checked
One working day of the team's decision ledger, published with a standard-library checker. 11 decisions cleared their bar, 14 missed it, 5 could not be judged as written and 4 were still open. The failures, and what they changed, stay in the record.
Consumption Engine: next evidence
The public synthetic fixture is runnable by a reviewer and checks preservation, correction, refusal and archive restoration. The separate local demonstration records the September 24 private-runtime synthetic result.
Evaluate a concise briefing of current facts, decisions and next steps against ordinary source reading, including preparation and review effort. Private-runtime distribution and recovery on another machine remain separate qualification work.
Supporting tool: BigBoss
BigBoss is publicly available as a separate local approval tool. These links describe source commit 5615b72, inspected September 23, 2026. They document BigBoss as a separate tool; integration with Consumption Engine is still in development.
Structured read-only actions can proceed. Other proposals enter review or match a blocking rule.
Coverage depends on the actions an adapter submits.
A hash includes the proposed action, workspace, and policy version. A decision refers to that recorded request.
The adapter must apply the decision only to the matching action.
SQLite retains requests, decisions, device identity, and events beyond a terminal session.
A decision record does not establish successful execution.
Read the full BigBoss case study, See supported integrations
Separate BigBoss validation record
Tagged release: v0.1.0
The release records 399 passes and no skips in each of four CI jobs: Ubuntu and Windows, Python 3.12 and 3.13, with no vendor API keys configured.
This is the historical result for commit 10acc53. GitHub may require sign-in to view the job logs.
Later source: September 19
This commit restricts JSON pairing-code access and documents remaining local enrollment paths. Its CI run reports success; the historical 399 count above belongs to the tagged release.
These BigBoss tests were written by the author and run on hosted build systems. Independent testing, production results and Consumption Engine integration have not been established by these checks. Run the BigBoss suite from a fixed version.
Supporting research
One recorded live run shows a claim-level check identifying an error peer critique missed. It shows how the review process works. A broader accuracy benefit has not been established.
Inspect the recorded exampleAn author-run study examines the types of changes merged into one repository, the recorded authors and the review history. It does not measure whether those changes improved the software.
Read the studyA separately evaluated matchup counter and experimental learner components. The case study keeps evaluation conditions and upstream contributions beside the results.
Read the research caseFormat, size and a short SHA-256 identifier, measured when this page was built.