RESOURCES
Technical resources.
Technical briefs, verification material, security documentation, case studies and terminology for systems that need to be inspected rather than merely described.
OVERVIEW
Documentation should explain the boundary as well as the capability.
Resources are organized around architecture, evidence, verification, security and terminology. The purpose is to make system claims easier to interrogate: what state exists, what produced it, what can be independently checked, what remains outside scope and which system owns the decision.
Technical briefs
Architecture briefs describe runtime roles, data and authority boundaries, deployment assumptions, failure behavior and integration surfaces. A brief should let a technical reader understand where a system begins and ends before anyone reaches for implementation detail.
Verification material
Verification resources distinguish receipts, hashes, signatures, manifests, timestamps, releases and independent verification. These are related controls, not interchangeable synonyms for “trusted.”
Security
Security resources separate public posture, responsible disclosure, authorized testing and engagement-specific Rules of Engagement. Reporting a suspected vulnerability is not the same permission as actively testing a production system.
Glossary
The glossary defines the operating language used across agentic runtime, deterministic state, evidence, intelligence, compilation and Network-Centric Operations, including where similar terms intentionally mean different things.
Case studies
Case studies record engineering problems, methods, results and evidence boundaries. They are not converted into customer claims unless the underlying deployment and result are separately supported.