Documentation
Developer documentation for governed agents
The Trunnion public documentation explains reference formats and evaluation methods for governed agentic systems without exposing private implementation details or customer data.
The public documentation is organized around decisions a technical evaluator needs to make: what is recorded, where authority is enforced, how a person approves an action, how the system fits the deployment boundary, and how evidence can be verified.
It intentionally separates public reference material from private product internals. Exact APIs, supported operations, release manifests and customer-specific control packages belong to the applicable product and engagement.
Where should an evaluator start?
- Read the hash-chained audit trail specification.
- Review the audit record format.
- Use the browser verifier on the public sample.
- Review attribute-based access control.
- Review human approval gates.
- Compare deployment envelopes.
- Map the workflow to NIST AI RMF.
Which contracts should a governed agent runtime expose?
At a minimum, the architecture should define typed contracts for identity, task, model endpoint, policy decision, approval, tool action, result receipt and audit record.
| Contract | Minimum question it answers |
|---|---|
| Identity | Who is acting, and on whose behalf? |
| Task | What bounded outcome is being pursued? |
| Model endpoint | Which model and data terms apply? |
| Policy decision | Is this exact action allowed, denied or reviewed? |
| Approval | Who approved which immutable parameters until when? |
| Tool action | What operation reaches which target? |
| Receipt | What did the target accept or change? |
| Audit record | Can another reviewer reconstruct and verify the chain? |
Closed or versioned contracts reduce ambiguity. Free-form tool descriptions are useful to a model but insufficient as an enforcement interface.
What belongs in release documentation?
Release documentation should identify source revision, build artifact, dependencies, model endpoints, policy bundle, tool adapter versions, schema versions, evaluation results, known limitations, deployment requirements and upgrade path.
Where a product supports multiple environments, document the differences. A cloud release and an air-gapped package may share application logic but differ in model serving, identity, monitoring, updates and support.
What belongs in an evidence package?
A strong evidence package connects claims to artifacts:
- action catalog and consequence classification;
- policy examples and negative tests;
- approval state and parameter-binding tests;
- audit schema and verifier results;
- state-change boundary coverage;
- model and workflow evaluation;
- deployment and dependency inventory;
- data flow and retention;
- cross-tenant and access-control tests;
- incident and recovery exercise;
- open limitations and accepted risk.
The package should name the exact release and environment. Architecture prose alone is not release evidence.
How are public examples scoped?
Public examples use invented identifiers and non-sensitive scenarios. They demonstrate structure and verification behavior, not deployed customer data or confidential Trunnion Core internals.
Do not paste production records, CUI, classified, export-controlled, procurement-sensitive or other restricted information into public tools. The interactive tools on this site run locally in the browser, but the public website is not an approved environment for restricted data.
How should standards be used?
Use standards for the part they actually specify. FIPS 180-4 defines secure hash algorithms. RFC 8785 defines JSON canonicalization. NIST SP 800-162 defines an ABAC model. NIST AI RMF provides risk-management outcomes. OWASP publishes agentic-security risks and mitigations.
None of those sources alone defines a complete governed agent runtime. The system has to compose them and state the boundary of each claim.
How can a team request product-specific documentation?
Use the contact page to identify the product, workflow and deployment lane. Do not send restricted content. Trunnion can then determine which current interfaces, manifests, evaluations and control evidence are appropriate for authorized review.
Direct answers
Frequently asked questions
Is this the production API documentation?
No. This public documentation provides reference concepts and formats. Product and release-specific interfaces are supplied through the applicable engagement.
Where is the audit record format?
The audit record documentation and public specification describe required fields, canonicalization, verification, privacy and failure handling.
Can the examples be used directly in production?
They are educational reference patterns. Adapt them to the system threat model, data classification, release process and approved technical standards.
Does Trunnion publish its private Core implementation?
No. Internal platform implementation details remain withheld pending intellectual-property clearance. Release evidence is shared through authorized diligence channels.
Are the standards links authoritative?
The linked standards bodies remain authoritative. Trunnion summaries and mappings should be checked against the current official publication.
How can a team evaluate a release?
Define the workflow and acceptance criteria, then request the exact control, evaluation and evidence package for the proposed product and environment.