The runtime request contract defines the operational boundary for a model-backed task. It makes identity, task, risk, context, route, tools, memory, budget, approval, output, trace, classification, retention, deadline, and idempotency explicit before execution.
Key takeaways
- A request identifier correlates one logical request; an idempotency key prevents duplicate effects.
- Permissions and allowed tools are explicit—not inferred from a prompt.
- Raw sensitive inputs are not required for a useful trace.
[ar_contract type=”runtime”]
Purpose and invariants
The contract is accepted only when the version is supported, identifiers are valid, timestamps are UTC, required authority is resolved, and the requested risk and retention policies are allowed. The runtime may narrow permissions or route choices, but it must not silently broaden them.
Field specification
| Field | Meaning | Security note |
|---|---|---|
| contractVersion | Semantic version of the request schema | Reject unsupported major versions |
| requestId / correlationId | Logical request and cross-system correlation | Non-secret, stable, unique in scope |
| idempotencyKey | Deduplicates a logical side-effect attempt | Bound to actor, operation, and scope |
| timestampUtc / deadlineUtc | Admission time and execution deadline | Use RFC 3339/ISO 8601 UTC ending in Z |
| actor / tenant / session | Identity and ownership context | Resolved from authenticated systems, not model text |
| taskType / riskLevel / input | Declared work, consequence, and payload | Validate classification and size |
| permissions / allowedTools / toolPolicy | Maximum authority and tool constraints | Runtime may narrow, never broaden silently |
| contextPolicy | Allowed sources, provenance, freshness, and limits | Prevents indiscriminate retrieval |
| modelRouteConstraints | Allowed deployments, providers, regions, capabilities, and fallback | Data and policy follow the route |
| memoryPolicy | Readable/writable scopes and retention behavior | No implicit durable memory |
| budget | Time, tokens, cost, steps, tools, and retries | Enforced across attempts |
| approvalPolicy | Actions and conditions requiring approval | Approval has authority and expiry |
| outputContract | Schema, format, citations, and validation | Model output remains untrusted until validated |
| traceSettings | Correlation, sampling, and payload policy | Raw input capture defaults off |
| dataClassification / retentionPolicy | Handling and lifecycle | Apply to derived records and artifacts |
| metadata | Namespaced extension values | Must not become an authority bypass |
Minimal example
A minimal request still carries identity, route, tool, memory, budget, output, trace, classification, and retention boundaries. It is minimal in optional detail, not in safety semantics.
[ar_downloads file=”runtime-request-minimal.json”]
High-risk example
The high-risk example includes deadline, tenant context, restricted routes, approval-required write tools, narrower egress, evidence requirements, and stronger retention/redaction.
[ar_downloads file=”runtime-request-high-risk.json”]
Validation
- Parse with duplicate-key and size protections where supported.
- Validate JSON Schema structure and formats.
- Validate semantic compatibility: version, task type, risk, routes, tools, classification, retention.
- Resolve actor and tenant from trusted identity, comparing rather than trusting payload claims.
- Check deadlines and budgets before execution.
- Return stable errors without echoing secrets or full input.
Error model
| Code | Meaning | Retryable |
|---|---|---|
| contract.invalid | Schema or semantic validation failed | No; caller must correct |
| contract.unsupported-version | Major version unsupported | No; negotiate or migrate |
| identity.mismatch | Payload actor/tenant conflicts with authenticated context | No |
| route.unavailable | No permitted route can meet constraints | Maybe, after availability changes |
| budget.exhausted | Time, token, cost, step, or retry budget ended | Only with new authority |
| approval.required | Execution paused before a protected action | Resume after valid approval |
Versioning and compatibility
Use semantic versions. A new major version may remove or redefine fields. Minor versions add backward-compatible fields or enum values only when old consumers safely ignore them. Patch versions clarify validation without changing meaning. Persist the accepted contract version with evidence and keep migration tests for supported histories.
Security and redaction
- Do not place bearer tokens, private keys, or secrets in the contract.
- Use references to protected context and credentials.
- Validate URLs and egress destinations against policy.
- Limit metadata size and namespace extensions.
- Redact or tokenize sensitive identifiers in broad telemetry.
- Keep full input only when a documented purpose, access control, retention, and consent justify it.
Downloads
[ar_downloads file=”aruntime-runtime-request.schema.json”][ar_downloads file=”aruntime-runtime-contract.schema.json”]