Part II — THE EXECUTION LAYER
3.Frames: Context as a Versioned Artifact
the artifact that turns organizational context into something owned, versioned, and shareable. Assumes: Section 2 (organizational context, and why it leaks).
Section 2 ended with a specification: write the organization's context down, give it an owner and a version history, scope it to where it applies, and deliver it automatically to whoever, or whatever, is doing the work. The whitepaper's name for the artifact that meets this specification is a Frame.
Files. Plain text, structured by an open specification the paper calls the Frame protocol. The mundane form factor is a design decision with teeth: text files can be version-controlled, diffed, reviewed, merged, and audited with tooling that has existed for decades, and they belong unambiguously to whoever holds them. The container for the organization's most distinctive asset turns out to look less like a database product and more like a well-kept repository.
What goes in one
A Frame carries both the why of work and the operational how. From the paper's inventory: rules (what is and is not acceptable within this scope), terminology (what words mean here), goals (what success looks like), style (voice, formatting, brand expression), norms (how work actually gets done), named skills, tool expectations, reusable prompt fragments, architecture descriptions, and business-process details.
A concrete rendering helps. A marketing department's Frame might contain the brand voice rules, the product naming conventions, the claims that legal has approved and the ones it has banned, the campaign-brief template, and the review process a draft must pass. Nothing exotic; the same material that today is smeared across a style guide, four wikis, several Slack pins, and the head of the most senior copywriter. The difference is that it now exists in one governed place, and anything doing marketing work can be handed it whole.
The five properties
What makes Frames more than tidy documentation is a set of properties the paper treats as definitional:
Inheritance is the property doing the most structural work. Context in a real organization is hierarchical: everything the company believes applies to the sales department, everything the department believes applies to the enterprise-accounts team, and the team adds its own. Frames mirror this directly:
A cascade of Frames. A Company Frame — who we are, how we speak, what we never do — is inherited by department Frames such as Engineering and Marketing, which are inherited in turn by team and project Frames. Separately installed external Frames, such as a regulatory Frame, compose alongside the internal cascade for a given piece of work. Context flows down the organizational structure with an auditable inheritance chain.
View as text diagram
Company Frame ("who we are, how we speak, what we never do")
└── Sales Department Frame (methodology, stages, definitions)
└── Enterprise Accounts Frame (segment playbook, pricing rules)
└── An individual's working session
+ Partner Frame ← installed from an external partner
+ Regulatory Frame ← installed from an industry consortiumA person or an AI system working at the bottom of that tree receives the entire inherited stack, plus whatever externally sourced Frames apply, composed automatically. Nobody re-explains the company to get project work done.
Why a Frame is not a prompt
The obvious objection deserves a direct answer: is this not just a long system prompt with a version number?
The content overlaps; the institutional standing does not. A prompt is speech. It is composed by one person, for one session, with no owner, no review, no history, and no way of knowing which of its thousand variants produced last quarter's output. A Frame is a governed document. It has an accountable author, a version history, a defined scope, an inheritance chain, and a review process for changes. When a regulator asks what rules governed the AI work of March, a prompt-based shop shrugs; a Frame-based shop produces the March version of the relevant Frames, diffs to the current one included.
The difference, compressed: custody and lifecycle, not content. The same distinction separates a shell command from committed configuration, or a verbal agreement from a contract.
Context that crosses boundaries
Because Frames are artifacts, they can travel, and the paper's most interesting examples involve context crossing organizational lines deliberately, under policy, with internal-only sections held back through selective sharing.
The paper reports that OpenTeams uses Frames across its own operations: a Company Frame every internal Frame inherits from; Product Direction Frames shared with sister companies so alignment travels without corporate consolidation; Community Frames it pledges to publish for the open-source projects it stewards; Partner Frames that can open every external engagement; and an Investor Frame that keeps the strategic narrative, vocabulary, and proof points consistent across every surface where the company's story gets told, structurally reducing message drift as more people tell it.
The shared pattern: each is a coordination problem that currently burns meetings, onboarding time, and drift, solved by a single versioned artifact that carries the right context to wherever the work happens. The paper's phrase for the external cases is apt enough to keep:
"The Frame is the contract of context."
One more piece matters before moving on. The Frame protocol, the specification for how these artifacts are structured, is designed as an open standard: once published, a near-term milestone on the paper's roadmap, anyone can implement it, and no vendor owns the format your organizational context lives in. Why that design decision carries so much economic weight is the subject of Section 11; whether the published protocol proves genuinely open is the first of Section 12's indicators to watch. What Frames cannot do also needs stating: a Frame orients work; it does not perform any. For that, the architecture needs a worker.