Runtime Protocols and Record Governance

Purpose

This note distinguishes runtime interoperability protocols from record governance. Protocols define how systems exchange context, invoke tools, or coordinate execution. ARCS governs the records created when those actions occur, including retention, custody, preservation, publication, and verification.

Runtime protocols answer different questions

A runtime protocol may define how an agent invokes a tool, how credentials are presented, or how context moves between services. Those are execution questions. They do not by themselves determine whether interaction records are retained, which entities hold them, whether they enter logs or backups, or whether they are preserved under legal hold.

ARCS addresses the record consequence

ARCS applies when protocol-conformant activity produces records. A single successful tool call can create records at multiple surfaces: the operator application, the protocol server, the upstream vendor, downstream service providers, monitoring systems, and backups. Protocol conformance does not answer how long those records persist or who can produce them. ARCS does.

Why the distinction matters

Treating protocol adoption as though it resolves record governance creates a false sense of coverage. An operator can use a well-designed protocol and still have undocumented custody surfaces, undeclared vendor retention, or no preservation procedure. Conversely, an operator can govern records rigorously even when the runtime protocol layer is comparatively simple.

Practical reading

Protocols govern how systems operate. ARCS governs what happens to the records produced when they operate. The two are complementary, but they are not substitutes for one another.