Purpose: This guide is a practical filter for identifying, classifying, and validating governing principles from an organisation's materials. It is designed to be used as a lens — either by an AI system or a practitioner — to bring principle-level thinking into alignment with P3 theory. It does not require any existing P3 infrastructure. It is a starting point, not an endpoint.

Who this is for: Organisations at early maturity who need to separate what they must do from what they choose to do from what they usually do — and who want to ground that separation in a coherent framework before building governance structures on top of it.

A principle is a governing constraint — a statement about what must be true in your work, regardless of how the work is done. It bounds the space of valid solutions without prescribing any specific solution.

This is different from a guideline, a preference, or a procedure. A guideline suggests a direction. A preference expresses a value. A procedure specifies steps. A principle defines the boundary of what is permissible.

The clearest test: if you removed this commitment, would your solution become invalid, risky, or dishonest? If yes, you are looking at a principle. If removing it would merely make your solution less efficient or less elegant, you are looking at a preference.

Not all principles are the same, and treating them identically is one of the most common sources of governance dysfunction. Principles differ in where they come from and what happens when you violate them.

Absolute Principles are discovered, not decided. They reflect physical, mathematical, or logical reality. You cannot vote to change them. If you violate one, the system fails — not because someone enforces a rule, but because reality enforces it. Example: A safety-critical system cannot be tested only by the team that built it. The cognitive bias that creates errors also creates blindness to those errors. This is physics, not policy.

Regulatory Principles are imposed by external authorities — legal requirements, safety standards, professional codes, contractual obligations. They are human constructions, but within your jurisdiction they are practically inescapable. Violating them has consequences: fines, sanctions, legal liability, loss of operating permission. Example: A system that processes personal data must comply with the privacy regulations of the jurisdictions in which it operates.

Institutional Principles are the principles your organisation has chosen to adopt — technology standards, quality thresholds, architectural commitments, process requirements. These could be otherwise; you have chosen to be bound by them. They are the most strategically important category because they are the ones you can actually adjust. Example: All services in our platform must be independently deployable. We could have decided otherwise, but we decided this.

Heuristic Principles are experience-derived guidelines that represent accumulated wisdom without carrying mandatory force. A practitioner may deviate when context warrants, but should be able to explain why. Example: Prefer simple solutions over clever ones. Avoid coupling components that will need to change at different rates.

Two important failure modes to watch for when extracting principles from materials:

Principle by Proxy: This occurs when a specific tool, technology, or implementation is stated as a principle. "We use Python" is not a principle — it is a proxy. The underlying principle might be "we optimise for team mobility and ecosystem maturity," from which Python follows as a valid current choice. Expressing the proxy rather than the principle locks you into an implementation when the true commitment is more general. When you encounter a tool name, a technology name, or a specific method name in a candidate principle, look for the underlying functional requirement. That is the principle.

Undead Principles: These are institutional commitments that outlasted the strategic reason that created them. They were rational once — but the conditions that made them rational have changed. They continue to consume governance attention and create friction without serving any current purpose. When a candidate principle cannot be connected to any current strategic objective or operational risk, flag it as potentially undead. Ask: what problem does this solve today? If no one can answer clearly, the principle may need retirement.

Apply the following filter sequentially to any candidate principle statement found in your materials — strategic documents, architecture decisions, operating procedures, governance policies, or team agreements.

Ask: if we removed this commitment entirely, what would break or become unacceptable?

Ask: where does the force of this commitment come from?

Document the type alongside the principle. The type determines how the principle should be governed (see Section 4).

Ask: does this statement describe what must be true (function), or does it name a specific tool, technology, or process (structure)?

Ask: is this principle still serving an active purpose?

An organisation at early maturity does not need an exhaustive principle catalogue. It needs a coherent, active, enforceable minimum set. The following is the minimum viable composition.

The most common failure at early maturity is adopting too many institutional principles before the organisation has the capacity to govern them. A principle without enforcement is not a principle — it is an aspiration. And a large set of unenforced aspirations creates the Paradox of Principles: the more principles you declare, the more interpretive anxiety you generate, and the more defensive bureaucracy you produce in response. Start small. Start with what you can actually defend.

Use the following structure to document each extracted principle:

A principle without governance is an aspiration. For each principle in your minimum viable set, apply the following three-question test.

Can someone tell, in practice, whether this principle is being respected or violated?

If yes: the principle is observable. Proceed.
If no: the principle is too abstract to govern. Rewrite it until you can answer yes, or reclassify it as a value statement (which belongs in a different kind of document).

Is there a person or function that has the standing to stop work when this principle is being violated?

This does not require a formal role or title. It requires that someone has the acknowledged right to say "this violates our commitment" and be taken seriously. If no one has that standing, the principle is not yet constitutionally active — it is a stated preference. Name the person or function.

Does that person or function bear a consequence if the principle is violated on their watch and they did not act?

If yes: accountability exists. The governance loop is closed.
If no: the authority is advisory, not constitutional. Advisory authority reliably fails under pressure. This is the constitutional failure mode documented in aviation disasters, engineering collapses, and software outages alike: people who saw the problem but were not empowered — or did not feel empowered — to stop it.

Apply governance proportionate to the principle's type:

When applied to client materials, this guide should be used as follows:

Statements that do not survive Step 2 are preferences, guidelines, or procedures — valuable, but not principles. They should be retained in the appropriate document type, not promoted to the principle register.

A principle register that is honest about what it cannot yet govern is more valuable than one that is inflated with aspirations. The minimum viable set is the set you can actually defend today, with a clear path to extending it as governance capacity matures.

This guide is a pre-P3 reference document. It does not assume any P3 governance infrastructure. It is designed to create the conditions in which P3-compatible governance can subsequently be built.