Understanding Your First Response
Anatomy of a governed AI response — trust boundaries, segments, and audit trail.
Understanding Your First Response
Every Raptor response is a structured message. Here's what each field means.
Response anatomy
{
"ok": true,
"reply": "The deployment is verified. Binary hash matches...",
"decision_type": "respond",
"trust_boundary": {
"primary": "verified",
"sublabel": "1 segments verified",
"actionability": { "level": "safe", "label": "All claims verified" },
"provenance": {
"execution_id": "abc-123",
"input_hash": "sha256:..."
}
},
"segments": [\
{\
"boundary": "confirmed",\
"text": "Binary hash matches the build attestation.",\
"basis": "attestation"\
}\
],
"decision_support": {
"confidence": "CLEAR",
"recommendation": "Deployment integrity confirmed.",
"basis": "Ed25519 attestation verified against signer trust registry."
},
"audit_trail": [\
{ "name": "intent_received", "time": "17:44:23 UTC", "status": "pass" },\
{ "name": "governance_evaluated", "time": "17:44:23 UTC", "status": "pass" },\
{ "name": "response_generated", "time": "17:44:24 UTC", "status": "pass" },\
{ "name": "response_attested", "time": "17:44:24 UTC", "status": "pass" }\
]
}
Trust boundary levels
| Level | Letter | Meaning |
|---|---|---|
| Confirmed | C | Verified against an authoritative source |
| Executed | X | Action ran with recorded result |
| Retrieved | R | Fetched from a system of record |
| Likely | L | High-confidence inference, not verified |
| Uncertain | U | Limited evidence, treat with caution |
Segments
A single AI response often contains multiple claims. Raptor does not assign one trust level to the entire response -- it classifies each claim independently.
The segments array breaks the response into individually governed pieces:
"segments": [\
{\
"boundary": "confirmed",\
"text": "Binary hash matches the build attestation.",\
"basis": "attestation"\
},\
{\
"boundary": "likely",\
"text": "The deployment should complete within the maintenance window.",\
"basis": "historical_pattern"\
}\
]
Each segment contains:
| Field | Description |
|---|---|
boundary |
Trust level for this specific claim (confirmed, executed, retrieved, likely, uncertain) |
text |
The exact text of the claim |
basis |
What evidence supports the classification (e.g., attestation, system_record, historical_pattern, model_inference) |
The top-level trust_boundary.primary reflects the lowest trust level across all segments. If one segment is likely and the rest are confirmed, the primary boundary is likely. This ensures the overall classification is conservative -- the response is only as trustworthy as its weakest claim.
The trust_boundary.sublabel summarizes the segment distribution (e.g., "2 segments confirmed, 1 likely").
Audit trail
Every governed response produces exactly four events in sequence. This is the governance chain:
"audit_trail": [\
{ "name": "intent_received", "time": "17:44:23 UTC", "status": "pass" },\
{ "name": "governance_evaluated", "time": "17:44:23 UTC", "status": "pass" },\
{ "name": "response_generated", "time": "17:44:24 UTC", "status": "pass" },\
{ "name": "response_attested", "time": "17:44:24 UTC", "status": "pass" }\
]
| Event | What happens |
|---|---|
| intent_received | The inbound message is captured, hashed, and logged. The decision engine classifies intent and determines capability requirements. |
| governance_evaluated | Active policies are checked against the request. Budget limits, capability gates, and tenant-level rules are enforced. If any policy blocks the request, the chain stops here with status: "blocked". |
| response_generated | The AI provider generates the response. The proposal layer structures the output and the commit layer assigns per-claim trust boundaries. |
| response_attested | The complete response (input hash, output, trust boundaries, policy decisions) is written to the hash-chained event log. This entry is immutable and forms the cryptographic proof that governance was applied. |
The chain is append-only. If governance_evaluated returns "blocked", no response is generated and no attestation is recorded -- the chain has only two events. A complete chain always has exactly four events with status: "pass".
These events are stored in the hash-chained event log and can be queried via the audit events endpoint (GET /api/tenant/audit/events).
Confidence levels
| Level | Threshold | Meaning |
|---|---|---|
| CLEAR | >= 95% | Proceed with confidence |
| RECOMMENDED | >= 80% | Strong recommendation |
| ADVISORY | >= 50% | Consider alternatives |
| INSUFFICIENT | < 50% | Do not act without further evidence |
Actionability
The actionability field tells you whether to act on the response:
- safe --- all claims verified, safe to act
- review --- contains inference, review before acting
- blocked --- review required, do not act without verification