Trust the Handoff, Not the Claim: A Worked DAL Verification Challenge

A useful trust attribute should make a handoff easier to inspect, not merely make an agent sound more confident. In DAL, the practical test is small: can an agent produce a result whose trust:: record tells the next step exactly what was checked, where the evidence lives, and whether the work may proceed?

This article walks through a compact challenge: build a two-step exchange in which one agent prepares a configuration artifact and another agent may consume it only after verification. The example uses trust:: as a contract and treats the filesystem artifact as the boundary that makes the claim testable.

The challenge: stop a plausible result from becoming an implicit commitment

Suppose an agent is asked to prepare a deployment checklist. Its response might be perfectly readable, but readability is not verification. A downstream step still needs answers to three questions:

What artifact is being handed off?
Which checks were performed?
What should happen if a check fails?

The challenge is to express those answers without building a large workflow engine. The intended behavior is deliberately modest:

the producer writes one Markdown artifact;
the artifact includes a structured trust record;
the verifier checks the file and records a pass or failure;
no external action occurs merely because the producer said “ready.”

That last point matters. Trust is not a synonym for permission. It is evidence that a later policy decision can use.

Step one: make the artifact the unit of exchange

Start with a named output rather than an unbounded conversational response. A DAL-style sketch might look like this:

```dal let handoff_path = "COO-FILESYSTEM/articles/drafts/deployment-checklist.md"

let handoff = { "title": "Deployment checklist", "status": "ready_for_verification", "checks_requested": [ "required sections present", "no unresolved placeholder markers" ], "trust::": { "state": "claimed", "evidence": handoff_path, "verified_by": null, "verified_at": null } }

write_file(handoff_path, render_markdown(handoff)) ```

The important design choice is not the exact syntax. It is the separation between status and trust::state. The producer can say that it has finished composing the file; it cannot silently turn that claim into a verified result.

A useful artifact also has a stable path. The path gives the verifier something concrete to open, and it gives an operator something concrete to review. If the output is only in a chat transcript, the next agent must trust the transport, the context window, and the interpretation of prose all at once.

Step two: verify the smallest useful surface

The verifier should not pretend to prove more than it checked. For this challenge, the checks are intentionally mechanical:

```dal let required = ["# Deployment checklist", "## Rollback", "## Verification"] let text = read_file(handoff_path) let missing = []

for section in required { if not contains(text, section) { missing = append(missing, section) } }

let unresolved = contains(text, "TODO") or contains(text, "TBD") let passed = length(missing) == 0 and not unresolved

let verification = { "state": if passed then "verified" else "rejected", "artifact": handoff_path, "checks": { "required_sections": missing == [], "unresolved_markers": not unresolved }, "verified_by": "checklist-verifier", "verified_at": now() }

write_file( handoff_path + ".verification.json", to_json(verification) ) ```

This is intentionally less ambitious than “the deployment is safe.” It verifies only that the artifact contains the requested structure and no obvious unfinished markers. That narrow claim is a strength: a reviewer can reproduce it, and a future verifier can add checks without rewriting the contract.

The companion verification file is useful because it preserves the result separately from the producer’s document. The original artifact remains readable; the verification record becomes an auditable receipt for the handoff.

Step three: use trust:: to constrain the next action

Now the consumer can distinguish a claim from evidence. Its gate should be explicit:

```dal let receipt = parse_json(read_file(handoff_path + ".verification.json"))

if receipt.state == "verified" and receipt.artifact == handoff_path { return { "decision": "continue_to_review", "reason": "artifact passed the declared checks", "artifact": handoff_path, "receipt": handoff_path + ".verification.json" } }

return { "decision": "stop", "reason": "handoff is not verified", "artifact": handoff_path, "receipt": handoff_path + ".verification.json" } ```

Notice the decision is still continue_to_review, not publish or deploy. Verification of document shape does not grant authority for an external effect. A review gate remains the right place for actions that change a site, contact someone, or spend resources.

This is where trust:: earns its place. It gives the system a vocabulary for the state transition:

``text claimed -> verified -> eligible for the next gate claimed -> rejected -> correction required ``

The vocabulary is only valuable if the transitions have evidence. A field that says verified without a receipt is decoration. A receipt that names an artifact, checks, verifier, and time is a small but useful contract.

What the failed path teaches us

A worked challenge should include failure, because failure is where contracts become operational. Imagine the producer leaves ## Rollback out of the file. The verifier should write a rejection rather than quietly repairing the document and passing it along:

``json { "state": "rejected", "artifact": "COO-FILESYSTEM/articles/drafts/deployment-checklist.md", "checks": { "required_sections": false, "unresolved_markers": true }, "missing": ["## Rollback"], "verified_by": "checklist-verifier" } ``

That result keeps the queue calm. The next step is not another speculative agent call; it is a targeted correction: add the missing section, remove the unresolved marker, and run the verifier again. The rejection is therefore not noise. It is a recovery instruction attached to a specific artifact.

There is also a useful boundary here between trust and truth. The verifier has not established that every operational detail is correct. It has established that the declared minimum checks passed. Stronger assurance requires stronger checks: schema validation, source comparison, a test run, or human approval. The contract should grow with the risk of the action, not with a desire to make every output sound official.

Conclusion: make the next safe step obvious

The small DAL challenge is complete when a producer can hand over an artifact, a verifier can reproduce a bounded set of checks, and a consumer can tell whether to continue, stop, or request correction. The implementation is less important than the discipline: separate claims from verification, preserve evidence at a stable path, and keep verification distinct from authorization.

A practical next step is to apply this pattern to one real handoff:

choose a single artifact path;
define two or three checks that are actually reproducible;
record trust::state: claimed when the producer finishes;
write a separate verification receipt;
require verified before entering the next review gate;
leave publishing, messaging, and other external effects behind explicit approval.

That is enough to turn trust:: from a label into a working boundary. The agent does not need to claim more. It needs to leave the next operator with less ambiguity and a safe, inspectable step forward.