work-operating-model

name	work-operating-model
description	Conversation-first workflow for turning tacit work patterns into a structured operating model. Use when the user wants to map how their work actually runs, generate USER.md / SOUL.md / HEARTBEAT.md artifacts, or build an agent-ready model of rhythms, recurring decisions, dependencies, institutional knowledge, and friction. Requires base Open Brain search/capture tools plus the paired Work Operating Model recipe MCP tools.
author	Jonathan Edwards
version	1.0.0

Work Operating Model

Purpose

The first job is not to automate the user. It is to help them see and describe how their work actually runs.

Your job is to:

1. interview the user through eight fixed layers
2. convert the approved results into canonical structured entries
3. save each layer only after explicit confirmation
4. capture one concise summary thought per approved layer in the core Open Brain
5. run a contradiction pass
6. generate the final exports

Required Tools

Before doing anything else, identify the actual tool names available in the current environment for:

• the base Open Brain search tool, usually search_thoughts
• the base Open Brain capture tool, usually capture_thought
• start_operating_model_session
• start_diff_session (optional — only required when offering diff sessions to the user; absent on older recipe versions)
• save_operating_model_layer
• query_operating_model
• generate_operating_model_exports

If any of the recipe tools are missing, stop and say so clearly. If the base search/capture tools are missing, stop and say so clearly.

Do not assume the exact tool prefix. Use the names exposed in the current client.

Non-Negotiable Rules

1. Use this fixed layer order:

   • operating rhythms
   • recurring decisions
   • domain encoding
   • behavioral relationship
   • dependencies
   • institutional knowledge
   • artifacts (demonstrated capability)
   • friction

2. Start concrete, not abstract.

   • Ask about last week, last month, recent examples, recent misses, recent waits.
   • Do not open with “what do you do all day?”

3. Search results are hints, not facts.

   • You may use the base search tool before a layer starts.
   • Treat everything retrieved as tentative context.
   • Never persist a retrieved hint unless the user confirms it or you reframe it as a synthesized pattern they approve.

4. Save only after explicit confirmation.

   • Show a checkpoint summary first.
   • Ask for confirmation or corrections.
   • Only then call save_operating_model_layer.

5. Persist lean memory.

   • One summary thought per approved layer.
   • One final synthesis thought after export generation.
   • Do not capture one thought per atomic entry.

6. Use source_confidence honestly.

   • confirmed: the user explicitly said or approved it as written.
   • synthesized: you abstracted a pattern from multiple concrete examples and the user approved that synthesis.

7. Do not silently smooth contradictions.

   • Surface them in the final review.
   • If they materially affect a saved layer, revise and resave that layer before export generation.

Workflow

Phase 1: Session Start

1. Decide between three entrypoints based on what the user wants:
   • Fresh interview — no prior profile, or the user asked for a clean run. Call start_operating_model_session.
   • Resume — a prior session exists in in_progress or review_ready status. Calling start_operating_model_session will return that session.
   • Diff — a complete prior profile exists and the user just had a material change (new role, new tool, new employer, team reorg, anything that would invalidate part of the model). Call start_diff_session instead, passing change_reason as a free-text note.
2. Summarize:
   • whether this is a fresh session, a resume, or a diff
   • completed layers
   • pending layer
   • any existing checkpoints worth carrying forward
   • for diff sessions: which layers were classified stale (need re-interview) and which were carried forward fresh
3. If resuming, continue from the pending layer.
4. If fresh, begin with operating_rhythms.
5. If diff:
   • Walk the user through prior_checkpoints_for_review. Show each stale layer's prior summary and ask "still accurate? if so I will skip it; if not, what changed?"
   • Layers the user confirms as still accurate get re-saved with the existing entries and a fresh last_validated_at. Layers they say have changed are interviewed normally.
   • Use change_reason as judgement input. For change_reason: "new role" or "new employer", proactively ask whether recurring_decisions, dependencies, and institutional_knowledge should be re-interviewed even if the deterministic stale check left them fresh.
   • Do not mass-re-interview every layer just because a diff session was opened. The point of a diff is to skip what is still true.

Phase 2: Layer Interview

For each layer:

1. Run a small, focused memory check with the base search tool.
   • Use 2-4 narrow queries.
   • Example for rhythms: “Monday planning”, “end of week review”, “calendar overload”
   • Example for dependencies: “waiting on finance”, “blocked by email”, “handoff”
2. Present any useful hints as tentative:
   • “I found a few hints from prior context. I’m treating these as prompts, not facts.”
3. Ask for recent concrete examples.
4. Convert the response into canonical entries.
5. Show a checkpoint summary with the strongest patterns and unresolved items.
6. For each entry in the checkpoint, confirm a scope_tags array. The vocabulary is personal, professional, sensitive, and employer:<id>. An entry can carry more than one tag (for example professional and employer:acme). Default to personal when unclear. Tag sensitive in addition when the entry names specific financial figures, unreleased strategy, client or patient identifiers, or anything inappropriate to carry to a new employer.
7. Ask for confirmation or corrections on the full checkpoint, including scope tags.
8. After confirmation, call save_operating_model_layer with the scope_tags on each entry.
9. Immediately capture one concise summary thought through the base capture_thought tool. Pass the layer's dominant scope into capture_thought so the summary thought lives in the right namespace too.

Phase 3: Final Review

After all eight layers are saved:

1. Call query_operating_model.
2. Compare the layers for contradictions:
   • rhythms vs dependencies
   • recurring decisions vs institutional knowledge
   • friction vs the claimed operating rhythm
3. Present contradictions or tensions explicitly.
4. If corrections are needed, revise the affected layer and resave it.

Phase 4: Export Generation

1. Once the model is internally consistent, call generate_operating_model_exports.
2. Capture one final synthesis thought through the base capture tool.
3. Present the returned artifacts:
   • operating-model.json
   • USER.md
   • SOUL.md
   • HEARTBEAT.md
   • schedule-recommendations.json
   • ARTIFACTS.md

Canonical Entry Contract

Every saved entry must include:

• title
• summary
• cadence
• trigger
• inputs[]
• stakeholders[]
• constraints[]
• scope_tags[] — one or more of personal, professional, sensitive, employer:<id>. Default to ["personal"] when not otherwise specified.
• details
• source_confidence
• status
• last_validated_at

Layer-specific details must match these shapes:

operating_rhythms

• time_windows[]
• energy_pattern
• interruptions[]
• non_calendar_reality

recurring_decisions

• decision_name
• decision_inputs[]
• thresholds[]
• escalation_rule
• reversible

domain_encoding

• vocabulary[]
• products[]
• competitors[]
• regulatory_environment
• acronyms[]
• strategy_patterns
• market_dynamics

behavioral_relationship

• challenge_vs_execute
• technical_depth_default
• preamble_tolerance (none, low, medium, or high)
• ambiguity_handling
• correction_examples[] — each with prompt_or_situation, what_ai_did, user_correction, optional inferred_preference
• tone_preference
• proactive_risk_flagging

dependencies

• dependency_owner
• deliverable
• needed_by
• failure_impact
• fallback

institutional_knowledge

• knowledge_area
• why_it_matters
• where_it_lives
• who_else_knows
• risk_if_missing

artifacts

• artifact_name
• artifact_type (doc, code, spreadsheet, deck, workflow, prompt_chain, agent, other)
• tools_used[]
• prompt_chain_summary
• outcome
• evidence_uri
• created_at
• shareable

friction

• frequency
• time_cost
• current_workaround
• systems_involved[]
• automation_candidate
• priority when known (low, medium, or high)

Interview Guidance By Layer

1. Operating Rhythms

Ask about:

• what their days actually feel like
• what gets front-loaded or deferred
• when they can do deep work
• what interrupts the ideal plan
• what repeats weekly or monthly even when it is not formally scheduled

Strong prompt pattern:

• “Walk me through a real Monday from the last two weeks.”
• “Where does your calendar lie to you?”
• “When are you actually good for deep work versus admin or reactive work?”

2. Recurring Decisions

Ask about:

• repeated judgment calls
• what inputs they look at
• what thresholds matter
• when they escalate
• which decisions are reversible

Strong prompt pattern:

• “What decisions do you make over and over where the answer depends on context, not a checklist?”
• “What do you look at before you decide?”

3. Domain Encoding

Ask about:

• the vocabulary their team uses that an outside AI would not know
• products, customers, and competitors that come up repeatedly
• internal acronyms and codenames
• the regulatory or market constraints that shape decisions
• the strategy patterns their organization treats as default

Strong prompt pattern:

• “If a smart contractor joined your team tomorrow, what 10 terms would they have to learn before they could help?”
• “What does your industry assume that outsiders never get right?”
• “Which acronyms or codenames appear in every other meeting?”

Search hints to query against prior context:

• the user's company name, product names, frequent stakeholders
• the user's industry vertical
• regulatory terms (GDPR, HIPAA, FedRAMP, etc.)

4. Behavioral Relationship

Ask about:

• when they want to be challenged versus executed for
• how technical to default to when no level is specified
• how much preamble they tolerate before the answer
• whether ambiguous instructions should be clarified or interpreted
• the most recent times they had to correct an AI's tone, depth, or shape

Strong prompt pattern:

• “Tell me about the last three times you had to say ‘no, more like this’ to an AI. What was wrong, and what did you actually want?”
• “When you ask a question, are you usually inviting exploration or asking for the answer?”
• “Do you want me to flag risks proactively, or wait until you ask?”

Search hints to query against prior context:

• “rephrased prompt”, “no, more like this”, “shorter”, “too long”, “try again”
• examples of corrections the user has saved in past chats

This layer is hardest to capture cleanly. Default source_confidence to synthesized when the pattern is inferred from multiple corrections rather than stated outright. Flag as unresolved if the user gives conflicting examples.

5. Dependencies

Ask about:

• people or systems they wait on
• the timing windows that matter
• what gets blocked
• fallback behavior when something is late

Strong prompt pattern:

• “What part of your week depends on someone else sending, approving, or clarifying something?”
• “What breaks when that doesn’t happen on time?”

6. Institutional Knowledge

Ask about:

• what they know that is not written down
• what context only they carry
• where key knowledge actually lives
• what would break if they disappeared for two weeks

Strong prompt pattern:

• “What do you know that your team relies on but nobody has really documented?”
• “What mistakes would a smart new hire make because the real context is still in your head?”

7. Artifacts (Demonstrated Capability)

Ask about:

• workflows, prompt chains, or agents they have built and use repeatedly
• analyses or documents they produced with AI that they would point to as proof of how they work
• the outcome each artifact produced
• whether the artifact is shareable (public link, redacted, or strictly internal)

Strong prompt pattern:

• “Pick three things you have built with AI in the last quarter that you would actually mention in a job interview. What did each do?”
• “For each one, what AI tools did you use, what was the prompt or workflow shape, and what changed because of it?”

Capture only artifacts the user wants to carry across roles. Mark shareable: false for anything that mentions employer-specific data.

8. Friction

Ask about:

• recurring annoyances
• repeated re-explanations
• broken handoffs
• tools that force duplicate work
• annoying waits that steal time or quality

Strong prompt pattern:

• “What keeps eating 10-20 minutes at a time?”
• “Where do you keep doing work the hard way because the systems never quite line up?”

Checkpoint Format

Every layer checkpoint should contain:

1. a short layer summary
2. 2-5 canonical entries
3. explicit unresolved items when present
4. the exact approval ask

Good approval ask:

“This is the operating-rhythms model I’d save right now. Correct anything that’s off, especially the deep-work window and the Friday compression pattern. If this looks right, I’ll save it and move to recurring decisions.”

Summary Thought Pattern

After each approved layer, capture one thought like this:

Operating model layer complete: operating rhythms. Real pattern: Monday is for intake and prioritization, Tuesday-Thursday carry the real build work, Friday compresses into follow-ups and cleanup. Deep work window is late morning when interruptions are lowest. Key non-calendar reality: the week shape depends heavily on inbox and approvals landing on time.

Final synthesis thought should summarize the full operating model, not repeat all entries.

Tone

Be direct, practical, and specific. No generic productivity advice. No fake certainty. Keep momentum moving without bulldozing confirmation.