Agent Trust & Assurance

This is the operations manual for the whole Agent Trust & Assurance stack. It is the single place an administrator comes to understand why the assurance capabilities exist, what each one is, and how to operate them together as one process — Grounding, Guardrails, Evaluation, Observability/Ops, the Ontology and its Governance, the Trust Membrane, Agent Authority, and Data-Product Governance.

This document is self-contained in its Why, What, and How. You can read it end to end and fully understand the mission, every capability, and how to operate the whole process — without opening anything else. The architecture documents linked throughout are optional deeper reading on internals (data models, code seams); they are never required to understand what a capability is, why it exists, or how to run it. If you administer a production Uderia deployment, this is your runbook.

Version: last updated 18 July 2026. This manual tracks a fast-moving platform; verify capability status against the linked architecture and roadmap documents for anything time-sensitive.

Part 1 — WHY: the mission

1.1 The trust problem

An LLM agent is powerful and, by default, untrustworthy for enterprise use. Left ungoverned it will:

• Hallucinate — answer confidently from parametric memory instead of your data.
• Drift out of scope — reach for data it was never meant to touch. (Uderia's own documented failure mode: an agent received a complete, scope-correct 21 KB knowledge enrichment, ignored it, brute-forced 19 calls across unrelated databases, and produced a confident, wrong 230-day answer.)
• Act with borrowed authority — a scheduled task or a sub-agent runs as you, with your full permissions, unattributed.
• Consume unvalidated ingredients — ground on a knowledge graph, knowledge repository, champion-case store, skill, or pack nobody checked, shared from who-knows-where. An agent cannot be signed until each of them is: for a knowledge-focused agent that means its corpus must be screened and signed first, because the corpus is the agent.
• Leak or absorb harm — leak personal data, or be steered by a hidden instruction buried in a document.
• Degrade silently — quality erodes turn over turn with nothing measuring it.

Enterprises cannot deploy what they cannot trust. Every one of these is a trust failure, not a security failure — the platform can be perfectly secure and still produce a confidently wrong, out-of-scope, unattributable answer.

1.2 The mission

Make agents trusted. Turn an AI agent from an opaque generator into a grounded, guarded, measured, attributable, and verifiable participant in the enterprise — without sacrificing the openness that makes the platform useful.

Trust is not one feature. It is a stack of independent, composable layers, each closing one failure mode, each safe to run on its own, and each strongest when run together.

1.3 The two pillars — and where this manual sits

Uderia separates two concerns that are often conflated:

Security keeps the doors locked. Assurance makes the thing inside the doors trustworthy. Both map onto external frameworks (EU AI Act, NIST AI RMF, GDPR) — see §5.

1.4 The design principles (why the stack behaves the way it does)

Every capability in this manual was built to the same principles. Knowing them tells you how the whole system will behave under your hand:

1. Safe by default. Every capability ships off, or observe-only. A fresh deployment behaves exactly like an ungoverned one until you turn something on. You are never surprised; you opt into rigor deliberately.
2. Show, don't block (for sharing). Trust is visible and verifiable, and by default it informs rather than blocks. Sharing stays open; enforcement is a choice you make.
3. When in doubt, refuse (for enforcement). Where a capability does enforce (grounding, guardrails, agent-identity limits), any internal error denies — it never quietly permits.
4. Applies to every kind of agent. Assurance works the same for all five kinds of agent (Ideate, Focus, Optimize, Coordinate, Conversation) — not just the tool-using ones.
5. Trust ≠ access. A checked thing is not an authorised one. Signing proves an agent and its parts are intact and unchanged; it grants no permissions. Authority is a separate concern (Agent Authority).
6. Defence in layers. No single control is the whole answer. A turn passes through several independent checks; each catches what the others miss.
7. Honest about limits. Where a capability is the attainable form of a larger goal, this manual says so plainly. (The long-standing example — Agent Authority limiting what an agent can do while limiting what data it can see stayed "the OBDA future" — has since closed: signed data products shipped Aug 2026, and a surface-only agent's data authority is now literally the set of signed products on its surface. See §2.12.)

Part 2 — WHAT: the assurance stack

2.0 The trust lifecycle of a single turn

The capabilities are not a menu — they are a pipeline. One agent turn passes through them in order, and that ordering is the assurance process:

                    ┌─────────────────────── one agent turn ───────────────────────┐
  user / trigger →  │ ① INBOUND GUARDRAIL  → ② IDENTITY (who is acting, scope set)   │
                    │        → ③ GROUNDING trusted-scope stamped                     │
                    │        → engine runs: every tool call ④ IDENTITY-ENFORCED       │
                    │        → answer drafted                                         │
                    │        → ⑤ OUTBOUND GUARD (personal data/toxicity) → ⑥ GROUNDING │
                    │        → ⑦ EVAL scores the turn → ⑧ PROVENANCE sealed (signed)  │  → answer
                    └───────────────────────────────────────────────────────────────┘
        everything grounds on ⓪ THE ONTOLOGY;  the agent + its ingredients carry a ⑨ TRUST BADGE;
        the whole flow is watched in ⑩ OBSERVABILITY (Agents / Sessions lenses)

Each numbered stage is a capability below. Read Part 2 to know what each is; read Part 3 to know how to operate them.

2.1 ⓪ The Ontology — the knowledge foundation

Everything trustworthy an agent says is anchored to a knowledge model of your business — the ontology. It captures both the business view (the entities that matter and their attributes) and how that maps to the real data (the tables and columns behind them), plus business concepts, metrics, and domain terms.

• Why it matters for trust: the ontology is the boundary grounding holds the agent to, and its concepts are what the agent should reason over instead of guessing. No ontology → nothing for grounding to check against.
• The Platform Ontology ("Ontology" view) is the whole-deployment map, centred on your agents — showing agents, their memory, sessions, knowledge, components, and configuration — so you can see what grounds what.
• Deeper reading (internals, optional): ONTOLOGY_ARCHITECTURE.md · PLATFORM_ONTOLOGY_ARCHITECTURE.md · KG_INSPECTOR_ARCHITECTURE.md

2.2 ③⑥ Grounding — anti-hallucination, enforced

Grounding checks every answer against the knowledge the agent was actually given, and can pass · annotate · block confident-but-wrong drift. It closes the failure mode in §1.1.

• What "declared scope" is: the specific data the agent's knowledge model says it is allowed to draw on — for example, the sales databases and their tables. An answer that reaches for anything outside that (a different database, an invented table) is drift.
• Process (how it runs): a quick check flags any answer that references data outside the declared scope; a second opinion then confirms whether it is genuine drift — an honest "that isn't in my scope" refusal is allowed through, a confident answer built on out-of-scope data is caught. If the second opinion can't run, the turn is only flagged, never wrongly withheld.
• Modes (set per agent): observe (measure only, changes nothing) · annotate (deliver the answer with a note) · review (withhold exactly as enforce, but park the original for the owner's disposition — human oversight, nothing lost) · enforce (withhold a confirmed out-of-scope answer).
• Proof it works: a published test showed it went from catching none of the drift to catching all of it, with no false alarms — out-of-scope answers reaching users dropped to zero.
• Deeper reading (internals, optional): AGENT_OPS_EVAL_ARCHITECTURE.md §6a/§6b · TIER_1.1_GROUNDING_GATE.md · TIER_1.4_BENCHMARK.md

2.3 ①⑤ Guardrails — protection on both edges

Fast, free protection at both ends of the conversation (it adds no cost — no extra model call):

• Incoming — catches a hidden instruction planted in a request or document trying to hijack the agent. When enforcing, that request is refused before the agent ever reads it.
• Outgoing — catches personal data (email addresses, national ID numbers, card numbers, phone numbers, access keys, bank account numbers, IP addresses) and toxic content. When enforcing, personal data is masked and toxic answers are withheld.
• Process (how it runs): the incoming request is screened before the agent sees it, and the drafted answer is screened before it's delivered; either way a note records what was caught.
• Privacy promise: the note names the category found — never the actual value.
• Modes: two postures, each with one property — Observe (☑ disclose findings to the reader stores the composite annotate) and Enforce (☑ keep withheld originals in the Assurance Inbox for my review stores the composite review — enforce with retention, a human owes each parked item a disposition). Under plain Enforce a FULL withholding still retains its original as a quiet recoverable entry (no action owed); routine personal-data redactions never auto-park. The outgoing and incoming (prompt-injection) postures are chosen per agent on its Guardrails card, under the overall guardrails switch.
• Deeper reading (internals, optional): TIER_1.3_GUARDRAILS.md

2.4 ②④ Agent Authority — the agent as a governed principal

When an agent acts on its own — a coordinator's expert, a scheduled task, a step in a flow, a call from another system — it takes on a limited identity derived from its owner: a strict subset of what the owner could do. Every attempted action is checked against that limit before it happens (and refused if it fails, safely), and every such action is recorded as done by the agent, not the person who owns it.

• Scope (set per profile): may it act unattended at all · read-only (no writes) · specific tools it may never use · which connectors it may reach · a spending cap per run. A scope can only ever remove authority, never add — an agent is always a subset of its owner.
• Process (how it runs): the moment an agent starts an unattended run it takes on this limited identity; every time it tries to use a tool, that attempt is checked against the limit before it happens, and refused if it's outside scope. The refusal is recorded, and the whole run is attributed to the agent rather than the owner.
• Honest scope: this limits what the agent can do. Limiting what data it can see ("cannot query outside its slice of the business model") is the next step — see the OBDA vision.
• Deeper reading (internals, optional): AGENT_AUTHORITY_ARCHITECTURE.md

2.5 ⑦ Evaluation — measuring every turn

Every turn is measured, for all five kinds of agent (not just the tool-using ones):

• Automatic scoring (free, always on): a suite of quick, rule-based checks grades each turn on cost, speed, tool success, whether it stayed in scope, how much work it took, whether it ended cleanly, how much of its data came from a governed data product (vs the agent free-forming its own query), and more. Each is banded Healthy / Review / Danger.
• Independent judging (optional, sampled): for the open-ended questions rules can't answer ("is this answer actually supported by the data?"), a panel of independent models judges the turn. Kept to a sample so it stays cheap.
• Seeing how the panel voted: when judges run, the Agent Quality Judged step shows the ruling first — a tally such as 3 pass · 1 fail, with any failing dimension named on that line rather than hidden behind a click. Opening it reveals one row per dimension: each judge's vote (✓ pass · ✗ fail · ? abstained, the model named in the tooltip) beside the final consensus, and each judge's reasoning under a further disclosure. A model that could not be parsed shows as an abstention, never as a pass — an abstaining judge is part of the panel's composition, and hiding it would overstate the consensus.
• Choosing who sits on the panel: any LLM configuration can be excluded from judging (Config → LLMs → edit → Judging role) while continuing to answer normally. One panel serves both judge layers, so excluding a model removes it from the in-flight judge a gate escalates to and from the panel that scores quality afterwards — it is not a measurement-only setting. Worth doing for a model that regularly abstains because it did not respond in time: the panel waits for every member on every judged turn, so one silent model sets the pace of the whole evaluation without contributing a vote. Every model participates unless you say otherwise.
• If the panel did not return: the step reads LLM judge panel — no ruling and says so in the verdicts row, rather than showing a panel and a bill with nothing behind it. Judges that finished are kept; judges the cut-off silenced are recorded as abstentions naming the cut-off, so a missing dimension is never mistaken for one that did not apply.
• Process (how it runs): the instant a turn finishes it is scored automatically, off to the side so it never slows the answer; a fraction of turns is also judged. The result is recorded against that exact turn so it can be reviewed later.
• The Quality card appears on every turn (live and on reload), grouped into plain sections (Core · Resource · Tasks · Tools · Knowledge · Planning · Coordination · Quality). A turn might read speed 3.2 s (green), tool-success 100 % (green), stayed-in-scope: 3 out-of-scope calls (red), work 5 steps (amber) — each banded, so a degraded turn is legible at a glance. Nothing here alters the answer; evaluation measures, it does not gate.
• Deeper reading (internals, optional): AGENT_OPS_EVAL_ARCHITECTURE.md

2.6 ⑩ Observability & Ops — the two lenses

Assurance you can watch. Two views onto the same tamper-evident record of what happened:

• Awareness (formerly "Session Performance") — the per-conversation view: cost, speed, the full trajectory of a past turn, and its Quality card.
• Trust (formerly "Agent Performance") — the per-agent view: a colour-coded health roster (each agent's pass-rate, cost, speed, failing checks), a history of its runs, coordination trees for multi-agent work, and side-by-side comparison. Admins can switch between my agents and the whole system.
• The assurance dial — on every turn, one instrument showing which protections actually ran on that answer. It is a view over the platform's intervention registry: every point that can alter, withhold, constrain or attest an answer is declared once, and the dial renders what the record says — it derives nothing of its own. That matters because the dial's predecessor enumerated its stages by hand and silently omitted six real gates; a surface that claims to show the assurance path while leaving gates off it teaches you that what you see is what ran. While the turn is still running the dial fills station-by-station — you watch the inbound guard clear, watch grounding retrieve, then watch each gate report — rather than a ring that spins and settles all at once at the end. What it shows mid-turn is progress, never a verdict: a station takes its colour only when its machinery has finished (the one exception is a change already made to the answer, such as a redaction, which is surfaced immediately and labelled as an act). A protection with no evidence on a turn reads "not recorded", never as a pass.
• Process (how it runs): every turn is sealed into a tamper-evident record as it completes; both views — and the quality scores and trust checks — read from that same unforgeable record, so what you see is what actually happened.

2.7 ⑨ The Trust Membrane — verifiable trust for agents & artefacts

A tamper-evident signed badge on every agent and every shareable thing, on one principle: an agent is trusted exactly when everything it is built from is — its knowledge model and every skill, extension, and repository it uses must each be signed.

• Three states: ⚪ unsigned · 🟢 trusted (signed and unchanged) · 🟠 changed (signed, but the content has since moved — so trust is honestly withdrawn until re-signed).
• Compositional: the consumer reads one badge — on the agent — and the whole catalogue of parts hides behind it. Signing an agent is a single act that vouches for its whole make-up; if any part is unsigned, the agent can't be signed and you're shown exactly which part is blocking.
• Verifiable by anyone, even offline, with nothing but the signer's public identity; trust ≠ access (a signed thing is checked, not authorised); badge, not gate — nothing is ever blocked from being shared.

Every kind of thing that can be exposed — what gets signed, and what "trusted" means for it. Anything that can be shared (published to the marketplace) or built into an agent can be signed. There are ten kinds, and sign-off runs the right check for that kind — so "trusted" is transparent and means something specific each time (a signed skill was screened for hidden instructions; a signed extension had its code inspected for unsafe actions; a signed knowledge model was checked for validity). This table is the whole surface — nothing exposable is left uncovered:

Kinds 1–8 are individual things (signed on their own content); kinds 9–10 are bundles (signed only when all their parts are). Every check returns a plain verdict — clean (ready to sign), caveat (sign, with a note), or blocked (fix it first) — so sign-off is never a rubber stamp: it tells you exactly what, if anything, is wrong. A shared copy shows 🟢 only if it is an exact, unmodified copy of what was signed — which is why trust survives the marketplace: publish it, and whoever installs, subscribes to, or forks it sees the same honest badge.

• Deeper reading (internals, optional): TRUST_MEMBRANE_ARCHITECTURE.md · the full validator-per-class reference: TIER_5.2_VALIDATORS.md

2.8 Governance of products — ontology, packs, metrics

Trust's governance face — turning knowledge assets into governed data products with a release lifecycle:

• Ontology governance: a draft → propose → approve → release → retire lifecycle for the knowledge model, gated by a validity check — a thing can't be a governed ontology unless it's a valid one. Releasing fixes a version and signs a verifiable record of it.
• Agent-pack governance: the same lifecycle for a bundled agent (a "pack"), plus a service tier; you can require that a pack be trusted before it's published, so a distributed data product is always a governed one. Retiring a pack archives its conversations and stops new copies.
• Governed metrics: a business metric is defined once in the ontology and consumed by both the AI and business-intelligence tools from that one definition; each answer shows whether the metric comes from a governed, trusted ontology.
• Deeper reading (internals, optional): PACK_GOVERNANCE_ARCHITECTURE.md

2.9 Operational trust — consumption & cost

An agent you cannot bound is not operationally trustworthy. Per-user consumption limits (requests per hour, usage per month, configuration changes) and consumption tiers (Free / Pro / Enterprise / Unlimited) stop runaway cost; when a limit is reached, the request is refused rather than quietly allowed. Configured under Administration → App Config → Security. (Full detail lives with the platform-security pillar — noted here so the assurance stack is complete.)

2.10 Every trust process at a glance

Every trust-related process in one view — what value it delivers, how the process runs in plain terms, where you operate it, and how you see it working. Nothing in the stack is a black box.

2.11 The closed trust loop — how the new layers compose

The stack above no longer just measures and reports — it closes the loop:

1. Every turn renders its Trust Journey (the §2.0 pipeline as a live strip in the turn's trace) and offers the consumer an answer receipt.
2. Every agent's measured conduct feeds its behavioral trust state; the seal (integrity) and the ring (conduct) are one glyph on the roster.
3. Exhausting the trust budget trips the circuit breaker — alerting, and optionally freezing autonomy, instead of waiting for a human to notice.
4. Before tightening any policy, the backtest replays it over sealed history so enforcement decisions are made on evidence.
5. The three firewalls (memory, retrieval, tool-result — the last covering the connector/web lane and the ReAct engine) close the indirect-injection paths the edge guardrails cannot see; trust-aware routing makes compositional trust operative at coordination time, not just visible on a badge.

Nothing in this loop weakens the founding principles: everything ships off or observe-only, every enforcement fails closed, every action is attributable and visible, and computing any of it costs zero tokens.

2.12 Signed data products — determinism you can verify

The newest layer (Aug 2026) goes one level deeper than everything above: instead of observing, grading, or enforcing what an agent says, it constrains what an agent can even reach — and hands the reader a sealed receipt for every number that crossed the boundary. Full architecture: OBDA_ARCHITECTURE.md; the visual story: The Anatomy of a Signed Data Product on the trust site.

Reading the Products dialog (the gold Products button on an ontology's card — rendered only when the OBDA_ENABLED master is on):

• Each product row carries three chips: validated / unvalidated (has the gate run for this manifest?), signable / blocked (did it pass?), and the trust state (🟢 trusted · 🟠 changed · ⚪ unsigned). A product that was edited after signing reads 🟠 until re-validated and re-signed — the ratchet.
• The Verification selector chooses the evidence tier: Structural (declarations trusted, stated honestly in the report) or Live against a chosen database connection — the V7 probes execute the battery at the real target and empirically spot-check every declared cardinality and key. A contradiction blocks signing and names the declaration the data disagreed with. The report's mode (live vs structural) is part of what gets signed, so an empirically-verified signature is distinguishable from a declaration-trusting one.
• The grain-safety grid shows every measure × dimension pair: solid = safe, dashed = rejected (hover names the offending 1:N hop). A query outside this grid is refused, never silently multiplied.
• The sign ceremony states exactly what is attested: the manifest hash AND the validation-report hash — the proof travels inside the signature.

Reading a consumption. A governed answer's capsule ("Why trust this answer?") carries a Data products row — fitness_sales v1 · trusted · 32 rows — with the request hash, compiled-SQL hash and the seal note one hover away. The receipt is sealed into the turn's Ed25519 chain (step type obda.consumption) and rides the existing Export receipt, verifiable offline. The Governed-Data note's lane reads governed (all operations through products), free-form/mixed (the agent wrote raw SQL), or confined — every raw attempt was denied by the data surface and nothing executed: that is the protection working, and it reads as a pass at GROUNDED, never as a failure.

Confining an agent. The profile editor's Trust section carries the Data surface card: list the products, then either Surface-only (raw SQL denied fail-closed; only 🟢 products served; the one exception is the statement the surface itself compiled this turn, executed verbatim) or Advisory (nothing denied; violations observed and scored — the development mode). If a surface-only agent ever executes free-formed SQL, a danger surface_breach item lands in the Assurance Inbox — "a hole report, not agent misbehaviour" — because the structural confinement should have made that impossible.

The knowledge twin. The Knowledge card's Signed knowledge only toggle (requireSignedKnowledge) is the same posture for the other modality: only collections whose integrity signature is signed-and-intact back this agent's answers. If the trust suite is physically absent it fails open with a loud warning rather than silently emptying the knowledge lane.

Composition. A product built from signed products signs with its members' attested hashes inside its own signature (lineage). An unsigned member blocks the sign-off naming the member; a re-signed parent flips the composed child 🟠 until it is re-signed (and a parent shape change forces re-validation first).

Part 3 — HOW: operating the assurance process

This is the runbook. It assumes an admin-tier account.

3.0 Reading the Trust Circle

Where: Trust → Trust Circle. Pick an agent from the star at the centre, or leave it on the whole estate.

The ring is eight live readings of one agent (or the estate), arranged as the loop the assurance stack actually runs: configuration → behaviour → judgement → back to configuration. It is not an illustration; every station reads from the same records the REST API serves.

"The estate" always means your estate. Even in admin system scope — where the Sessions and Agents lenses can span every user — the ring restricts its execution readings to your own agents before any station reads them, because its configuration side (your profiles) and SIGNED (your attestations) can only ever describe yours. Both attributes of a reading describe one subject; 4/12 pairing your four profiles against twelve agents belonging to everyone is the exact mixed-subject reading the two-attribute model forbids.

Each station shows two things

Under every station you see a pair:

review · 1/4
   │       └── execution: what actually happened in the scored window
   └────────── configuration: how the control is set

Those answer different questions, and both matter:

• Configuration — is this control set up so it would work?
• Execution — did it actually work?

The pair is what makes drift visible. review · 1/4 means "configured to withhold a bad answer, but only 1 of 4 scored turns came through clean." Either number alone would mislead you.

One grammar, four channels (every trust ring in the product)

The same visual language holds on the Trust Circle, the per-answer assurance dial, the mini glyphs and the Assurance Inbox — each channel has exactly one job:

• Colour = attention priority. Green quiet · amber worth a look · red needs you now · grey = the absence family. Colour is never a verdict — the verdict is the word on the chip ("blocked", "masked", "parked", "clean").
• Ticks = engraving. One tick = detail recorded behind the mark; two ticks = a gate ACTED — on this answer (the dial) or on at least one turn in the window (the ring).
• The accent (orange) dot = an act is owed — sign, attest, or decide. Pin the station and the button to perform it is right there. Outstanding work is neither an event nor a verdict, so it rides the actionability channel, not the ticks and not the colour.
• Six states, everywhere: pass · warn · danger · not turned on (sparse dash) · not in yet (dense moving dash — a reading still coming) · not recorded (a gap in the trace, never mistakable for a pass).

What the numbers mean is decided by altitude, not by surface: estate = worst-of x/y agents · agent = mode · windowed rate · per turn = events (nothing is a rate).

Colour and the inbox correlate — by construction

An open inbox item folds into its station's colour (a danger item ⇒ the segment reads red until you decide or acknowledge it), and a station red from a failing rate files one ack-able station-shortfall observation per agent — so a red segment always resolves to a worked item in the Assurance Inbox, and acting on the item releases the fold. An acknowledgment means seen, never fixed: the measured rate stays red until the turns improve.

Where the numbers come from — press the "?"

Pin a station (click it) and a ? appears beside the close control. It opens "How these figures are derived": the population the figure was measured over, how each attribute was computed, and — where quality scores contribute — the contributing dimensions as clickable chips that open the Assurance Guide, scoped to that station and showing each dimension's live status.

This is the answer to the most common question about the ring: the ring counts TURNS; the Quality card counts CHECKS. 12/18 on GROUNDED means twelve of eighteen scored turns were clean on its dimensions — it is not comparable to the Quality card's "24 checks", which grades the one turn you are looking at.

Every check is counted at JUDGED. The other seven stations report what their machinery did. These are two different questions asked at two different moments. A guarantee station answers what ran during the turn — a gate that escalated, a guard that redacted, a boundary that denied a tool. A check answers how the finished answer graded, taken after it shipped by a scorer that changed nothing. So every check lands at JUDGED, whose whole subject is exactly that, and the seven guarantee stations read their own machinery alone.

The practical consequence: a red Grounding Overlap colours JUDGED, not GROUNDED. GROUNDED tells you what its four gates did; JUDGED tells you how the answer graded. Both are true, and reading them as one number was the confusion this change removed — a gate that did its job all turn could read red because a scorer graded the answer poorly afterwards, with nothing on screen saying which half had moved.

Each check still records which guarantee it is about — you see it as a chip on its Assurance Guide entry, and it is how you get from a poor score to the machinery that should have prevented it. That is a label for navigation; it is not where the check is counted.

The one place everything comes together is TRUSTED, the sole aggregate: a recency-weighted blend of the trust-critical checks with every remaining check, each counted exactly once, capped by integrity.

Inside JUDGED, the checks are grouped by the MOMENT they measure — Plan · Retrieve · Act · Compose · Deliver, plus The run (cost, latency, volume, termination) and Flow run for flow-agents. That is the process an agent actually runs, so a poor group points at a stage of the work rather than a category of metric.

What you can change, and what is fixed

Two things in the Assurance Guide look alike and are not equally under your control:

Deterministic dimensions come in three shapes, and the Guide says which one you are looking at:

The third is easy to mistake for the second. A dimension that never returns a verdict cannot fail a turn, so it never contributes to a station's clean count — it is there to be read, not to judge.

The Guide states this per dimension: open it (from a station's ? explainer, or "What do these mean?" on the roster) and each entry names its pass line, the exact admin key that moves it, or says plainly that there is nothing to set. The deterministic / LLM judge chip beside each name is the tell.

The Guide shows your CURRENT bands, not the shipped defaults. Each entry reads "Bands now: Healthy ≤ $0.30 · Danger > $0.60" for what is actually configured on this deployment, read live from the same settings the sliders write — so it stays right the moment you retune them, and the comparison direction follows the metric (≤/> where lower is better, ≥/< where higher is better). A metric you have not tuned says not set — measured, but not banded; the one exception is Grounding Overlap, where the scorer still applies a code fallback of Danger < 50%, and the Guide names it rather than implying nothing convicts. Out of the box only two metrics ship banded (max_out_of_scope_dbs, max_tool_calls).

Two lenses — the whole record and the current leg

The ring reads through one of two lenses, toggled at the top-left of the stage (Whole record · This leg) — the speedometer model: the odometer never resets, the trip meter does.

• Whole record (the default) — everything in the retained window, exactly as before. A trip reset changes nothing here, ever.
• This leg — each agent since its trip reset. After you fix an agent (re-tune it, quarantine a document, re-sign it), "Start a new leg" on the ring's narrative panel marks the moment; the leg lens then answers "how is it doing since the fix" without the old failures dragging the rates down, and the station explainers compare the leg against the previous one — did the fix work?

What a reset is not: it deletes nothing. Every turn, verdict, incident and review stays on the whole record; the reset appends an audited marker (who, when, your reason, and the agent's signing state at that moment) that appears in the agent's Trust History and its story. While the leg lens is active, every scoped reading names its boundary ("since 30 Jul") and an amber leg chip rides the ring — a clean leg can never masquerade as a clean history.

The same leg is available on the Agent Roster: expand an agent and a This leg pill sits beside the runs filters (only when a leg exists) — it scopes the dimension bars, the work mix and the runs ledger together, each section carrying the "this leg · since …" chip.

What the lens never touches: configuration readings (SIGNED, BOUNDED, the modes), the behavioral badge, the circuit breaker, and the audit pack all keep reading the whole record — the lens is how you look at the agent, not how the platform judges it. Only your own agents can be reset, and an empty leg reads "empty, not clean".

Why a station can read dashed rather than amber

Some protections are opt-in, and a station that guards one asks "is anything owed?" before it asks for your attention:

• SIGNED reads dashed until this deployment has signed something. Once you sign one artefact, signing is a practice here, and every unsigned agent becomes amber — outstanding.
• BOUNDED reads dashed when nothing can drive that agent unattended — no coordinator lists it as an expert, no scheduled task targets it, no flow node runs it. Authority scoping only protects unattended runs, so an agent nothing drives that way has nothing to bound. The question is asked per agent, not per estate: owning a coordinator does not put every agent at risk, only the experts that coordinator actually calls. Add an unscoped agent to a coordinator, a schedule or a flow and it turns amber.

Dashed means "nothing is owed" — never "we could not tell". Where the answer is uncertain the station reads amber, because an unnecessary amber is a smaller error than a dash hiding real exposure.

Where green ends and amber begins — configurable

A rate's colour comes from two floors: green at or above 0.80, amber at or above 0.50, red below. They are set once under Administration → App Config → Operations → Agent Evaluation → Quality bands, and every surface that colours a pass rate reads them — the roster bars, the Trust Circle's execution attribute, and the cross-agent KPI charts.

Raising the green floor turns currently-green agents amber immediately. It changes how quality is reported, never how a turn is scored or gated.

Only the numbers are configurable. Whether a gate acts (enforce/review can withhold an answer; observe/annotate only record) and worst-of aggregation across agents are properties of the system, not judgements about where a bar sits — a setting that let an observe-only gate read green, or turned worst-of into best-of, would manufacture exactly the false green this whole grammar exists to prevent.

Reading n= — why some dimensions have far fewer verdicts

A dimension's rate is only as strong as the number of turns it was decided on, and that number differs per dimension. The n= badge (on the roster bars and the explainer chips) is that denominator:

Colour is reserved for the rate's band and nothing else — a thin sample is marked by shape (the fraction form, the dimmed bar, a dashed chip edge), never by borrowing amber, which would put a perfectly healthy dimension under a warning tint. Every visual channel on a bar row is in that legend — colour (the band), the n= badge (its denominator), the fraction + dimming (thin evidence), the dashed judge marker (a model opined rather than a rule measuring). A channel that carries meaning but is not in the legend is a signal nobody can read; the grammar gate now asserts this.

Why judge dimensions have tiny denominators. Deterministic scoring is free and runs on every turn; the LLM-judge dimensions cost real tokens, so they are sampled (5% of turns by default, plus any anomalous turn). So Groundedness (RAG) 0% n=1 means "the one turn a judge looked at did not pass" — not "this agent is ungrounded". Read an amber n= as "worth a look at that one turn", never as a rate. Raise the judge sample rate under Administration → App Config → Trust → Scoring & evidence if you want a denominator you can trust.

Seven stations read no checks at all and say so in their explainer — they report what their mechanisms did, which is a different thing and the point of the split. Only JUDGED reads checks. Where a station's machinery did nothing this turn, the side renders a dash: honest absence, never a zero.

When two checks of the same thing disagree. A few dimensions measure one property twice — Grounding Overlap counts literal word overlap, Groundedness reads meaning and refines it. Where both decided a turn, what you see is the pair's standing, not the worse of the two: if the coarse check flagged an answer and the judge cleared it, the station reads worth a look and tells you why — "N turns flagged by the coarse lexical check and cleared by the judge that refines it". That usually means the answer paraphrases heavily (benign) or the judge was lenient (worth a glance). The numbers themselves are never rewritten — the chip still shows what was measured; only what it contributes to the station changes. A failure both checks agree on is never softened.

Reading REVIEWED on a quiet turn. A gate in review mode that ran and found nothing reads "armed — nothing on this answer needed a human", not "not turned on": the protection is in force, it simply had nothing to park. And when a request is refused at the door — the inbound guard blocking an injection before any model sees it — every layer downstream reads a dash with the cause named ("the request was refused before the agent ran"), because there was no retrieval to screen, no answer to ground and nothing to seal. That is the best outcome the guard can produce, and it must not render as a screen full of gaps.

A — means that side genuinely does not exist, not that it is broken or empty:

When one agent is in focus, SIGNED shows the state word — unsigned, not attested here, attested, changed — not a ratio. Focused on a single agent, 0/1 is the scope size wearing a ratio's clothes: it reads identically for an agent that was never signed and for one whose only outstanding act is the local attestation. Estate scope keeps the ratio, where it is real.

Every station's two attributes describe the same subject. Focused on one agent, REVIEWED shows that agent's queue; the estate figure is still named in the hover so a focused zero can never be misread as "the inbox is empty."

The colour tells you where to look, not whether you passed

This is the most important thing to internalise. Station colour is a call to attention, not a verdict. It answers "does this need me, and how urgently?" — because with eight stations, the only decision you actually make is where to look next.

Dashed always means nothing is waiting on you — never work you haven't done. SIGNED is the case where that matters: while nothing in your deployment has ever been signed, SIGNED reads dashed, because signing is opt-in and you have not opted in. The moment you sign your first agent, every unsigned agent turns amber — signing is now a practice here, so the rest are genuinely outstanding, and the hover says so: "sign-off is outstanding — this deployment signs agents and this one is not signed yet." The station becomes a to-do list exactly when it starts to mean something.

The colour is the worse of the two attributes, and the hover always tells you which one caused it — look for "needs you now because of execution". That distinction is the whole point: a design problem and an operating problem need opposite responses.

Two deliberate behaviours worth knowing:

• Green does not mean "nothing to see." Hover a quiet station and you still get its full reading. Green means nothing is waiting on you.
• Dashed is never counted as a problem. observe is a legitimate posture you chose, so a fresh install is not in alarm. It is shown, never tallied.

SIGNED also changes shape, because two ambers can mean different work

Colour answers how urgently, so two states that need you equally are the same amber — correct, but it left two genuinely different jobs looking identical. SIGNED therefore carries a second signal in its shape: the same seal you already see on profile cards and marketplace listings.

The button follows the shape. An agent that is publisher-signed but unattested is offered "Attest this deployment" — not "Sign this agent", which would be an act that cannot help.

Only SIGNED does this. The other seven stations have no such vocabulary to borrow, and inventing one per station is exactly the drift this grammar exists to prevent.

The summary line saves you the scan

Above the ring: "1 needs you now — SCORED · 3 worth a look — GROUNDED, BOUNDED, TRUSTED." Read that first. You should never have to scan eight glyphs to find the two that matter.

The hover is the same four slots, every station

CONFIGURATION   review
EXECUTION       12 of 14 turns clean on safety checks
────────────────────────────────────────────────
WHY             quiet   enforce and review can redact or withhold an answer;
                        observe and annotate only record
EVIDENCE        2 of the last 14 scored turns tripped a guardrail

The Execution row carries a unit-bearing figure — N of M turns, never a bare 4/4 "dimensions" (the I4 fix: "dimensions" reads as the 14 scored dimensions when it actually counts turns; the code now emits "N of M turns clean on safety checks" and the gate asserts it).

The top pair is what it says — the two attributes, with the value first because that is what you came to read. The pair below the line is why it says that: which rule produced the colour, and which concrete instances are behind it. When the colour was pulled by one attribute rather than the other, the Why row names it — worth a look · execution means the configuration is fine and the measurement isn't.

Always read Evidence. It is mandatory precisely so that a comfortable-looking count can never hide a finding. The clearest example: REVIEWED can read 0 open (nothing is waiting on your decision) while Evidence names a danger-severity observation sitting in the Assurance Inbox — because derived observations are recomputed from the sealed trace and carry no disposition to dispose of. The count is honest; Evidence is where the finding lives.

Clicking a station

A single click pins the station: the reading stays on screen and the station's actions appear beside it — because acting on a reading must not cost you the reading. Which actions appear is derived from the state, so SIGNED offers Sign this agent when sign-off is owed, Attest this deployment when only the local half is missing, and Verify offline when it is already signed (§3.5). Blocking ingredients get their own route, so a refusal is never a dead end.

Navigation stays available alongside them, and the driver decides which route leads: a station amber because its execution fell short opens this agent's runs, while one amber because of its configuration opens the posture matrix. The other route stays beneath it — reordering routes is honest, removing one is not.

Dismiss a pinned station five ways: Esc, clicking it again, clicking outside it, the ✕, or pinning another. It is never a trap.

Estate scope

With no agent selected, each station aggregates across every agent — worst-of, so one laggard keeps the station amber. The value then reads as a ratio (2/10 · 4/6), and Evidence names the laggards so you know who to fix. A green estate station means every agent is clean, not that at least one is.

Contract and conventions behind these readings: TRUST_STATUS_COMMUNICATION.md

3.0a Reading a station's modules — what actually assessed this

A station panel names the mechanisms that ran ("1 withheld", "nothing acted"). That tells you what happened, not why — which module produced the finding the mechanism acted on, or what it measured. Each mechanism row expands to exactly that.

Each row is property · module · what it found, with the module's own numbers beneath it (supported ratio 100%, 1 tool call). The property is the stable name on the left; the module is whatever is bound to it today — so after a remap the row shows the new module rather than a fossil of the old one's output. Clicking a row opens that property's entry in the Assurance Guide.

An abstention is not a pass. A module that could not run says so in words ("needs scope_databases, which this turn did not provide") and is drawn dashed — a turn with nothing to assess is a turn nobody checked, which is a different fact from a clean one.

How a module finding reaches the station colour. Through the mechanism, never around it:

assessor finding → mechanism reading → station colour (worst-of its mechanisms)

So a station goes amber because a mechanism read amber, and a mechanism reads amber because it folded a finding. The indirection is deliberate, not plumbing: the mechanism reading is the gate's own decision, which may legitimately differ from a raw finding. The clearest case is the grain heuristic — a module fires, the grain_faithfulness judge withdraws the verdict, and the reading is correctly a pass. If module findings coloured the ring directly, a withdrawn verdict would still light it up.

The failure mode to know about, because it has happened: a gate that assesses several branches (the honesty gate runs three — absence claims, retrieval sufficiency, and the library-provenance branch, which itself reports two kinds: a citation the turn never opened, and an identifier the library does not contain) must fold all of them into its one row. Reading only one branch's stamp produced a row saying "no unsupported absence claim" with a green dot, directly above its own module list saying "1 of 3 found something" — one mechanism, two answers, and a quiet station above both. A multi-branch mechanism reads worst-of its branches and names which one drove it, and still names the quiet ones, so you can tell checked and clean from not checked at all.

3.0b Reading the Assurance Guide's PROPERTIES

The Guide's other entries answer what does this measure and what does this control do. The Properties shelf answers the question underneath both: what is actually being assessed.

A property is the unit both lanes are about — a guarantee promises it, a control upholds it, a measurement grades it. Each entry states:

• assessed by — the module bound to each lane: during the turn (which can act on the answer) and after the turn (which reports only). Where one module serves both, the entry says so — the two can then never disagree about what was found, which is the whole point of the arrangement.
• graded by — the scored dimension that measures this property afterwards, as a link. Every property that has one carries the route; nine of the ten do.
• Where a lane has nothing bound, the entry says why. Request integrity is assessed in flight and deliberately never scored — whether a blocked request was truly an attack is not decidable from the turn, so its detector is measured against a curated corpus instead (the resilience self-test). That is a finished design, not a gap, and the entry distinguishes the two.

This is the surface a remapping UX will operate on. A property is permanent; which module assesses it is a binding, and bindings are data.

3.0c Reading the Agent Roster — three readings, not one

The roster's headline (44% live pass rate · 18 turns · 8 failed) answers one of the questions you can ask about an agent, and the words invite the others.

The third one is a preference, not a measurement, and the surface keeps it apart on purpose: a vote never moves the pass rate, a band, or a station colour (Rule 3bb.4). The line is absent entirely when nobody has voted — that is an honest absence, not a zero. In system scope you see no vote reading at all rather than someone else's zero.

Read the disagreement count first. It counts turns where the scorers and the person point in opposite directions — passed but downvoted, or failed but upvoted. That is the only signal in the platform where a human tells you the quality bands are wrong for this deployment; everything else is the platform grading itself. A rising disagreement count is your cue to revisit Config → Trust → Quality bands, not to discipline the agent. See §3.0d for what a vote actually changes.

The pass rate is the first one. A turn counts as failed when a check a rule measured landed in the danger band — unless the judge that refines it corrected that (the row then carries a judge-cleared mark saying why it is not a failure) — or a gate withheld the answer, so a withheld turn can never read clean. Amber flags but never convicts, and a judge alone never convicts: a model opined, no rule measured it.

Why it is not mechanism-driven. It would flatter the agent. On a real 18-turn sample, 16 turns had no mechanism act at all: an intervention-driven rate would have read 89% on an agent whose grounding measurements were the worst thing about it.

The two readings are close to independent. The same sample:

a mechanism acted  + measurements flagged :  0
a mechanism acted  + measurements clean   :  2      the system working
nothing acted      + measurements flagged :  5      <- look here first
nothing acted      + measurements clean   : 11

The third row is the one to act on: those answers were delivered, and the measurements say they were poorly grounded. No control caught them. That is the case for moving a gate from observe to enforce — and it is invisible in an intervention count, which reads 0 there.

The intervention reading. Beside the rate sits the mechanism axis — "2 of 18 answers altered or withheld · 2 parked for review". It answers what the rate cannot, and an agent nothing acted on says so plainly. A trailing "N turns where a guard did not run" means a control failed open on those turns: the honest reading is unknown, not pass, which is why it is shown here and not folded into the quality figure.

Reading a run row. Each row in the Runs Ledger carries a strip of marks — one per scored dimension, in station order, the same checks in the same columns on every row (a check that did not run on a turn appears dashed in its place), so a column can be read down the ledger. Three channels, none of them colour alone: fill is what the check found (solid passed · half worth a look · outlined failed · dashed did not run), shape is who measured it (square = a rule · diamond = a model), size is what the ruling could do (a larger diamond = a gate consulted that judge during the turn, so its verdict could withhold the answer; the plain diamond = sampled after it), and a centre dot means the rule measured a failure and the judge that refines it cleared the same answer. Hovering any mark says what that check found, not just what it is; the Key above the ledger draws all three.

Two chips appear only when they have something to say. withheld · parked, with a dot and — when something is owed — the accent colour, means a mechanism acted: what was delivered is not what the model wrote. The Acted filter isolates those turns, because which turns were altered is a different question from which scored badly. 1 judge flagged this appears when the scoring panel found a problem, and gate asked a judge · cleared when a gate consulted one mid-turn and did not act on it. A turn where every judge upheld carries no chip: the diamonds already say a judge ran and agreed.

Two words, two populations: a judge is one check asked once of the turn; its models are the panel voting inside it. So 1 judge flagged this counts checks, and 1/1 models counts panel members.

Reading the sparkline. One bar per turn, oldest → newest, driven by the same value as the rate — it is the rate's evidence, not a second signal. Pass is a full-height bar, fail is half-height, so you can read it without relying on colour. There is no amber bar: per turn the reading is binary, and amber lives on the rate (≥80% green, ≥50% amber, below red).

If a historical pass rate looks better than you remember, it is: turn failure is now resolved against the current gating policy rather than the value frozen onto the span when it was scored, so turns convicted by advisory-only checks under a retired rule no longer count. See the FAQ, §4.9.

3.0d What a vote actually changes

Rating an answer in the conversation panel is not a comment box. The rating reaches the mechanism behind that answer, and what it does depends on which engine produced it — hover either button and the tooltip tells you, for that agent, before you click.

Things worth knowing before you rely on it:

• A coordinator answer built from more than one expert propagates to nobody. The answer is a synthesis; blaming or crediting every expert would invent a judgement you never made. Single-expert answers propagate.
• It is reversible. Clearing a vote, or flipping it, undoes what it did — a retired plan competes again, paused memories resume.
• Nothing is deleted. A downvote demotes, excludes or pauses. Paused memories stay visible in the Memory manager and can be re-activated by hand; flagged documents are surfaced for you to look at, never auto-quarantined.
• Your votes are yours. Nobody else reads them, and they never affect another user's agents.
• It costs nothing by default. Every effect above is deterministic and spends zero tokens. The one exception is opt-in: an admin can enable judge on downvote, which runs the LLM judges on a rejected turn to explain it (Config → Trust). That spends tokens, ships off, and never overrides an agent whose judges you turned off.

Full mechanism: FEEDBACK_SIGNAL_ARCHITECTURE.md.

3.1 The operating posture — a maturity ladder

Do not switch everything to enforce on day one. The stack is designed for a graduated rollout: observe → measure → tighten. Every capability starts safe (baseline), so you climb the ladder deliberately.

You can stop at any rung; each is stable. Most production deployments live at stage 3–4.

3.2 The control map — where every switch lives

3.2a Third-party controls — what you are agreeing to when you raise one

A pack can ship a control: machinery that withholds, alters or annotates a live answer. Three things are true of every one of them, and they are what make raising one a decision you can make safely.

It arrives dormant. A third-party control installs at observe. It records what it would have done and changes nothing until you raise it here. Installing a pack can never, by itself, withhold an answer — so you can run a new pack for a week and read what it would have caught before giving it any power.

The act is the platform's, not the pack's. The pack chooses when to act and which act from a closed set (withhold · alter · annotate). Uderia performs it, and the posture ladder, the parking, the retention, the audit event and the reading on the Trust Circle are identical however the finding arrived. A pack cannot ship "always withhold, whatever the operator set": it declares what it wants at enforce, and every weaker posture is derived by the platform.

It cannot act unless its pack is signed and bound. A control only ever sees findings from a module you have assigned, and assigning requires a signature. An unsigned pack's control is inert at any posture — you do not have to remember this, it is structural.

Two things to know when you set one:

• Restore is not the same as choosing observe. Restoring forgets the decision (the control is dormant and nothing is recorded); choosing observe records that you decided it should watch. Only the first leaves this deployment's attestation.
• Raising a control moves the deployment attestation. The agent will read changed until you re-attest, exactly as it does when a bound module is swapped — because starting to withhold answers is the larger change of the two.

Platform gates behave differently on one point: their posture is per agent (the profile editor's Trust Configuration), not deployment-wide, so their rows here name where their mode is set rather than offering a switch.

Where the per-agent cards live: the profile editor has a dedicated Trust Configuration sidebar section, grouped by Trust Circle station — GROUNDED holds Grounding and Honesty (honesty's findings land at GROUNDED), GUARDED holds Guardrails, BOUNDED holds Agent Authority, JUDGED holds Judges. REVIEWED is armed by setting any gate to Review; SIGNED, TRUSTED and PROVEN have nothing per-profile to set. Cards open collapsed (a single-card section stays open).

Persistence note: the Agent Evaluation & Grounding card has its own Save button; its settings (eval, grounding master, guardrails master, thresholds) persist across restart. Per-profile cards save with the profile.

3.3 Runbook — standing up assurance on a new deployment

1. Turn on measurement. Config → Operations → Agent Evaluation & Grounding → enable online eval → Save. Leave judges sampled (or off to start). Nothing changes for users; you now have data.
2. Set grounding + guardrails to observe (switches on; the grounding and outgoing-guardrail modes at observe). Run real traffic for a few days.
3. Read the Agents roster. Left nav → Agents. Look for red/amber health, out-of-scope drift, personal-data exposure, cost outliers. This tells you which agents need enforcement.
4. Curate the ontology for the profiles that need grounding. Build/refine the KG; run the validity check; fix issues.
5. Tighten. Move the data-touching / externally-answering profiles to grounding enforce and guardrails enforce. Leave exploratory profiles at observe.
6. Sign and attest. Sign your production agents, then attest each deployment — two distinct acts (§3.5). Optionally enable Ontology/Pack governance approval.
7. Constrain autonomy. For any profile used by a scheduler, genie coordinator, or flow, set an Agent Authority scope (§3.8).
8. Establish a monitoring cadence (§3.9).

3.4 How the layers compose on one turn (defense in depth)

Understanding the ordering tells you what catches what, so you know which control to reach for when something slips through:

1. Inbound guardrail — a prompt-injection is refused before the model sees it.
2. Agent Authority — if autonomous, the principal + scope are set for this turn.
3. Grounding trusted-scope — the profile's bound-ontology scope is stamped onto the turn.
4. Tool calls — each MCP/component/connector call is identity-enforced (denied if out of scope).
5. Outgoing guard — personal data masked, toxic answers withheld.
6. Grounding gate — a confident out-of-scope answer is annotated or withheld.
7. Eval — the turn is scored; drift/cost/quality banded.
8. Provenance — the whole turn is sealed into the signed chain; the agent's trust badge reflects its (unchanged) composition.

A hallucination that slips past grounding may still be caught by evaluation; a personal-data leak the model generates is caught outbound; an injection is stopped inbound. No single layer is load-bearing.

3.5 Workflow — signing an agent, then attesting the deployment

Two acts, not one. An agent is partly portable and partly local, so its trust envelope has two halves and each is vouched for separately.

Signing (bottom-up)

1. Open the agent — its shield shows ⚪ unsigned and what is blocking it (unsigned parts).
2. Sign each blocking part from its own badge (the knowledge model, the skills, …). The screen walks you through it — "to sign this agent, these parts need signing first."
3. Sign the agent. That one act vouches for the whole make-up.
4. If any part later changes, the badge honestly flips 🟠; re-sign to re-affirm — but read which half moved first (see "When 🟠 changed means re-attest, not re-sign" below).
5. Anyone can verify the badge is genuine — including offline, on hand-off.

When 🟠 changed means re-attest, not re-sign

🟠 changed proves a baseline exists — the agent was vouched for, and something has moved since. It does not say which half moved, and the two have different remedies:

Re-signing a deployment-face drift cannot clear it — the portable signature was never broken. That is why the SIGNED panel offers the act that is owed rather than a generic "sign" button: an offered act that cannot help reads as the fix, which is worse than no button at all (Rule 8.5). The panel names the drift verbatim in its Evidence slot, so you can tell the two apart before you click.

Attesting the deployment

Signing alone does not turn a badge green. An agent you installed from a pack — or any agent whose deployment has never been attested here — reads ◒ deployment unattested: the author vouched, you haven't. SIGNED shows — · not attested here and offers "Attest this deployment".

6. Click the SIGNED station to pin it, then Attest this deployment. The station goes green and reads — · attested. You do not need to be an admin — attesting a deployment is the owner's act on their own agent, because it is a statement about a surface only they control ("this model, these tools, these connectors are what I intend here"). Signing off the artefact stays admin-only: that half vouches for something a third party can check.

Why it is a separate act. The three things most worth catching are a swapped model, a grown tool catalog (a write tool appearing where there were only reads) and a newly enabled connector — and those are exactly the three that cannot survive an install unchanged, because a subscriber runs their own model, their own server and has opted into nothing. Folding them into the portable signature would force a choice between two dishonest outcomes: every installed pack permanently 🟠 (which teaches people to ignore 🟠), or real widening hiding behind 🟢. Two halves avoid both.

What it buys you. Once attested, those three are drift-detected and the badge names what changed — "tools appeared: base_writeQuery(sql)", "connectors enabled: uderia-shell". An unexplained amber gets clicked through; a named one does not.

One honest limit. The tool catalog is read from the stored classification snapshot, not a live connection — so the badge resolves offline, but an upstream MCP server change is caught when the profile next re-classifies, not the instant it happens.

The fork trap — attest a freshly forked profile in the wrong order and it drifts on its own first use. A newly forked or installed profile's classification_results is not pre-populated — classification is lazy: it runs when the profile is first actually dispatched to while active for consumption, not at fork time. Attesting a deployment before that first run locks in an early (often empty or partial) snapshot as the baseline; the moment the agent is actually used — its classification runs, the catalog fills in for real, and the badge flips 🟠 changed ("tools appeared: …"), even though nothing insecure happened — the reachable surface was simply measured for the first time after, not before, the attestation. The safe order:

1. Fork or install the profile.
2. Activate it — run its connection test (Setup → Profiles), the same step every agent needs before it can be driven at all. This is what makes classification eligible to run.
3. Optionally force it explicitly: POST /v1/profiles/<id>/reclassify (it only actually reclassifies an active profile — on an inactive one it just clears the cache and asks you to activate first).
4. Then attest the deployment. The snapshot is settled, so the badge holds.

Attesting before step 2–3 is not wrong, exactly — the fix is the same either way (re-attest once classification has run) — but it produces a needless 🟠 the moment someone first uses the agent, which reads as a problem when it is really just late-arriving information.

3.6 Workflow — governing an ontology (validity → release)

1. Open the ontology's Govern dialog. Read its validity report: valid / partial / invalid, with the specific issues listed.
2. Fix what's invalid (the report is specific). A partial ontology can still be released, with a noted caveat.
3. Walk it through the lifecycle: draft → propose → approve → release. Releasing fixes a version and signs a verifiable record of it. If approval is required, the approver must be authorised and (by policy) not the owner.
4. Retire it when it's no longer current — a recorded, auditable act.

Honest note: "release" here means marking this version as the official one, which is a different act from sharing it on the marketplace. Today, releasing does not yet change which knowledge the agents actually use — they use the live model. Making release govern what agents ground on is a planned next step.

3.7 Workflow — governing an agent pack / data product

Open the pack's Govern dialog: a lifecycle stepper, a trust hero (affirms or nudges you to sign off), one primary CTA (the recommended next action), instant SLA pills, an activity timeline. Enable require-approval / require-trust in the admin Agent Pack Governance policy to enforce that a published pack is approved and trusted. Deprecation archives the pack's sessions and blocks new forks.

3.8 Workflow — scoping an agent that acts on its own

For any agent used unattended (scheduled tasks, a coordinator's experts, flow steps, calls from other systems):

1. Profile editor → Agent Authority card.
2. Decide the limits: keep it read-only? bar it from specific tools? restrict which connectors it may reach? cap its spend per run? Or switch off unattended use entirely.
3. Save. From then on, unattended runs act under those limits; the owner's own interactive use is unaffected.
4. Confirm in the audit trail: unattended actions show as done by the agent, and any blocked attempt is recorded.

3.9 Monitoring & triage

3.10 Recommended production posture (checklist)

• ☑ Online eval on; judges sampled (raise the rate for high-stakes deployments).
• ☑ Grounding enforce on every profile that answers from data or answers externally; observe on exploratory profiles.
• ☑ Guardrails on: enforce the outgoing mode on every externally-facing agent; incoming protection on via the overall switch.
• ☑ Production ontologies conformant and released; production agents signed (🟢).
• ☑ Every autonomously-used profile carries an Agent Authority scope (least privilege).
• ☑ Agent Pack Governance requires approval + trust for published packs (if you distribute).
• ☑ A weekly cadence on the Agents roster; triage any profile trending amber/red.

Part 4 — the capability & control reference

Part 5 — compliance mapping

Agent Trust & Assurance is how a Uderia deployment evidences AI-governance obligations:

• EU AI Act / NIST AI RMF — grounding (accuracy), guardrails (safety/robustness), evaluation (measurement/monitoring), provenance (traceability), agent identity (accountability), governance lifecycle (risk management).
• GDPR — personal-data detection and masking on the way out (categories only, never the raw value); consumption and data-product governance; the ability to erase what an agent remembers.
• The tamper-evident record of every turn, plus the signed quality and trust verdicts, give an auditor evidence they can verify independently — even offline.

Related documents

• Reading the surfaces: TRUST_UX_FAQ.md — the companion FAQ. This manual covers what each control does and how to operate it; the FAQ covers how to read what the ring, the Scorecard and the Assurance Guide are telling you — why a station is red, what a dot means, why a check is greyed out, and the mechanism-vs-measurement distinction every other question turns out to be about.
• Architecture (internals): AGENT_OPS_EVAL_ARCHITECTURE.md · TRUST_MEMBRANE_ARCHITECTURE.md · AGENT_AUTHORITY_ARCHITECTURE.md · ONTOLOGY_ARCHITECTURE.md · PLATFORM_ONTOLOGY_ARCHITECTURE.md · PACK_GOVERNANCE_ARCHITECTURE.md
• Roadmap / tier docs: TIER_1.1 · TIER_1.3 · TIER_1.4 · TIER_4.2 · TIER_4.3 · TIER_5.2 Trust Membrane · LEAPFROG_ROADMAP
• Delivered (Aug 2026): OBDA_ARCHITECTURE — grounding and identity made structural: signed data products, the data surface, sealed consumption receipts, the compositional ratchet. (The vision that predicted it: OBDA_VISION.)
• The other pillar: SECURITY_ARCHITECTURE.md