Your context, guiding AI.
A Frame is versioned, shareable context. It encapsulates normative knowledge that aligns AI with how you work. Frames take minutes to create and give lasting value.
Frames guide the work. Write one, and it keeps guiding it.
The models are capable. What is missing is a portable container for the rules, terminology, goals, and norms that turn generic AI into your organization’s work, so the context stays with the organization that produced it.
No container for organizational rules, terminology, and norms. Every session re-sets the stage from scratch.
The same question gets a different answer depending on who asked, in which chat, on which day.
The context that produced a good result stays in one person's prompt history. It cannot be reviewed, reused, or handed on.
When guidance lives in prompts, nobody can say afterwards which rules shaped a decision, or who owned them.
“In consuming intelligence, you are creating intelligence. And what you create should belong to you.”
A Frame is that container: written once, versioned, owned, and activated where the work happens.
01
01
What people always have to be told before they can start.
02
A Markdown file containing norms, definitions, and other context. One page is plent
03
Frames in your agent or toggle it on in Collab. From then on it shapes every answer.
04
Managed context to stay aligned. In Collab the owner, visibility, and history travel with it.
05
Maintain and improve your Frames and AI becomes an effective member of your work group.
WHY DO IT?
Open a chat and the stage is already set. The first useful answer arrives first.
Written once, versioned, and owned. It appreciates with every revision instead of evaporating.
The same terminology and rules for everyone, so quality holds as the team and the work grow.
Collab shows exactly which Frames shaped an answer, so you can trust it and improve it.
02
Skill
Frame
How do I do this?
How it activates
Several can be layered together
Deliberately, with a review and deliberation
vs. a system prompt
A prompt lasts a session and is unowned. Nobody can review or version it.
vs. a wiki page
A wiki page holds the same knowledge, but someone has to find it and read it. A Frame you just switch on.
03
How we sound, and the words we never use.
The way this team does the work, in order.
Goals, terminology, and constraints for one effort.
What an outside collaborator needs to know, and no more.
The rules that are not negotiable, stated as rules.
Scope, widest to narrowest
Company
Vocabulary · values · brand voice · norms
Team
Style · conventions · audience
Project
Goals · terminology · constraints
Personal
Your own working preferences
Where to start
Start where the pain is sharpest and the review loop is shortest, usually team or project.
Don’t design the whole hierarchy before anyone has used one Frame.
04
Four fields are required. The rest matter once the Frame is shared and revised by other people.
Terminology, goals, rules, style, norms. No fixed taxonomy required. Use the headings your team already thinks in.
Write rules as decidable statements
Keep it short
05-07
The models are capable. What is missing is a portable container for the rules, terminology, goals, and norms that turn generic AI into your organization’s work, so the context stays with the organization that produced it.
Consolidate the context and rules.
Connect your AI to Drive, Slack, Gmail, …, and have it create a first draft.
Point it at existing material and ask for a Frame draft, not a summary.
After a work session, ask what you had to tell it that a Frame should have carried.
Hand it the draft and the spec; ask what is bloated or unenforceable.
Put the draft in front of the people who know. Their corrections are the feedback the agent cannot give you.
Agents draft. You edit. Nothing about that is optional.
Agents are verbose. Expect to cut the draft by half.
Every rule must be decidable. Strike the aspirational lines.
Ownership cannot be delegated. The maintainer is a person who read and is accountable for every line.
Agents copy what they read. If a password or API key was in the source material, delete it from the draft.
Point the agent at this page, where Frame Spec v0.2 is reproduced in full, and ask it to conform to the spec rather than to your description of it.
Create, activate, and share in one place.
Permissions, ownership, and history come with it. You don’t add them later.
Name, description, visibility, owner. Four fields and you have a Frame.
02 · Organize
Bundle related Frames so the right set comes in together.
03 · Activate
Turn one on in chat, or several, and see what's active while you work.
04 · Share
Set who can read, who can edit, and who answers for it.
05 · Review
Every edit is a version. You can see what changed and who changed it.
Rules · norms · language
Layered over Company
Expires 30 Sep
Read-only · external access
Collab shows which Frames are active while you work with your agent.
Any text editor will do
A file is enough.
Write it in whatever you already use. This is the path when the Frame is drafted outside Collab or kept alongside other files that are versioned together.
frames/api-conventions.md
—
type: frame [0.2]
name: API Conventions
description: How we name and version endpoints.
visibility: internal
maintainer: sam.r
—
## Rules
– Paths are plural nouns: /invoices, not /invoice.
– Every breaking change ships behind a version prefix.
– Errors return a machine code and a human message.
Checklist
Four required fields present
Every rule decidable
A named maintainer
No credentials, no personal data
Reads in under two minutes
Bring the file in and Collab adds what a shared Frame needs on arrival: visibility, ACLs, an owner, and version history.
One warning
Decide where the source of truth lives. Editing in both places and re-importing overwrites.
Frames need no infrastructure to share. Email, chat, a shared folder, or a repository all work.
08
Same prompt. Different answer.
One Frame makes a big difference.
“Compile my to-do list.”
Same account, same day, same model. The only difference is whether the Client Delivery Frame was active. →
Without the Frame
You
Compile my to-do list.
8 items found in your inbox, slack, and calendar. Ordered by severity.
Priya’s email asks when the migration window can move. She assumed the reader is aware of project timelines. That connection is written in the project plan, which the agent never thought to open, so the email scores Low and lands at the bottom of the list.
With the Frame
You
Compile my to-do list.
Project plan reviewed. Client commitments first, per Client Delivery.
Unblock Northwind’s data migration before Thursday’s cutover.
Prep for the Northwind renewal call on Friday
Send Aster the revised delivery date you promised in writing
Return the security questionnaire to IT
Approve the Q3 headcount plan
The top item is the same email that ranked last without the Frame. The project plan says the migration window gates Thursday’s cutover, and that date was confirmed to Northwind in writing. Read together, a scheduling question is a blocked deliverable.
The email was in both lists. Only the second one knew what it meant.
Priya wrote as if the reader shared her context, the way colleagues do. One rule told the agent where that context is written down; the other told it what to do once it had it. Neither is clever. Together they caught the one item that could have cost a client.
09
01
In real work.
02
Send changes to the owner, not to a copy.
03
The maintainer is accountable for changes.
04
Recorded in the history, visible to everyone.
ANTI-PATTERNS
Everything anyone ever knew, in one Frame nobody reads.
Rules describing who you'd like to be, not what you do.
Nobody owns it, so nobody fixes it when it goes stale.
Task instructions dressed up as standing context.
Everything above is a way of working. This is the contract. Point an agent at this page and it knows how to read, write and use frames.
This must be:
Yaml
type: frame
or, to specify which version of the Frame Spec the Frame conforms to:
Yaml
type: frame [0.2]
This is the minimal explicit hook that tells an AI system or surrounding implementation that the file is intended to be handled as a Frame rather than as generic Markdown. The bracketed spec version is optional but recommended.
One or two sentences describing what the Frame is for and when it should be used.
Suggested values:
Yaml
version: 0.1.0
This tracks the Frame’s own revision history, not the spec version. Authors should update this when the content of the Frame changes.
One or more parent Frames that this Frame extends. May be a single value or a list.
Yaml
inherits: company-core
Yaml
inherits:
– company-core
– department-engineering
Values should be references that an implementation can resolve: typically a file path, a Frame name, or a URI. The spec does not require a specific resolution mechanism.
After the frontmatter, the rest of the file is normal Markdown. The body should contain the context the Frame is meant to carry. Typical content may include:
Frames are intended to be loaded as system context for AI assistants, where tokens are at a premium. Authors should keep body content concise: prefer short bullets over long prose, omit boilerplate, and include only the guidance that would actually change how work is done. A Frame that is too long to read quickly is too long to be useful.
1.
Inheritance must be explicit.
A Frame only inherits what it declares.
2.
A child Frame extends its parents.
All parent guidance applies unless the child overrides it.
3.
The child takes precedence.
Where parent and child guidance conflict, the child wins.
4.
Parents are read in order.
When multiple parents are listed, earlier entries have lower precedence than later entries. The child always has highest precedence.
5.
Inheritance is not transitive by default.
If A inherits B and B inherits C, an implementation may resolve the full chain, but is not required to.
Because transitive resolution is optional, the same Frame may behave differently across tools. Implementations should disclose whether they resolve inheritance chains transitively, and authors should not rely on transitive resolution unless a specific tool guarantees it.
1.
Resolve and load the parent Frame(s).
2.
Present the combined guidance to the AI assistant, with the child’s content taking precedence on any point of conflict.
The simplest valid implementation is concatenation: parent content first, then child content, with a note that later content overrides earlier content.
Inheritance typically flows from broader to narrower scope: company → department → team → project. This is a convention, not a requirement. A Frame may inherit from any other Frame regardless of scope.
MD
—
type: frame [0.2]
name: Editorial Style Guide
description: Shared guidance for clear, consistent external writing.
visibility: shared
—
# Editorial Style Guide
## Goals
– Be clear, direct, and credible.
– Avoid hype and overclaiming.
## Terminology
– Prefer “Frame” over “alignment file”.
## Style
– Use calm, explanatory language.
– Make important assumptions explicit.
MD
—
type: frame [0.2]
name: Engineering Documentation Style
description: Writing guidance for engineering documentation that extends a broader editorial style guide.
visibility: internal
version: 0.1.0
scope: department
maintainer: engineering enablement
inherits: editorial-style-guide
—
# Engineering Documentation Style
## Style
– Use precise technical language when writing for engineers.
– Keep the calm, direct tone from the broader editorial guidance.
– Code examples are preferred over abstract descriptions.
In the example above, the engineering documentation Frame inherits the editorial style guide Frame. All parent guidance applies unless the child Frame overrides it. The child Frame narrows broad editorial guidance into conventions for engineering documentation.
Those may become part of later versions, but they should not block immediate use.
Because a Frame is loaded as system context, it can influence how an AI assistant behaves. Provenance and source verification are future-facing and are not defined in v0.2. Until they are, implementations and users should only load Frames from trusted sources and should not treat a Frame’s contents as verified.
1.
2.
3.
4.
Apply that guidance when the Frame is made active by a user or system.
5.
We use cookies to improve your experience on this website. You may choose which types of cookies to allow and change your preferences at any time. Disabling cookies may impact your experience on this website. You can learn more by viewing our Cookie Policy.