The ARuntime developer reference specifies boundaries for requests, tools, policy decisions, evidence, and traces. It does not assume a particular model provider or advertise a nonexistent SDK.
Key takeaways
- Validate contracts before expensive or consequential execution.
- Keep authorization, credentials, idempotency, and retention outside model prose.
- Design for partial failure and duplicate delivery.
- Correlate infrastructure, model, tool, policy, evaluation, and business outcomes without storing raw sensitive input by default.
Runtime design principles
- Models propose; runtimes decide. Model output is untrusted data until validated and authorized.
- Fail before side effects. Validate version, identity, risk, scope, budget, and output requirements during admission.
- Make effects typed. A tool contract declares input, output, permissions, side-effect class, retry, idempotency, approval, and compensation.
- Persist decisions, not every payload. Use protected references, hashes, and redaction metadata.
- Preserve attempt history. A later success does not erase prior failure or compensation.
- Version every boundary. Schemas, tools, policies, models, prompts, and traces evolve independently.
Contract set
Runtime request
Defines who is asking, what task is allowed, which context and routes may be used, budgets, approvals, output, trace, and retention.
Tool contract
Defines typed I/O, authentication reference, permission, side effects, egress, retry, idempotency, compensation, rate, and audit fields.
Policy and approval
Returns allow, deny, transform, require approval, or escalate with reasons, scope, authority, expiry, evidence, and review path.
Evidence record
Correlates contracts, context references, route, tools, policy, approvals, side effects, failures, recovery, evaluation, and output.
Trace record
Separates infrastructure, model, tool, policy, business, and evaluation spans while maintaining common correlation.
Implementation flow
- Parse JSON with strict error handling.
- Validate against the supported schema and compatibility policy.
- Resolve authenticated actor, tenant, and delegated workload identity.
- Classify data and risk; reject unknown or contradictory authority.
- Choose a model route from allowed deployments.
- Assemble minimized context with provenance and freshness.
- Validate model output against the output contract.
- Resolve a tool contract and evaluate policy.
- Acquire short-lived credentials and execute with timeout and idempotency.
- Validate result, update checkpoints, and persist minimized evidence.
- Evaluate the task outcome and finalize response or recovery.
Tool registry
The registry maps a stable tool identifier and version to schemas, owner, executable adapter, authentication reference, permission and side-effect class, egress policy, timeout, retry, idempotency, concurrency, approval triggers, compensation, errors, rate limits, observability, audit fields, and deprecation. Registration is an administrative action; a model cannot add a new privileged tool during a task.
State and checkpoints
Persist request identity, current phase, completed step results or artifact references, idempotency records, approval waits, budgets, and evidence correlation. Keep execution workers replaceable. Checkpoint before a side effect when recovery requires a stable pre-action state, and after a completed idempotent effect when replay must not repeat it.
Observability and evidence
Use stable request, correlation, trace, span, tool-operation, policy-decision, approval, and artifact identifiers. Infrastructure traces answer where time and resources went. Model traces answer which deployment and generation phase ran. Tool traces answer what external operation occurred. Policy events answer why an action was allowed or denied. Business and evaluation records answer whether the workflow achieved a valid outcome.
Testing stochastic workflows
- Schema conformance and unsupported-version errors
- Permission denial and expired approval
- Model timeout, refusal, malformed output, and route fallback
- Tool timeout before and after a side effect
- Duplicate delivery and idempotent result reuse
- Checkpoint loss, worker termination, and replay
- Prompt injection in retrieved content and tool results
- Trace/evidence outage and redaction policy
- Outcome evaluation across repeated stochastic runs
Runnable reference
The PHP 8.1+ example performs local contract validation, route selection, tool authorization, an idempotent non-destructive operation, evidence creation, and error handling. It does not call a model provider or persist raw input.
[ar_downloads file=”aruntime-reference-implementation-php.zip”]
Implementation checklist
- Pin contract versions and compatibility rules.
- Use valid UTC ISO 8601 timestamps.
- Keep secrets out of model input, logs, and evidence.
- Require explicit authority for external effects.
- Define retry and compensation per tool.
- Validate every state transition.
- Test cancellation and deadline propagation.
- Document retention and deletion for traces and memory.
- Publish a correction and deprecation path.