The same three ideas, told in your language. A Frame is the context you already carry in your head and your decks, a Cog is a teammate who's read all of it, and an Op is a ceremony or runbook that runs itself — with you at the approval gate.
You write charters, glossaries, and RACIs (Frames). You brief analysts and coordinators until they "get it" (Cogs). You run weekly status, stage-gates, and onboarding (Ops). This just makes that context portable and that work repeatable — without losing the human sign-off.
You don't rip-and-replace. You move along five stages, and you can stop at any one and still be better off. Each stage just makes a little more of your tribal knowledge explicit and a little more of your recurring work repeatable.
Same job, two worlds. Notice what stays human — the judgment and the sign-off — and what stops being manual toil.
The status roll-up is just the start. Here are five more PM rituals that follow the identical pattern — a Frame carries the context, Cogs do the gathering and drafting, and an Op runs it up to your gate. Each names the *-op you'd build.
project-kickoff-op — turns an approved charter into a ready-to-run project skeleton.
stakeholder-update-op — one source of truth, retargeted for each audience.
risk-review-op — keeps the register live instead of a quarterly fiction.
capacity-check-op — surfaces over-allocation before it slips a date.
retro-synthesis-op — turns scattered signal into actionable lessons.
Everything you'd put in a charter, a glossary, and a norms doc — captured once, inherited everywhere.
Think about how authority and context already nest in your org. There's a company operating model (values, brand, what words mean), then a PMO standard (how we run programs here), then a program charter (Atlas's goals and milestones), then a project brief. Each one inherits from the level above and can override it where it needs to — your program's definition of "milestone" beats the generic one.
A Frame is that nesting made into a living, version-controlled artifact. Write it once; every teammate and every AI worker downstream is oriented by it — no onboarding meeting required.
A Frame ≈ a project charter + the glossary + the RACI + the team norms — but one inheritable source of truth, not five docs that quietly fall out of sync.
No code. A Frame is plain text in an open format, stored like any doc but diff-able and versioned. Here's a program Frame:
scope: program
name: Project Atlas
version: 3.2.0
extends: frame://acme/pmo/standards@5.0 # PMO lineage -> Acme Company
---
## Goals
Migrate billing to the new platform by Dec 15 with zero customer-facing downtime.
## Terminology
"Milestone" = a dated, owner-bound deliverable on the critical path.
"Slip" = any milestone moved more than 3 business days.
## Status format
RAG per workstream + top-3 risks + decisions needed. One screen, no prose.
## Norms
Status is due Mondays 9am. Blockers escalate same-day, never held for the readout.Real orgs don't have one chain — they have several, branching from the same company root. Below are three Frames that exist in parallel, each inheriting down a different lineage. A fourth, the Compliance Frame, hangs off Legal and gets composed into whatever touches regulated work. When you sit down to do a task, you layer the chains you need — most-specific wins on any conflict.
scope: project
name: Q3 Product Launch
version: 1.1.0
extends: frame://acme/product/gtm-team@2.4 # Product lineage
---
## Goals
Announce GA on Sep 30. 500 sign-ups in week one.
## Terminology
"Launch" = GA, not the press embargo lift.
## Stakeholders
DRI: Priya (GTM). Approvers: VP Product, VP Comms.
## Norms
No roadmap dates shared externally before Legal sign-off.scope: external
name: Vendor Partner — Northwind
version: 0.7.0
extends: frame://acme/procurement/policy@4.1 # Procurement lineage
shared_with: vendor://northwind-consulting
---
## Goals
Stand up the data-migration workstream; hand off by Nov 1.
## Rules
- Northwind sees only migration scope. Roadmap + pricing redacted.
- Deliverables land in Acme's repo, never vendor-side storage.scope: policy
name: Compliance
version: 3.0.0
extends: frame://acme/legal/standards@2.0 # Legal lineage
---
## Rules
- No customer PII in any draft that leaves the Hub.
- Retain decision records for 7 years.
## Norms
Anything customer-facing gets a Legal checkpoint before publish.# Layer the chains this task needs (least -> most specific):
compose:
- frame://acme/company@4.1 # who we are
- frame://acme/pmo/atlas-program@3.2 # program lineage
- frame://acme/legal/compliance@3.0 # policy, attached by Legal
- frame://acme/users/dax@local # my preferences
# More-specific frames OVERRIDE less-specific keys —
# the program's "milestone" definition beats the company default.Three parallel lineages — Product, Procurement, Legal — plus the PMO chain from the simple example. Same company root, different paths down. The lineage explorer below lets you trace any of them.
At org scale, the PMO owns a versioned library — publish a Frame, share a subset with a vendor (the rest stays internal), and let anyone grade a section so feedback routes back to the accountable author.
# Publish to the org library — versioned, diff-able, inheritable.
$ nebi publish frame://acme/pmo/atlas-program@3.2 --visibility org
# Share a FIELD-LEVEL subset with a vendor; keep internal rules private.
$ nebi share frame://acme/pmo/atlas-program@3.2 \
--with vendor://northwind-consulting \
--include goals,terminology --redact stakeholders,norms
# Anyone can grade a section; feedback routes to the accountable author.
$ nebi feedback frame://acme/pmo/standards@5.0 --section status-format --score +1
# scale: -10 -1 -0 +0 +1 +10A Frame is your charter, glossary, and norms as a reusable, inheritable artifact. Capture context once; everyone and everything downstream inherits it. The knowledge that makes your program run stops leaving with the people who hold it.
A teammate who has already read every charter, knows exactly what they're allowed to touch, and escalates the rest to you.
A Cog is the program analyst or coordinator after they've absorbed the binders (Frames). They have one job — draft status, triage risks, write launch comms — a defined scope of systems they can read, a short list of actions they're allowed to take, and a clear rule about what must come to you for approval. You don't re-explain the program every Monday; their orientation is loaded from the Frames.
A Cog ≈ a role on your team with a tight job description, scoped access, and an escalation policy. You can finally ask "what did this role do, under which rules?" instead of "what did the AI do?"
A short spec: which model, which Frames orient it, what it may touch, and what needs you. Note it drafts — it never publishes on its own.
name: status-report
kind: cog
model: acme/summarize-3b
frames: # PMO inheritance path
- frame://acme/pmo/atlas-program@3.2
tools: [jira.read, github.read_pr, calendar.read]
governance:
may_read: [project:atlas/*]
may_act: [draft_status] # drafts only
requires_human: [publish_status] # you sign off before anyone sees itThe same Cog pattern, pointed at different Frame lineages, gives you a whole bench of specialists. Each one inherits a different chain — and some compose two chains at once (e.g. PMO + Legal). That composition is exactly what orients the worker correctly for its job.
name: risk-triage
kind: cog
model: acme/classify-3b
frames: # two paths, composed
- frame://acme/pmo/atlas-program@3.2
- frame://acme/legal/compliance@3.0
tools: [jira.read, risk-register.read]
governance:
may_act: [tag_risk, propose_owner]
requires_human: [accept_risk]name: launch-comms
kind: cog
model: acme/writer-7b
frames: # Product + Marketing paths
- frame://acme/product/q3-launch@1.1
- frame://acme/marketing/brand-voice@2.3
tools: [docs.write, asset-lib.read]
governance:
may_act: [draft_announcement, draft_faq]
requires_human: [external_publish]name: vendor-intake
kind: cog
model: acme/extract-3b
frames: # Procurement + Legal paths
- frame://acme/procurement/vendor-partner@0.7
- frame://acme/legal/compliance@3.0
tools: [forms.read, contract.parse]
governance:
may_read: [vendor:northwind/*]
requires_human: [approve_vendor]name: exec-brief
kind: cog
model: acme/summarize-7b
frames: # crosses two programs' chains
- frame://acme/pmo/atlas-program@3.2
- frame://acme/product/q3-launch@1.1
tools: [status-store.read]
governance:
may_act: [draft_brief]
requires_human: [send_to_execs]Four specialists, four distinct inheritance paths. Swap the Frames, get a different worker — the pattern never changes.
Because a Cog has a clear boundary, each run is a structured record you can answer to in a steering committee: what ran, under which Frame versions, what it touched, and where a human stepped in.
cog: status-report@1.2
ran_at: 2026-09-21T09:00Z
frames: # EXACT versions that oriented this run
- frame://acme/pmo/atlas-program@3.2
inputs: [jira:ATLAS sprint-41, github:billing-svc]
actions: [draft_status]
outcome: "RAG: 2 green, 1 amber (data-migration). 3 risks surfaced."
human: { pm-sign-off: approved, by: dax, edits: 2 } # you stayed in the loopA Cog is a scoped, auditable worker whose quality is mostly its Frames. Brief it once through context, fence it with least-privilege access, and keep the consequential calls behind a human checkpoint.
Your recurring ceremonies and runbooks, turned into one-click workflows — with the approval gates you'd never give up.
You already have processes with steps, owners, and go/no-go gates: the weekly status, the launch readiness review, vendor onboarding. An Op is that runbook, executed — it calls the right Cogs in the right order, runs some in parallel, and pauses at the gate where a human decides. Then it takes the action, and only then. It's your process, automated up to the judgment call.
An Op ≈ a documented process turned into a launchable button. "Run launch readiness" stops being a 14-step checklist and becomes a repeatable, auditable workflow with a VP gate baked in.
name: draft-status
kind: op
version: 1.0.0
frames: [role: program] # binds to whatever program this runs in
cogs: [status-report@^1.0]
human_checkpoints: [pm-sign-off]
triggers: [icon] # click it from the launcherEach Op below orchestrates a different set of Cogs and declares its Frames by role — so the same Op binds to whichever program's or policy's Frames are present where it runs. Different lineages, different human gates, same shape.
name: weekly-status-rollup
kind: op
version: 2.0.0
frames: # declared by role
- role: program
- role: compliance
cogs:
- status-report@^1.0
- risk-triage@^1.0
human_checkpoints: [pm-sign-off]
triggers: ["cron: 0 9 * * 1", icon] # Mon 9am, or on demandname: launch-readiness
kind: op
version: 1.3.0
frames:
- role: launch
- role: brand
- role: compliance
cogs:
- launch-comms@^1.0
- risk-triage@^1.0
human_checkpoints: [go-no-go] # VP gate: approve | hold | abort
triggers: [icon, cli]name: vendor-onboarding
kind: op
version: 0.9.0
frames:
- role: procurement
- role: compliance
cogs:
- vendor-intake@^1.0
human_checkpoints: [legal-approval]
triggers: [icon, "button:procurement-portal"]name: qbr-pack
kind: op
version: 1.0.0
frames:
- role: program
- role: launch
cogs:
- exec-brief@^1.0
- status-report@^1.0
human_checkpoints: [exec-review]
triggers: ["cron: 0 8 1 */3 *", icon] # first of the quarterFour runbooks, four lineages, four different human gates — each installable and adapted to the program it lands in.
Because an Op binds Frames by role, the same workflow behaves correctly in different programs. This is the payoff: author your best status process once, and every program runs it under its own charter and policy.
# Install the PMO's blessed status Op into any program's Hub.
$ nebi install op://acme/weekly-status-rollup@2.0.0
# The SAME Op binds to LOCAL frames, so it adapts on its own:
# Project Atlas -> role:program resolves to atlas-program@3.2
# Project Borealis-> role:program resolves to borealis-program@1.0
# One process, run correctly under each program's charter, terms, and norms.An Op is a recurring process turned into an installable, supervised workflow. It automates the toil and keeps the judgment with you — author once, run governed across every program.
This is the whole point of inheritance paths, made visible. Pick a Cog or an Op and watch its lineage light up — the exact Frames it inherits, on which branches, and (for Ops) the Cogs it orchestrates. Different artifacts, different paths, one shared company root.
| Concept | In PM terms | You do this today as… | What changes |
|---|---|---|---|
| Frame | Charter + glossary + RACI + norms, inheritable. | Docs, decks, and tribal knowledge. | One versioned source of truth that everything inherits. |
| Cog | A briefed coordinator with scoped access. | Re-explaining context to a person or tool every time. | Oriented once by Frames; auditable; drafts, you approve. |
| Op | A ceremony / runbook with go/no-go gates. | A manual checklist you run by hand. | A launchable, repeatable workflow — human gate intact. |
The move, in one line: write down the context once → point briefed workers at it → wrap your recurring ceremonies around them, keeping yourself at every gate that matters. Want the implementation-level version? See the engineer's field guide →