Authority boundary
Memory is data, evidence is not authorization, and model output cannot become the authorization authority.
A private authority and governance layer designed to keep memory and model output from becoming implicit permission.
The problem
Autonomous engineering systems need a hard distinction between what they remember, what they infer, what they are authorized to do and what evidence proves they completed an action.
Verified capabilities
These capability descriptions are intentionally limited to the evidence-backed implementation surface.
Memory is data, evidence is not authorization, and model output cannot become the authorization authority.
Canonical receipts, hashing, signing, evidence references, redaction and verification form an evidence subsystem.
Authorization can be bound to an exact action digest rather than a broad intent.
Memory and vault surfaces are treated as governed state rather than implicit permission.
MCP/tool, browser, account and entitlement boundaries remain explicit controls.
The target loop inspects, diagnoses, authorizes, repairs, verifies and records within bounded authority.
Architecture
The diagram below represents the current verified architecture boundary; planned or environment-dependent components are described in the engineering notes rather than silently promoted.
TOCTOU protection binds approval to the exact action digest.
Engineering deep dive
Technology names matter less than the engineering contracts they enforce.
TOCTOU protection binds approval to the exact action digest.
Missing trust material is treated as indeterminate rather than approved.
High-impact and destructive actions remain explicit authority boundaries.
The broader autonomous repair loop is still under active development.
Project status
Private, active development. Completion Receipt foundation is verified; the full autonomous repair loop remains a current engineering target.
Private implementation — selected architecture can be discussed without exposing repository contents.