The Trust Profile Challenge: Make an Agent’s Evidence Budget Visible

This article walks through a compact DAL design for that challenge: define a profile, attach it to a task, and finish with an artifact that another agent or operator can verify without rereading the whole run.

This article gives you a worked exercise rather than a tour of every trust feature: the goal is to build one bounded profile for a research agent and show where the contract catches an overconfident result.

The challenge: three claims, three evidence states

Imagine an agent asked to compare two implementation options. The request sounds simple, but its output can contain at least three different kinds of statements:

1. Observed: a source explicitly says something.
2. Derived: the agent combines observations into a conclusion.
3. Unknown: the available material does not establish the claim.

The failure mode is familiar: a polished paragraph makes all three sound equally certain. Our small challenge is to require the agent to produce a trust profile with these rules:

• every observed claim has a source reference;
• every derived claim names the observations it depends on;
• unknowns remain visible instead of being filled with plausible guesses;
• the final recommendation is allowed only when its evidence threshold is met.

The profile is not a score. It is a set of conditions for what the agent may say next.

Step 1: write the profile as a contract

A DAL-style profile can be expressed as data alongside the task. The exact shape can evolve, but keeping the fields explicit makes the profile inspectable:

``dal let research_profile = { name: "bounded-comparison-v1", claims: ["observed", "derived", "unknown"], require_source_for: ["observed"], require_dependencies_for: ["derived"], allow_unresolved: true, recommendation_requires: { minimum_observations: 2, unresolved_disqualifies: ["security", "cost"] } } ``

The important design choice is allow_unresolved: true. A profile that forbids uncertainty often produces a more dangerous result: the agent has an incentive to turn a missing source into a confident sentence. Allowing an explicit unknown gives the verifier something concrete to inspect.

If your project uses trust attributes, the same idea can be attached to the operation rather than kept as an informal prompt:

``dal @trust(profile="bounded-comparison-v1", evidence="required") fn compare_options(request, sources) -> comparison_report ``

Treat this as a contract boundary. The attribute does not magically make the report true; it tells the runtime and the reviewer which evidence obligations belong to this function.

Step 2: make the output an artifact, not a paragraph

The agent should return a report whose structure preserves provenance. A minimal result might look like this:

``dal let report = { question: request.question, observations: [ { id: "o1", text: "Option A supports the required export format.", source: "source-01#format" }, { id: "o2", text: "Option B has a documented lower operating cost.", source: "source-02#pricing" } ], conclusions: [ { id: "c1", text: "Option A is the safer fit for the export requirement.", depends_on: ["o1"] } ], unknowns: [ "No source establishes the long-term migration cost for either option." ], recommendation: null } ``

There are two advantages to this shape. First, a verifier can check a conclusion without trusting the agent’s narrative transitions. Second, a later handoff can preserve the evidence graph. The next agent does not need to guess which sentence was a source observation and which sentence was the first agent’s interpretation.

The null recommendation is intentional. Because migration cost is unresolved, the profile says that a recommendation cannot yet be issued on that dimension. The useful result is not “the agent failed”; it is a bounded report that tells the operator what evidence would unblock the decision.

Step 3: verify the profile before accepting the result

The verifier can be small. It does not need to repeat the research task; it needs to enforce the contract:

```dal fn verify_profile(report, profile) -> verification { let errors = []

for observation in report.observations { if profile.require_source_for.contains("observed") and observation.source == null { errors.push("observation_missing_source:" + observation.id) } }

for conclusion in report.conclusions { if profile.require_dependencies_for.contains("derived") and conclusion.depends_on.length == 0 { errors.push("conclusion_missing_dependencies:" + conclusion.id) } }

if report.recommendation != null { if report.observations.length < profile.recommendation_requires.minimum_observations { errors.push("recommendation_below_observation_threshold") } }

return { ok: errors.length == 0, errors: errors, unresolved: report.unknowns } } ```

The verifier’s restraint matters. It checks provenance and thresholds; it does not pretend to prove that a cited source is correct in the world. That deeper check can be a separate step with a separate artifact. Keeping the layers distinct prevents “the citation field exists” from being confused with “the claim was independently confirmed.”

A failed verification should also be an artifact. For example:

``text status: changes_required failed: conclusion_missing_dependencies:c1 next_step: attach observation IDs to every derived conclusion ``

That status is more actionable than a generic error string and can travel through a handoff or review queue.

What the challenge catches

Suppose the agent initially writes: “Option A is cheaper and easier to migrate.” The first half might be supported by a pricing source; the second might be an intuition. Under the profile, “cheaper” must point to an observation, while “easier to migrate” either points to evidence or moves into unknowns.

This is the value of a trust profile: it narrows the space of acceptable output before a reviewer has to debate the prose. It also makes honest incompleteness cheap. The agent can finish with a useful comparison and a precise evidence request instead of spending more steps manufacturing confidence.

The profile can be extended carefully. Add a freshness field if sources expire. Add a confirmation requirement for claims that affect an external action. Add a review_required result when the evidence is sufficient to inform a decision but not sufficient to authorize one. Each addition should correspond to a real failure mode, not a desire for a larger schema.

Next steps: run the exercise on one real workflow

Start with a task that already produces recurring overclaiming—research, procurement comparison, or an operational diagnosis. Then:

1. list the claim classes your workflow actually needs;
2. define the smallest profile that distinguishes them;
3. require sources and dependencies in the output artifact;
4. run a verifier that returns ok, changes_required, or an explicit unresolved set;
5. inspect the first few failures and adjust the profile, not the evidence standard downward.

A trust profile is successful when it changes the handoff. The receiving person or agent should be able to answer three questions quickly: what was observed, what was inferred, and what remains unverified? In DAL, that clarity can live in the contract and the artifact, so trust becomes something the system can check—not merely something the final paragraph asks the reader to assume.