CORAL report verification
Type: agentic-system-analyses/types/agentic-system-verification.md
Verification
The reports support a bounded source account. No material correction is required. I read the complete pinned boundary, four reports, reconciliation and contracts. The four correction-answer files are empty. The supplied structural report says none; there is no structural finding to route. I assessed the declarations, annotations, evidence layers, statuses, source anchors, containment relations and reconciliation dispositions, rather than accepting the analysts' validation statements as semantic verification.
The checkout HEAD equals the reviewed boundary and its working tree is clean. All independent source inspection below uses SRC-1 from the Source register, at that revision. I read source only; I did not execute CORAL, its helpers, tests, examples or services. The inspected implementation establishes wiring or conditional affordances, not exercised behavior or benefit. Nothing found contradicts the enclosing-runtime classification or the functional whole-system boundary. The latter includes shipped consumers; it does not imply exhaustive inspection of every grader or adapter.
Runtime and delivered workflow
I independently traced manager provisioning and launch, submission, grading, terminal-record construction, monitor selection, resume and migration. The source anchors are SRC-1, coral/agent/manager.py, coral/hooks/post_commit.py, coral/grader/daemon.py, coral/grader/subprocess_grader.py, coral/agent/registry.py and the inspected adapter files. The following distinctions survive the trace:
- RT-OBJ-task-config, RT-CMP-model-endpoints and RT-RTE-agent-launch distinguish symbolic configuration and model identifiers from opaque provider parameters. The launch code supplies model names, files and process arguments; it does not establish fixed weights or CORAL-owned inner tool turns. Per-agent mounts apply after generated settings. Provider mutability and external context policies remain qualified, not classified as absent.
- RT-RTE-eval-submission, RT-OBJ-attempt and RT-RTE-grader-execution correctly order producer-side queue checking, code commit, shared checkpoint, pending publication and detached-checkout grading. A failed result does not undo the commit. Worker timeout and errors differ from a grader's internally returned failure bundle. The checkout isolates the selected code snapshot from live edits, not all external dependencies or hostile effects.
- RT-RTE-heartbeat-feedback preserves two consequential qualifications visible in the monitor: all scored-new files become seen before one latest attempt is selected, and interval counts are advanced separately from real-budget plateau history. Neither per-attempt feedback delivery nor a universal tune exclusion follows. The implementation status applies to scheduling and prompt delivery, not completed consolidation.
- RT-RTE-resume-steering and RT-RTE-island-migration distinguish code selection, attempt archival, session reuse and shared-link changes. Resume checks ancestry and falls back to a fresh prompt when session recovery fails. Migration moves per-agent artifacts and changes shared roots while leaving source notes and skills behind. Neither path establishes atomic rollback or conversation erasure. Migration selection and cooldown searches in SRC-1,
coral/agent/migration.py, agree with the stated score-directed policy.
The circle-packing path was traced through the complete task and grader, then through the CLI wait and export functions: SRC-1, examples/circle_packing/task.yaml, examples/circle_packing/grader/src/circle_packing_grader/grader.py and coral/cli/eval.py. The geometric checks, numerical tolerances and recomputed sum support the bounded oracle account. The wrapper omits rejection details from the ordinary explanation. The workflow's feedback qualification is therefore consequential and correct, not an analyst disagreement. A CLI wait timeout leaves grading pending; it is not a rejected candidate. WF-RTE-candidate-export and EPI-RTE-code-selection correctly identify caller-selected Git effects without a score/status gate. The workflow does not claim deployment or successful execution of the packaged example.
I also checked the forcing claims. SRC-1, coral/agent/builtin/claude_code.py, coral/agent/builtin/codex.py, coral/agent/runtime.py and coral/sandbox/srt.py support RT-CLM-isolation-scope: outer wrapping is conditional, Codex bypasses native approvals on both paths, and settings can be overridden. Process containment remains an external deployment contract. The direct registry instance, manager keyword call and explicit Pi signature support the static mismatch in RT-CLM-pi-launch, including when the passed sandbox is None. No successful Pi launch is inferred.
RT-RTE-machinery-admission separates executable imports and mounted settings from the authoring procedure requested by plugin guidance. Registry and worker import checks are not semantic-safety checks. RT-RTE-specialist-delegation and RT-BAP-generated-instructions correctly leave inner delegation and compliance host-mediated. RT-CLM-agent-organizations remains an attributed improvement claim compared with infrastructure, not a demonstrated outcome. The runtime declares no evidenced absence.
Memory and epistemic reliance
I traced shared-file producers and actual consumers independently: SRC-1, coral/workspace/project.py, coral/hub/checkpoint.py, coral/hub/notes.py, coral/hub/skills.py, coral/cli/query.py, coral/web/api.py, coral/agent/warmstart.py and the manager's session and arrival-note functions. The object distinctions in MEM-OBJ-notes, MEM-OBJ-raw-sources, MEM-OBJ-note-navigation, MEM-OBJ-skills, MEM-OBJ-roles, MEM-OBJ-checkpoint, MEM-OBJ-migration-arrival and MEM-OBJ-session-state remain supported. In particular, snapshots are not lessons, session IDs are not conversation summaries, review sidecars are not captured sources, and executable skill resources are not merely prose.
MEM-RTE-knowledge-query correctly follows the consumer after selection: search returns discovery summaries, numeric reads omit the status predicate, nonnumeric reads concatenate bodies, and API skill detail selects a first matching directory rather than reproducing CLI ambiguity handling. Raw display is opt-in. Thus the positive query routes do not imply uniform addressing, automatic recall or a common token budget. MEM-BAP-retained-guidance distinguishes delivery from reliance.
For MEM-RTE-note-maintenance, I checked SRC-1, coral/template/skills/organize-files/SKILL.md and its move, index and resolver scripts. Flat frontmatter rewriting cannot support lossless structured provenance. The index excludes top-level _archive/; the hub walker does not. Authored supersession edges also leave nodes present. These are reader-dependent visibility rules, not uniform withdrawal. The report's afforded end-to-end status is appropriate despite executable helper steps.
I compared MEM-RTE-knowledge-revision with the separately declared epistemic functions, using SRC-1, coral/template/skills/deep-research/SKILL.md, coral/template/skills/deep-research/agents/synthesis-reviewer.md, coral/hub/prompts/reflect.md, coral/hub/prompts/consolidate.md and coral/template/skills/skill-creator/SKILL.md. Requested acquisition, synthesis, textual-support review and author disposition are distinct. The afforded revision path and doctrine-only epistemic functions describe different levels of the chain; their statuses need not be identical. Neither claims an observed accepted novel theory. The separate theory-builder, reflection, learning and self-improvement qualifications do not turn missing execution into an architectural absence.
The epistemic object records preserve raw assertions, research claims and review judgments separately. EPI-OBJ-attempt-score and EPI-OBJ-attempt-feedback correctly separate fixed numeric consumers from interpreted explanations. The daemon calls a first numeric result improved; that label alone cannot establish progress over a baseline.
The complete check bodies and exit paths in SRC-1, coral/template/skills/deep-research/scripts/check_grounding.py and coral/template/skills/create-notes/scripts/lint.py support MEM-CLM-grounding-gate, EPI-CLM-grounding-check, EPI-RTE-grounding-check and EPI-RTE-note-lint. Existence of a review file and a supplied verified flag are not verdict inspection or experiment rechecking. The static counterexamples do not pretend to be executed tests. EPI-RTE-note-selection licenses string-based selection, not truth adjudication. All other epistemic ledger functions preserve evaluator domain, separate checking from disposition, and withhold observed operation. No evidenced absence is declared.
Reconciliation and omission searches
The reconciliation makes no supersession and identifies no unresolved inter-report conflict. I checked each proposed overlap rather than merging by similar label. The broader memory containers retain distinct skill, role, legacy-format or read-back scope; the epistemic declarations isolate narrower content/functions. Export is a part of the broader direct-code-selection family, not the same whole route. The three explicit Part of: relations hold: score and feedback belong to the attempt, and the arrival announcement is an output part of migration. None requires replacing a valid container. Differences in inspections, reader paths and evidence layers do not constitute conflicting findings. The memory integration issues receive dispositions without selecting stronger statuses.
Omission questions came from the frozen tree and producer/consumer dependencies, not only the reports' anchor lists. I investigated whether alternate template selection removes retained-knowledge read-back, whether additional maintenance evaluators invalidate a score-only interpretation, whether export bypasses grading approval, and whether the exact example configuration can be conflated with the default launch. SRC-1, coral/template/coral_single.md.template retains note/skill orientation and subsequent knowledge-writing instructions. SRC-1, coral/template/presets/docker-opencode.yaml confirms the example's distinct OpenCode/Docker configuration. These checks preserve the reports' bounded conclusions rather than establishing host parity or a successful run.
The maintenance search found the separately instructed dedup judge and paired skill evaluations. Their existence agrees with the memory account and the epistemic report's explicit unassessed scope; the partial evaluator inventory is retained as a limit below. These are doctrine/design passages, not observed checks:
Save the verdict and reasoning to
output_path. Do not modify either note — the main agent executes the merge / rename / flag based on your output. ---coral/template/skills/organize-files/agents/dedup-judge.mdFor each test case, spawn two subagents in the same turn — one with the skill, one without (baseline). ---
coral/template/skills/skill-creator/SKILL.md
Further omission expansion stopped because the selected challenges have dispositions, the reports do not emit complete-system negative or coverage values, and no identified material contradiction remains. Other example graders, adapters and frontend internals could refine inventories but are not needed to support the emitted route findings. Their uninspected behavior is not evidence of absence.
Blockers
none
Limits
- The evaluator inventory is partial across retained-knowledge maintenance and skill optimization. MEM-RTE-note-maintenance, MEM-OBJ-skills, MEM-RTE-knowledge-revision and the epistemic coverage boundary do not supply a complete function-by-function epistemic assessment of these alternatives. Independent inspection of SRC-1,
coral/template/skills/organize-files/agents/dedup-judge.mdandcoral/template/skills/skill-creator/SKILL.mdconfirms requested content-sensitive dedup adjudication and with-skill/without-skill tests. These do not refute the inspected grounding/lint limits or establish exercised acceptance, but readers must withhold comparisons claiming that task scores and synthesis review exhaust CORAL's evaluators, or that all skill/maintenance acceptance criteria were assessed. The memory report's missing-helper qualification still prevents inferring a bundled autonomous optimizer.