A real delivery record
One change. Three hours. Six refusals. Nothing failed, and the verdict still reads Inconclusive.
This is the record of one real change to Paqad, the open-source framework we build with, written by the framework while the work happened, not for this page. Follow it from the frozen specification to the sealed receipt, and see why Inconclusive is the point.
Nothing was edited except to shorten long identifiers and to withhold one person’s name. Times are UTC, as recorded.
In one paragraph
This page is the record of one real change to Paqad, the open-source framework Eliyce builds with: change #557, which made loading the team’s rules a required, recorded step before an AI edits code. It was written by the framework while the work happened on 12 September 2026, not for this page. The verdict is Inconclusive: 12 gates passed, none failed, three could not be measured.
The record at a glance
What was agreed, what changed, what was tested, what is still open.
Change
#557 · Require rule-loading evidence for feature-development changes
Repository
Eliyce/paqad-ai, public, MIT licensed. Branch feat/557-require-rules-loaded onto main.
Written by
An AI coding agent, recorded on every row it wrote.
Accepted by
A named engineer at Eliyce. Name withheld on this page.
Verdict
Inconclusive: 12 gates passed, 0 failed, 3 not measured.
Delivered
Merged 12 September 2026, 20:50 UTC, pull request #559. Released in paqad-ai 1.87.0.
Stages
6 of 6 recorded. 34 min 20 s of recorded work.
Last verified
17 September 2026, 16:29 UTC, by paqad-ai 1.87.0 reading the record again.
Start where the change started: with what was agreed, before any code.
01 · What was agreed
The specification was frozen before any code.
The AI drafted it through a pipeline grounded in the project’s own documents. Two specialist reviewer roles, a solution architect and a QA engineer, added ten findings; all ten were accepted. A person confirmed the two invariants and signed off at 19:14 UTC on 12 September 2026. Had the goal changed mid-build, the work would have stopped and asked.
What the change had to do
The change made one step of Paqad’s own method mandatory. Before an AI edits source code, the rules that apply to those files must be loaded and recorded. A new command works out which rules apply, prints them and writes a record with a fingerprint of the rule text. The first source edit is blocked until that record exists. At the end of the change a gate fails a change that never loaded its rules, reads Inconclusive when the record went stale, and is skipped where it does not apply.
Acceptance criteria, as frozen
- AC-1, proven by test. When rules load runs for an enabled change, a rules-loaded record is written with the applicable rule ids, matched paths and a hash of the rule text, and the full rule text is printed.
- AC-2, proven by test. Without the record, a source edit is blocked and names the command to run; once the record exists the edit is allowed; a documentation-only edit is never blocked.
- AC-3, proven by test. The completion gate reads fail with no record, pass when the record covers the change, inconclusive when it is stale, and skipped where it does not apply.
- AC-4, checked by a person. The evidence and the narration describe rules as loaded and acknowledged, never as comprehended or guaranteed to be followed.
Invariants, confirmed by a person
- The command, the edit-time gate and the completion gate all derive the rule set and the hashed rule text from one canonical composer, so no divergent copy can drift the recorded hash.
- Only an absent record blocks. A stale record reads inconclusive and never blocks, so a change in progress never deadlocks.
Explicitly not in scope
- Judging whether the loaded rules were understood or correctly applied.
- Adding a setting to make rule-loading optional or tunable.
Signed off by a named person on 12 September 2026 at 19:14:29 UTC. Specification fingerprint c0453573635cc988…9234ec64a6f6 (SHA-256 of the frozen text). Five open defects at freeze, all major, none critical; a critical defect refuses the freeze. Zero questions to the human. Produced by the specification pipeline under strict adoption: a hand-written specification would have been refused without a recorded reason.
Frozen at 19:14. Nine minutes later the code was written.
02 · What changed
Six commits, thirty files, every edit witnessed.
Development ran from 19:14 to 19:23 UTC. Every file save passed the framework’s checkpoints (framework loaded, plan and specification recorded with fingerprints, no open decision, no rule violated by the edit) and was witnessed into the ledger. The six commits were made between 20:31 and 20:32 UTC, after the review and the checks, each stamped into the record by a git hook as it was made.
Commits on the branch
- 617634e3 · chore: sync framework-managed config and mcp files
- f689b256 · feat(#557): rules-loaded evidence artifact and canonical rule-text composer
- a1d04133 · feat(#557): paqad-ai rules load verb
- 998fb4c3 · feat(#557): edit-time rules-loaded kernel capability
- cb337d20 · feat(#557): completion-seam rules-loaded gate
- 4c26d9cc · docs(#557): teach required rule-loading in router, workflow and module docs
Merged into main through pull request #559 on 12 September at 20:50 UTC, by a person. Released in paqad-ai 1.87.0 on 13 September. The local record carries no merge stamp because the merge happened on GitHub and that hook runs on a local pull. Thirty files were in the scope of the checks, seven of them unit-test files.
The rules, loaded on record
Twenty-seven applicable rules were loaded and recorded for the changed files: nineteen always loaded (among them Security, Testing, Code Quality, Observability, Git, CI/CD) and eight matched by the changed paths. The rule text was fingerprinted so the record cannot point at an empty or altered file. The record attests that the rules were loaded and acknowledged; it does not claim they were understood, and the framework says so in its own words.
One honest detail. This change is the one that introduced the requirement, so the framework version that was running could not yet enforce it on this very change. The record was written at 19:41 UTC, when the new command was run on its own change. On every change since, the record must exist before the first source edit.
Reuse before new code
The plan consulted the code index six times, declared six existing functions it would reuse and justified five new constructs in writing, each checked against the nearest existing code. The plan could not have been compiled without this section.
Decisions written into the plan
- No configuration switch. Rule loading is required, not tunable, in the same way stages default to strict.
- Absent fails, stale reads Inconclusive. A change with no record fails like a missing plan; a stale record never blocks, so a change in progress never deadlocks.
- Presence, not coverage, at edit time. The edit-time gate asks only whether the record exists, so editing a new file never deadlocks. Coverage is judged at the end.
- An optional manifest entry. The record is declared optional in the bundle manifest because a dedicated gate enforces it.
985
Meaningful changed lines.
1.0 %
Near-duplicate new code: one near-copy in a test file, the standard scaffold, kept to match its neighbours. Warn mode, not blocking.
16.4
Reuse rate: calls into existing, untouched code per 100 changed lines (162 calls).
Every edit witnessed, every commit stamped. Now, what proved them.
03 · What was tested
Exit codes decided. The review is on the record.
Three commands from the project’s own configuration ran in the checks stage. Their exit codes, not anyone’s description of them, are what the verdict reads. The checks file lands in the record; the final judge reads that file, not the chat.
- format · pnpm format · exit code 0 · 12.2 s
- build · pnpm build · exit code 0 · 11.1 s
- test · pnpm test with the TAP reporter · exit code 0 · 1 min 54 s
Test mode: the runner’s own parallel mode. No isolation re-runs, no flaky quarantine. The record marks the run “meaningful green”: a chained command can no longer report green without running a single test.
An honest gap. The test runner’s output did not parse into per-test rows in this record, so the checks file carries the exit code and the duration, not a test count. The reviewer recorded the count separately and it is labelled as the reviewer’s statement.
Rule scripts and near-copies
Fifty-two rule-script sweeps ran over the change: 209 findings, all heuristic (candidates for a person to judge), zero deterministic violations, nothing blocked. One near-copy was flagged on new code, warn mode, not blocking.
The recorded review
Verdict: safe to merge, the reviewer’s judgement. Three findings, all minor: one contested the flagged near-copy as test scaffold, with the reason; one dismissed three heuristic scanner hits as false positives, naming each file and why; one recorded the honesty scope, that the record attests loading and not comprehension. AC-1 to AC-3 were checked by the named automated tests, AC-4 by reading the evidence and the documentation; a regression note confirms no existing test was weakened.
The reviewer’s statement, as recorded: “full CI green (typecheck, lint, format, 9142 tests, graph-ui, build), branch coverage 95.00%”. This figure is the reviewer’s; the checks file carries the exit codes. A rollback plan is recorded: the files and entries to revert, and the note that no data migration is involved.
The commands decided and the reviewer signed. One question remains: why not Safe to merge?
04 · What is still open
The verdict is Inconclusive, and the record says exactly why.
When the AI’s turn ended, an independent program read the ledger and the checks file and graded fifteen gates. Twelve passed. None failed. Three could not be measured this run, and the framework refuses to round “not measured” up to “passed”. So the sealed verdict is Inconclusive, not Safe to merge.
- Acceptance criteria to tests · pass · machine
- Specification review · pass · judged
- Implementation review · pass · judged
- Change completeness · pass · machine (no code diff at verification)
- Mutation testing · pass · machine (did not run; no signal to evaluate)
- Quality ratchet · pass · machine (every measure held equal or better)
- Duplication · pass · machine (one near-copy flagged, warn mode)
- Module documentation structure · pass · machine
- Instruction documentation structure · pass · machine
- Documentation freshness · pass · machine
- Extension surface · pass · machine
- Ratchet: strictness · pass · machine (held at 3)
- Ratchet: dead code · not measured (traceability map unavailable)
- Ratchet: tangledness · not measured (tool not wired)
- Ratchet: risky patterns · not measured (tool not wired)
Open, in plain words: three quality measures (dead code, tangledness, risky patterns) were not measured because their tools are not wired in yet. One near-copy in a test file is flagged for a person to judge. Nothing else. “Machine” means a script proved it. “Judged” means a model assessed it and the record says so. “Not measured” is reported as not measured, never as passed.
That is the answer the first line promised: nothing failed, three things could not be measured, and the framework says so instead of rounding up. Here is the whole evening, minute by minute.
The timeline
Three hours from request to merge, six refusals, one receipt.
Times are UTC on 12 September 2026 unless stated. Each stage end that names a file also stores the fingerprint of that file’s exact bytes at that moment.
- 19:00 → 19:07 · Planning, 7 min 15 s. Plan compiled and fingerprinted; reuse declared; four decisions and two risks written down.
- 19:07 → 19:14 · Specification, 6 min 57 s. Pipeline run with two expert roles; frozen with a person’s sign-off at 19:14:29; fingerprinted.
- 19:14 → 19:23 · Development, 8 min 53 s. Edits witnessed live by the checkpoint that runs before every file save.
- 19:23 → 19:33 · Checks, 9 min 29 s. Format, build and test; rule scripts swept the change.
- 19:33 · Documentation sync, 22 s. Closed by the independent verifier rather than by the AI.
- 19:33 → 20:06 · The verifier refused to close the change six times: the review had not been recorded, so the change could not end. The refusals are part of the record.
- 19:41 · Rules loaded on record: 27 applicable rules, rule text fingerprinted.
- 20:27 → 20:28 · Review, 1 min 23 s. Recorded and fingerprinted: verdict, three findings, what was checked, rollback plan.
- 20:29 → 20:31 · Checks run, 2 min 18 s. Format, build and test with exit codes and durations written to the checks file.
- 20:31 → 20:32 · Six commits made, in sequence, each linked into the record by the post-commit hook.
- 20:33 · Pull request #559 opened onto main, with the record. Opening a pull request pushes the branch, so the framework asked first.
- 20:50 · Merged by a person. One decision, seventeen minutes after the pull request opened. The release bot published paqad-ai 1.87.0 the next morning.
- 17 September, 16:29 · Receipt sealed and re-verified: paqad-ai 1.87.0 read the record again, recomputed the hash chain and sealed the verdict: Inconclusive.
Six refusals, one decision. Who did what.
Who did what, and the seal
Written by an AI. Accepted by a person. Sealed by a script.
Written by
An AI coding agent, recorded on every row it wrote.
Accepted by
A named engineer at Eliyce, recorded by name in the receipt and in the AI bill of materials. Not shown on this page.
Judged by
The framework’s independent verifier (paqad-ai 1.87.0): a separate program that read only what was on disk. The AI’s chat was not an input.
The receipt is an in-toto statement in a DSSE-shaped envelope, the format used in supply-chain security, hash-chained to the previous receipt of the same change. Its integrity recomputes from its own bytes: tamper-evident, not a cryptographic signature, and we do not call it one. The inventory is an AI bill of materials in the CycloneDX 1.6 format, carrying the same result, the graded counts and the authorship.
What this record proves: that the method ran, in this order, on these files, with these results, and who accepted it. What it does not prove: that the code is correct or secure. The reviewer’s “safe to merge” is a judgement and is labelled as one. The loaded rules were loaded, not necessarily understood. A measure that could not be taken reads “not measured”, never “passed”.
Six words carry the whole record.
How to read a record
Six words carry the whole thing.
The same words appear in the framework’s chat, in its pull-request comment, in the report and in the team view. They mean the same everywhere.
Safe to merge
Every gate the framework ran passed. It attests the gates, not that the change is beyond all error.
Needs your attention
A gate is blocking. The receipt names it. Resolve before merging.
Inconclusive
A gate could not reach a confident result. “Could not verify” never rounds up to “verified”.
Machine
A script proved it: a file exists with this fingerprint, a command exited 0, these rules matched these files.
Judged
A model assessed it, and the row says so. It never borrows the credibility of a machine result.
Not measured
The measure could not be taken this run, and the record says why.
Source: bundle 557-require-rule-loading-evidence-for-feature-dev-changes in the evidence ledger of the paqad-ai repository, generated by paqad-ai 1.87.0 and read on 17 September 2026. The ledger is kept out of version control by default, so the record files themselves are not on GitHub; the code change is: issue #557 and pull request #559.
Key facts
Four numbers to take away
27
rules loaded and recorded for the changed files, with the rule text fingerprinted
Change #557, 12 September 2026
52
rule-script sweeps over the change: 209 heuristic findings for a person, zero deterministic violations
Change #557, 12 September 2026
6
refusals by the independent verifier before the change was allowed to close
Change #557, 12 September 2026
1
decision asked of a person, the merge, seventeen minutes after the pull request opened
Change #557, 12 September 2026
Questions
What people ask about this record
Real. Every line comes from files Paqad wrote while change #557 to its own repository was made on 12 September 2026. Only long identifiers were shortened and one person’s name withheld.
Three quality measures, dead code, tangledness and risky patterns, could not be measured because their tools are not wired in yet. The framework reports not measured as not measured, never as passed, so the sealed verdict cannot read Safe to merge.
The code change is public: issue #557 and pull request #559 in the Eliyce/paqad-ai repository on GitHub, released in paqad-ai 1.87.0. The record files themselves live in the ledger, which is kept out of version control by default.
No. It proves the method ran, in this order, on these files, with these results, and who accepted it. Correctness and security are judged by the tests and the reviewer, and the record labels those as judgements.
Last reviewed 18 September 2026 by Eliyce.
See this for your own software.
Every change delivered this way, by your team or by ours, leaves a record like this one. Tell us how your team ships today.
We reply within one working day. Or write to hello@eliyce.com.