Governing AI discipline
Basic rules for foreground AI planning, executor AI work, repo inspection, scope control, and human authority.
Doctor Bones / GitHub-native project discipline
A starting discipline for AI-assisted work inside a repository.
Doctor Bones helps you keep project memory inside the repo instead of trapped in chat. It gives your human/AI team a shared operating discipline: workorders, playbooks, examples, checks, handoff rules, and release-readiness habits.
The lane
Doctor Bones is not trying to replace Cursor, Codex, Claude Code, Copilot, or GitHub bots. Those tools are the execution layer. Doctor Bones is the repo-native governance, instruction, and evaluation layer that tells those hands what a valid job looks like.
The open work is to turn the discipline into more executable repo artifacts: schemas, rubrics, examples, checks, and integration hooks. The rough list lives in TODO.md.
What you get at the beginning
Example prompt workflows
Day-in-the-life examples that teach future AI sessions when to read guidance, when to create workorders, and when to stop.
Workorders and checks
A plain contract format for bounded file-changing work, plus checks that help keep repo guidance and examples coherent.
What the repo actually uses
The starting material is ordinary GitHub-native project material. There is no special platform to install before the repo can begin teaching the AI how to work.
Human-facing orientation
The plain starting explanation: what this repo is, how to begin, and where a project-specific copy should put its own memory.
AI operating rules
Standing instructions for AI assistants: inspect repo state, respect the source/project boundary, and choose advice, prompt, edit, or workorder deliberately.
Prompt workflow examples
Concrete day-in-the-life patterns that show how a foreground AI should behave in recurring project situations.
Bounded executor tasks
Workorders describe file-changing work with purpose, scope, constraints, required checks, fallback behavior, and completion notes.
Contract shape
The workorder contract gives future AI sessions a concrete structure to validate against instead of relying on vibes.
Repo checks
Check scripts help catch drift between guidance, examples, schemas, and the discipline the repo claims to teach.
How it starts
You can begin by pointing a foreground AI at the GitHub repository. The AI reads the repo guidance first, then helps decide whether the next move is advice, a prompt, a small doc edit, or a workorder for an executor.
1
Use GitHub as the shared memory
The repository carries the current project instructions. Chat memory is useful, but repo state wins.
2
Ask the foreground AI to read first
The AI should inspect README, AGENTS, examples, readme_pmp, and relevant folder guidance before giving architecture advice or suggesting changes.
3
Use workorders for file-changing work
When the task needs an executor, the workorder names the target repo, scope, constraints, checks, fallback behavior, and expected completion note.
Example startup prompt
This is the basic shape. Replace the repository URL with the project repository created from the Doctor Bones template.
You are the foreground AI for <your project repository URL>.
Current repo state beats chat memory. Inspect the current project repository before giving
architecture advice, writing workorders, or suggesting repo changes.
Read README.md, examples/README.md, readme_pmp.md, AGENTS.md, and the relevant folder
guidance from the project repository first. Then identify current state, target, constraints,
foreground/executor decision, and the smallest useful next move.Doctor Bones carries PFEM vocabulary
A lens the repo architecture already knows
Doctor Bones has an inherent vocabulary regarding Polycentric Federated Evidence Mesh, or PFEM. This is a lens the Doctor Bones repo architecture itself knows, and it can help you make sure your agent projects are disciplined, evidence-aware, and less likely to collapse source, action, interpretation, and proof into one messy pile.
You probably need its insights
PFEM is a reference architecture with very broad applicability. You probably need it and do not know it yet, or at least you need its insights: clean evidence boundaries, explicit authority, traceable findings, careful rollups, and a habit of proving what the system claims to know.
Small prompts can do constrained work
When a repository has enough discipline, a short prompt can carry more meaning than it looks like. The AI is not guessing from a blank page. It can read the repo rules, follow the examples, respect the workorder boundary, and apply referenced architecture lenses such as PFEM and PFCOMM.
The demo below used fuller PFEM and PFCOMM references, not only the lightweight snapshots embedded in Doctor Bones.
Make me a WebGL 3D demo of what PFEM and PFCOMM would do in the context of a resilient mesh
of flying things that need to be coordinated with a mission objective.The point is not that the prompt is magic. The point is that the repository narrows the lane before the executor starts making files: evidence stays separate from coordination, authority is explicit, outputs are bounded, and checks or completion notes can be named.
Same architecture, different mission surface
The real PFEM and PFCOMM architectures can also shape a critical-infrastructure alert handling system and a ham/RACES field interface for watching the skies. Same generic boundaries; different operator surfaces.
PFEM examples for fundamental constants as information objects
PFEM can also be applied outside ordinary software operations. These WebGL examples treat the fundamental constants of physics as information objects: raw published digits become bounded evidence, bit encodings become normalized observations, running Z0 processes become generated findings, and speculative interpretations stay separate from proof.
When rigorously analyzed this way, the fundamental constants of physics may describe themselves differently than physicists do. For example, the characteristic impedance of vacuum appears in these toy models not as a passive property of spatial space, but as a runnable object whose generated behavior invites color-charge, strong-force, and atom-like interpretations.
The point is not to claim a completed physics result. The point is to show PFEM discipline on a stranger mission surface: keep source, transform, generated behavior, interpretation, and falsification boundaries visible while asking whether the characteristic impedance of vacuum is better modeled as an active information object than as a mere property of empty space.
Two Impedance Nodes In Now
A minimum toy universe where two Z0-running objects exchange delayed messages, and apparent distance emerges from reconciliation cost.
Electron As A Color Null
A sibling model where an electron-like candidate appears as a stable colorless hole carried forward by the impedance bond.
Four Impedance Nodes: Origin Of Geometry
A four-node 3D PTZ model where Z0 impedance structures form a fundamental entanglement basis and electron-null candidates move through the emergent geometry.
Fundamental Pointer Swap
This is the fundamental view, likely prior to the universe's own electro-weak epoch during conventional Big Bang emergence. Swap stabilization and solid-as-steel-looking spatial space come later, but this swap never stops.
Z0 Lorenz Sweep Monitor
This is the same Z0-running claim expressed in a form some reviewers prefer: controls, sweeps, plain-English reports, and measured comparisons against shuffled and true-random bit patterns.
Z0 Quark GeneZip Compression
A recursive remainder workbench showing that real quark grammar appears to permeate the fundamental constants of physics more strongly than equal-or-longer fake quark grammars under the same PFEM-visible controls.
The Lorenz sweep monitor demonstrates what the visual toy models were already saying in a more ordinary falsification dialect. Z0 is treated as a runnable information object, quark-span windows become selectable probes, and the page reports whether the XOR-running pattern is ordinary or unusual compared with controls. It does not replace interpretation; it gives the interpretation a measurement surface.
The GeneZip compression workbench asks a sharper grammar question. Using only its starting quark vocabulary, it repeatedly re-expresses remainder strings and compares the result against fake quark grammars that are never shorter than the real tokens. In this PFEM framing, the claim is inspectable: real quark grammar appears to permeate the fundamental constants of physics, while the negative control keeps that sentence disciplined.
Reference architecture and reference cognition
PFEM can be used as a reference architecture when you are building an evidence-bearing system: it gives you reusable boundaries for raw evidence, normalized observations, findings, packages, reports, rollups, provenance, confidence, and proof.
PFEM can also be used as reference cognition when you are evaluating someone else's system. In that mode, it is a structured way for a human or AI reviewer to ask what the system is treating as evidence, what is only inference, what has authority, what proves closure, and where the architecture has collapsed separate concepts into one blob.
What can Doctor Bones' built-in PFEM-lite do for coding agents and testing repositories?
PFEM-lite gives a coding agent a first-pass evidence-boundary lens for a repository. It helps the agent ask whether source inputs, normalized records, findings, reports, packages, rollups, tool calls, checks, and completion claims are being kept separate.
PFEM principles appear to address significant concerns when creating or evaluating AI agents, MCP code, tool environments, and configuration surfaces. The useful question is not only whether the agent can call a tool, but whether the surrounding repository keeps evidence, authority, action, mutation, verification, and reporting in separate, inspectable lanes.
Review agent changes
Look for places where generated code collapses evidence, interpretation, action, reports, and proof into one blob.
Test repository boundaries
Ask whether tests, fixtures, schemas, CI workflows, or validation scripts prove the important transitions instead of only checking that files exist.
Keep tool authority honest
Distinguish read-only inspection, draft/propose work, mutation, publish/send actions, and human-approved execution.
This is not a full PFEM audit. It is a useful starter discipline for coding agents: inspect the repo, cite what was read, name the boundary risks, and create a workorder when the fix needs real execution.
What exactly are PFEM-lite and PFCOMM-lite?
PFEM-lite and PFCOMM-lite are small embedded reference snapshots inside Doctor Bones. They give the AI enough vocabulary and boundary discipline to do useful first-pass analysis when the full PFEM or PFCOMM repositories are not being inspected.
PFEM-lite
A lightweight evidence-governance lens: raw evidence, normalized observations, findings, alerts, evidence packages, reports, rollups, provenance, confidence, and proof should not be collapsed.
PFCOMM-lite
A lightweight command-and-coordination lens: command intent, authority context, tasking, assignments, resources, status, receipts, messages, decisions, after-action records, and reports should not be collapsed.
They are not replacements for the real PFEM and PFCOMM architectures. They are the repo-smarts Doctor Bones carries by default so an AI can start in the right lane before you decide whether full architecture inspection is needed.
What we did for Kris with PFEM and PFCOMM smarts.
Kris's ShopOS concept is a good example of Doctor Bones as reference cognition. The screenshot already shows machine nodes, operational states, jobs, materials, dust collection, safety status, and shop-control surfaces. PFEM helps separate shop evidence from findings and proof. PFCOMM helps separate operator intent, authority, commands, receipts, status, and after-action accountability.
The point is not to turn one screenshot into fake certainty. The point is to show how a foreground AI can preserve the idea, estimate probability and risk honestly, and create the architecture path a real builder would need before handing bounded work to an executor.
You still have to think
Doctor Bones is not here to do all your thinking for you or to automate your intelligence. As a software architect, systems architect, or cognitive architect, your job is to understand the day-in-the-life examples and then do your own thing hereafter. Why did we show Polycentric Federated Evidence Mesh and Polycentric Federated Command Mesh doing those things? It is because if you think that way, this may be the right place for you.