A Trust Profile Is a Runtime Boundary, Not a Label

This article works through a compact DAL design for attaching a trust profile to a commitment, checking it before an external effect, and leaving a reviewable result behind.

The challenge: make “trusted” operational

Suppose an agent can research a destination and prepare a booking. We want three distinct outcomes:

• a low-risk research step may run automatically;
• a recommendation may be saved for review;
• a purchase must stop at an approval boundary.

A string such as trust_profile: careful does not achieve this by itself. The runtime needs a small contract that answers four questions:

1. What class of action is being attempted?
2. What evidence is required before that action can proceed?
3. Is approval required?
4. What artifact records the decision?

The goal is not to assign a permanent score to an agent. It is to constrain one commitment at one point in a workflow.

Define the profile as policy data

Start with data that is explicit enough for a checker to consume:

``dal trust_profiles = { "research": { "allowed_effects": ["read", "draft"], "requires_review": false, "evidence": ["sources"] }, "recommendation": { "allowed_effects": ["read", "draft", "propose"], "requires_review": true, "evidence": ["sources", "assumptions"] }, "purchase": { "allowed_effects": ["read", "draft", "propose", "buy"], "requires_review": true, "evidence": ["sources", "price", "approval"] } } ``

The important detail is that the profile describes effects and evidence, not personality. A purchase may be allowed in the abstract, while a particular purchase remains blocked until its evidence and approval are present.

Keep this map close to the policy boundary rather than burying it inside prompt text. Prompt instructions can explain intent; the checker should make the final decision.

Build a commitment with evidence slots

A commitment is the object that travels through the workflow. It should be inspectable before execution:

``dal commitment = { "id": "booking-2026-09-12-01", "profile": "purchase", "effect": "buy", "subject": "rail ticket", "evidence": { "sources": ["carrier timetable"], "price": "$84.20", "assumptions": ["refundable fare selected"], "approval": null }, "status": "proposed" } ``

This shape does two jobs. It gives the operator a concise review surface, and it prevents the execution step from having to reconstruct why the agent thinks an action is safe. Missing evidence is visible as a missing field, not hidden in a long transcript.

For a read-only research task, the same structure can be smaller. The contract should be proportional to the effect. A profile is not an excuse to demand purchase-grade evidence from every harmless lookup.

Check before crossing the effect boundary

The checker should return a decision rather than silently mutating the commitment:

```dal check_commitment = fn(c) { profile = trust_profiles[c.profile]

if profile == null { return {"decision": "deny", "reason": "unknown trust profile"} }

if !(c.effect in profile.allowed_effects) { return {"decision": "deny", "reason": "effect outside profile"} }

for field in profile.evidence { if c.evidence[field] == null { return {"decision": "review", "reason": "missing evidence: " + field} } }

if profile.requires_review && c.evidence.approval == null { return {"decision": "review", "reason": "approval required"} }

return {"decision": "allow", "reason": "profile requirements satisfied"} } ```

The exact syntax may vary with the host implementation, but the boundary is stable: resolve the profile, compare the requested effect, verify evidence, then require approval where policy says so.

Notice that review is not a failure. It is a useful terminal state for unattended work. The agent can finish its research, write the commitment, and stop without attempting the external effect.

Leave a receipt for every decision

A decision should produce an artifact that another operator or process can inspect later:

```dal result = check_commitment(commitment)

receipt = { "commitment_id": commitment.id, "profile": commitment.profile, "effect": commitment.effect, "decision": result.decision, "reason": result.reason, "checked_at": now() }

fs::write( "COO-FILESYSTEM/reviews/" + commitment.id + ".json", json::encode(receipt) ) ```

The receipt is intentionally narrower than a transcript. It records the policy inputs and the decision, not every thought that preceded them. That makes it suitable for queues, dashboards, and later diagnosis.

A practical implementation can add a hash of the commitment and a policy version. Those fields help detect whether someone reviewed one version of the evidence and executed another. They are especially valuable when profiles evolve over time.

Keep the profile narrow and composable

A single broad label such as high_trust tends to become an informal permission bypass. Prefer profiles that describe a bounded capability: research, recommendation, purchase, or message sending. If a workflow needs more capability, compose explicit checks rather than escalating a vague score.

Also separate identity from authorization. The profile can say what evidence and approval an action needs; it should not become a substitute for authenticating the principal who may approve it. In a production system, the approval receipt should identify the approver through the existing review mechanism.

Finally, make external effects the only hard boundary. Internal transformations can remain lightweight, while calls that send, buy, publish, delete, or otherwise change the outside world pass through the commitment check.

Conclusion: ship the smallest useful boundary

A workable trust profile does not need a sophisticated reputation model. It needs a small policy map, an inspectable commitment, a pre-effect checker, and a durable receipt.

A sensible next slice is:

1. define two or three effect-specific profiles;
2. require every external action to create a commitment;
3. return allow, review, or deny before transport;
4. write the decision receipt beside the review queue;
5. test missing evidence and stale approvals as first-class cases.

That design keeps the agent productive without making trust ambient. Research can continue, recommendations can wait in a calm queue, and irreversible effects remain explicit decisions rather than optimistic interpretations of a label.