The system as intended
- Purpose and desired outcomes
- Policies and procedures
- Roles and decision rights
- Controls and architecture
- Approved tools and workflows
- Measures and expectations
The Foundry Framework
Start with what is.
Build what should be.
A disciplined way to understand operational reality, design intentionally, and learn from what happens next.
Organizations are not static structures. They are living systems shaped by intent, design, people, constraints, information, tools, incentives, and time. The Foundry Framework makes that system visible—and provides a repeatable method for changing it without losing sight of why it exists.
THE OPERATING SYSTEM
01
Intent
What are we trying to accomplish?
02
Design
How is the organization supposed to work?
03
Operation
How does the work actually happen?
04
Outcome
What does the operating system produce?
Reality enters at every stage.
THE FOUNDATIONAL IDEA
Understand reality. Design intentionally. Learn continuously.
Operational Reality
The system on paper is only half the story.
Every organization has a system as designed and a system as operated. Policies, controls, workflows, structures, tools, and plans describe the first. Decisions, handoffs, adaptations, workarounds, relationships, local knowledge, and repeated behavior create the second.
The distance between them is not automatically failure. It is information about the environment, the design, and the people required to make the system work.
THE DISTANCE
EVIDENCE
The system as lived
- Judgment and adaptation
- Workarounds and exceptions
- Relationships and handoffs
- Shortcuts and local controls
- Institutional knowledge
- Actual outcomes and evidence
Most assessments begin by asking whether reality conforms to design.
We begin by asking why it does not.How to Read the Framework
One system. Four relationships.
The Framework connects the operating lifecycle, the lenses used to examine it, the method used to change it, and the condition the work is intended to create.
The Lifecycle
Intent → Design → Operation → Outcome
How purpose becomes a working system—and how the results of that system become evidence about both the design and the original intent.
The Lenses
Strategy · Structure · Process · Information · Culture
Five connected views used to understand a condition without isolating it inside a department, tool, control family, or process diagram.
The Method
Observe → Understand → Design → Implement → Measure → Adapt
A repeatable cycle for moving from evidence to context, from context to deliberate design, and from implementation to governed learning.
The Outcome
Operational Coherence
A condition in which purpose, design, operation, evidence, and adaptation agree closely enough for the organization to act, learn, and change without losing intent.
Operational Drift
Organizations rarely break all at once.
They drift.
A tool cannot support the approved process. A customer needs an exception. A contract changes the obligation. A role turns over. A deadline makes the formal path impractical. A spreadsheet fills a gap. An unofficial conversation becomes the only reliable handoff.
Each response may be rational in isolation. Some are improvements. Some create exposure. Many are both useful and fragile. Over time, however, the operating model separates from its stated design. Leaders continue steering by the map while the organization has quietly changed terrain.
That widening distance is Operational Drift: the gradual divergence between the system an organization intends to operate and the system its people have learned to operate in practice.
Constraint
A tool, policy, deadline, contract, resource limit, or organizational boundary makes the intended path difficult or impossible.
Adaptation
People adjust the work so they can still produce an acceptable result. The change may be smart, risky, necessary, invisible—or all four.
Normalization
The adaptation becomes ordinary. New people learn the local method. The documented design remains unchanged while the operating model moves on.
Distance
Leadership, assurance functions, and operators are now using different maps. Decisions are made from an incomplete picture of the system.
Adaptation isn’t the enemy. Unobserved adaptation is.
Governance fails when it assumes that the approved system and the operating system remain identical. Agility fails when every invisible adaptation is celebrated as responsiveness. The Framework creates a third position: make adaptation visible, understand what it means, and decide deliberately what the system should learn from it.
Read the Operational Drift InsightFive Lenses
See the organization as a whole system.
Operational reality does not respect the borders between departments, standards, tools, transformation programs, or audit scopes. A process problem may be structural. A control failure may be informational. A cultural behavior may be a rational response to strategy or incentive.
The five lenses are not separate workstreams. They are different views of the same system—and each lens changes what the others mean.
01
LENS
Strategy
What are we actually trying to accomplish?
Strategy establishes direction and the decision logic behind it. It makes priorities, outcomes, obligations, constraints, and meaningful tradeoffs explicit enough to guide the rest of the system.
Look at
- Purpose and intended outcomes
- Priorities and tradeoffs
- Risk appetite and obligations
- Decision rights and escalation
- Measures leadership actually uses
02
LENS
Structure
How have we organized ourselves to act?
Structure distributes authority, responsibility, expertise, capacity, and accountability. It determines where decisions can be made, where work crosses boundaries, and where the organization depends on coordination.
Look at
- Roles and accountability
- Authority and decision boundaries
- Capacity and capability
- Formal and informal dependencies
- Ownership across handoffs
03
LENS
Process
How does the work actually happen?
Process is the movement of work through the organization: triggers, decisions, controls, handoffs, exceptions, feedback, and recovery. The documented path matters; the lived path matters more.
Look at
- Triggers and inputs
- Decisions and controls
- Handoffs and queues
- Exceptions and recovery paths
- Rework, delay, and local optimization
04
LENS
Information
What does the organization know—and who knows it?
Information is the evidence, context, records, signals, and institutional knowledge required to make decisions. It includes formal systems of record and the knowledge that moves through conversation and memory.
Look at
- Sources and systems of record
- Information flow and access
- Evidence and traceability
- Decision context
- Institutional and tacit knowledge
05
LENS
Culture
What happens when nobody is directing it?
Culture is the system expressed through repeated behavior. It shows up in incentives, trust, habits, language, local norms, and what people believe will actually be rewarded, challenged, ignored, or punished.
Look at
- Incentives and consequences
- Trust and psychological safety
- Behavior under pressure
- Unwritten rules and local norms
- What leaders tolerate or reinforce
ONE OPERATING SYSTEM
Strategy gives the system direction. Structure gives it the capacity to act. Process moves the work. Information makes decisions possible. Culture determines what the system does when the design runs out.
The Method
Observe. Understand. Then design.
The order is intentional. Most improvement efforts begin with an answer: a standard, a tool, a target process, a transformation roadmap, or a preferred future state. The Foundry Framework begins with a question.
So, what do you actually do?
From there, the work moves through six repeatable stages. The cycle does not end with implementation because implementation is where the next body of evidence begins.
01
Observe
Start with what exists.
Follow the work. Gather evidence from the people, tools, records, handoffs, decisions, and exceptions that make the operating system visible. Observation is not an audit, a maturity assessment, or an invitation to begin correcting what you see.
- Key question
- What is happening—consistently enough that it belongs in our picture of the system?
- Evidence of progress
- A grounded evidence baseline: intended design, observed work, recurring adaptations, friction, dependencies, and relevant outcomes.
- Failure mode
- Observation fails when the investigator arrives with the answer, treats operators as evidence of noncompliance, or records only what fits the expected model.
02
Understand
Discover why it became this way.
Place each observation in context. Trace the constraint, history, incentive, dependency, tradeoff, or missing capability that shaped the current condition. A workaround may indicate disregard for a control—or it may be the only thing keeping an impossible process alive.
- Key question
- What problem is this behavior solving, and what would happen if it disappeared tomorrow?
- Evidence of progress
- An explanation of the operating condition: causes, dependencies, consequences, competing needs, and the relationship between local behavior and the wider system.
- Failure mode
- Understanding fails when correlation is treated as cause, leadership intent substitutes for operator experience, or the first plausible explanation ends the investigation.
03
Design
Respond intentionally to what you learned.
Decide what the operating model should become. Preserve what works. Formalize valuable resilience. Repair broken interfaces. Remove unnecessary friction. Integrate requirements into the work instead of layering them over it. Make the future state explicit enough to implement and measure.
- Key question
- What arrangement of roles, work, information, controls, and behavior best serves the intent under real constraints?
- Evidence of progress
- A coherent design with explicit decisions, ownership, interfaces, controls, measures, assumptions, and adaptation boundaries.
- Failure mode
- Design fails when a standard, tool, or preferred practice is mistaken for the operating model—or when individual improvements create new contradictions elsewhere.
04
Implement
Put the design into the real system.
Translate design into changed work: decisions, roles, tools, records, routines, measures, communication, and behavior. Implementation includes the conditions people need to adopt the design, not merely the deliverables used to describe it.
- Key question
- What must become different in the ordinary Tuesday version of the work?
- Evidence of progress
- Observable use: people can perform the work, evidence is produced, interfaces function, ownership is understood, and the new path can survive normal pressure.
- Failure mode
- Implementation fails when approval is mistaken for adoption, training is mistaken for capability, or receipt of a deliverable is treated as proof that the system changed.
05
Measure
Determine what changed.
Measure the operation rather than the project. Look for evidence that intended behaviors, outcomes, controls, and information flows have taken hold—and for unintended effects the design did not anticipate.
- Key question
- Did reality change in the way we expected, and how would we know if it had not?
- Evidence of progress
- A performance and assurance picture connected to intent: outcomes, leading signals, exceptions, control evidence, lived experience, and emerging adaptation.
- Failure mode
- Measurement fails when completion, attendance, publication, or tool configuration stand in for operating evidence—or when metrics cannot change a decision.
06
Adapt
Incorporate what reality taught you.
Use evidence to preserve, refine, or replace parts of the design. Update assumptions, controls, measures, documentation, and ownership as the environment changes. Adaptation is governed learning: deliberate enough to preserve intent and responsive enough to remain useful.
- Key question
- What must the operating model learn—and what now needs to be observed again?
- Evidence of progress
- Controlled evolution: decisions are recorded, the design reflects current reality, useful adaptations are incorporated, and the next observation cycle has a clear starting point.
- Failure mode
- Adaptation fails when every change is treated as loss of control, when uncontrolled drift is renamed agility, or when lessons remain local and invisible.
Return to reality. The design changes the operation. The operation produces new outcomes. Those outcomes become evidence for the next cycle.
Decision Discipline
Understanding creates choices—not automatic correction.
Once an operating condition is visible and understood, leadership can decide what it means. The Framework uses five decision categories to prevent every observation from becoming an undifferentiated action item.
Preserve
Leave an effective element in place because it serves intent, operates reliably, and does not create unacceptable risk or contradiction.
Formalize
Bring a valuable informal adaptation into the operating model so it has ownership, support, traceability, and a deliberate relationship to other controls.
Investigate
Hold the decision open because the evidence, cause, consequence, or wider system relationship is not yet understood well enough to act responsibly.
Redesign
Change the operating model because the current arrangement creates friction, fragility, risk, incoherence, or outcomes inconsistent with intent.
Retire
Remove an obsolete, duplicative, harmful, or unsupported element—and confirm that the need it once served is no longer being ignored.
Four Disciplines
What the Framework requires.
The Framework is deliberately skeptical of clean diagrams, completed deliverables, and confident recommendations that have not been tested against the way work happens. It imposes four disciplines on every application.
Evidence before judgment
Treat operational reality as information before classifying it as failure, noncompliance, resistance, or bad behavior.
Cause before correction
Do not remove an adaptation until the need, constraint, dependency, or incentive that created it is understood.
The whole system in view
Trace a condition across strategy, structure, process, information, and culture—not only the function where the symptom appeared.
Learning after delivery
Implementation creates new evidence. Measurement and adaptation belong inside the work, not in a post-project appendix.
THE FRAMEWORK IS
- A way to make operational reality visible
- A whole-system method for deliberate design
- A bridge between governance and adaptation
- A repeatable learning cycle
- A means of building lasting organizational capability
THE FRAMEWORK IS NOT
- Another standard or control catalog
- A universal maturity score
- An excuse for uncontrolled workarounds
- A transformation roadmap that ends at delivery
- A method for creating permanent consultant dependency
The Outcome
Operational Coherence.
The parts of the organization do not need to be identical. They do need to tell the same story.
Operational Coherence is the condition in which intent, design, operation, evidence, and adaptation agree closely enough for the organization to act deliberately. Strategy, structure, process, information, and culture make sense together. Requirements show up in the work. Tools support the process they were purchased to enable. Measures describe outcomes leaders actually care about.
Coherence does not mean perfect alignment, frozen process, or the absence of exception. It means the organization can see where the parts agree, where they do not, why the distance exists, and what decision that distance requires.
Direction is usable
People can connect daily decisions to purpose, priorities, obligations, and the outcomes leadership actually intends.
The design survives contact
Roles, processes, controls, tools, and information flows support ordinary work without requiring constant heroics or hidden repair.
Evidence tells one story
Documents, records, measures, operator experience, and leadership understanding describe the same operating system closely enough to support decisions.
Adaptation remains visible
The organization can change course without losing intent, burying the change, or allowing local solutions to become unmanaged enterprise risk.
Capability remains behind
The system can be understood, operated, and improved by the organization—not only by the people or consultants who originally designed it.
Where It Helps
Use the Framework when the symptom is visible—but the system is not.
The Framework is not limited to compliance or management systems. It can be applied wherever intent, design, operation, and outcome have separated enough to make decisions unreliable.
-
01
Your documentation looks right, but ordinary work consistently routes around it.
-
02
Audit findings recur because corrective action repairs the evidence without repairing the operating condition.
-
03
A tool implementation, reorganization, merger, or growth cycle has changed how work moves across the organization.
-
04
Critical outcomes depend on a person, relationship, spreadsheet, or body of institutional knowledge nobody planned for.
-
05
A new requirement or technology is being layered onto the organization without a coherent operating design.
-
06
Leadership can see symptoms—delay, rework, inconsistency, control failure, customer friction—but not the system producing them.
-
07
Teams need room to adapt, but governance cannot see where adaptation improves resilience and where it creates exposure.
-
08
A transformation delivered its artifacts, yet the work, decisions, measures, or outcomes did not meaningfully change.
The Framework in Practice
We did everything right.
Until reality entered the room.
We reviewed the documentation. Mapped the processes. Interviewed leadership. Wrote the procedures. Delivered the recommendations. Months later, while preparing to put those processes into a new tool, we finally sat beside the people doing the work and asked a more useful question: show me what you actually do.
The system we found was full of adaptations—not arbitrary deviations, but evidence about constraints we had never taken the time to understand. We had designed for the organization before reality had its say.
Read the Full InsightPut It to Work
One Framework. Several ways in.
The Foundry Framework is the common operating logic beneath our assessments, products, analysis, and embedded services. Start at the point that matches the work in front of you.
The Tuesday Assessment
A focused investigation of where intended design and real operation have separated—and why. It produces an operational reality map, an adaptation register, a leadership brief, and deliberate decisions without the 200-page transformation deck.
Explore the AssessmentReadiness Kits
Coordinated management-system foundations for ISO 9001, ISO/IEC 20000-1, ISO/IEC 27001, and integrated systems. Understand the requirements. Build the system. Make it yours. Templates are a foundation—not certification.
Explore Readiness KitsFoundry Intelligence
Practical analysis of what changed, why it matters, and what the change means for the systems you already operate. It is the handoff from what works today to what changes tomorrow.
Explore Foundry IntelligencevFSO
Experienced security administration embedded in the real work of cleared organizations—with explicit scope, operational discipline, clear ownership, and mission focus.
Explore vFSOQuestions
About the Framework.
These distinctions matter. The Framework is intended to make governance and improvement more grounded—not to replace obligations, excuse invisible work, or create a new layer of theory.
01 Is the Foundry Framework a standard or maturity model? +
No. It is a way to investigate, design, and continuously reconcile an operating system. It does not assign a universal score or prescribe one target state. The right design depends on the organization, its purpose, obligations, strategy, constraints, people, and operating reality.
02 How does it relate to ISO, NIST, ITIL, CMMC, and other bodies of knowledge? +
Standards and frameworks provide requirements, practices, vocabulary, and useful design inputs. They do not, by themselves, explain how your organization actually operates. The Foundry Framework helps translate those external expectations into a coherent system that can function in real work and produce meaningful evidence.
03 Does the Framework excuse noncompliance or uncontrolled workarounds? +
No. Understanding is not approval. A control failure may still require immediate containment, and a legal, contractual, safety, or security obligation remains an obligation. The Framework improves the quality of correction by identifying the operating condition that produced the failure instead of repairing only the visible evidence.
04 Does every difference between design and reality need to be eliminated? +
No. Some differences create risk; others remove friction or compensate for a weakness elsewhere. Some are obsolete, and some represent valuable resilience. Observe and Understand create enough context to choose deliberately: preserve, formalize, investigate, redesign, or retire.
05 How is this different from continuous improvement or PDCA? +
The Framework is compatible with continuous-improvement cycles, including PDCA. Its distinct emphasis is the explicit separation of intended design from lived operation, the use of five connected organizational lenses, and the requirement to understand adaptation before deciding what change means. It supplies a deeper operating picture for improvement cycles to act upon.
06 How does the Framework balance agility and governance? +
Governance keeps intent, obligations, ownership, evidence, and decision boundaries visible. Agility allows the means to change as evidence and conditions change. The Framework rejects both frozen compliance theater and adaptation nobody can see. Govern the intent and the learning—not every movement of the work.
07 Where does the Tuesday Assessment fit? +
The Tuesday Assessment is a practical entry into Observe and Understand. It establishes the intended design, follows the real work, identifies the distance, investigates why it exists, and makes the resulting conditions and decisions visible to leadership.
08 Does the Framework require a long consulting engagement? +
No. The Framework can guide a focused assessment, an internal improvement effort, a management-system build, an operating-model redesign, or ongoing governance. The goal is not perpetual consulting. The work should leave the organization better able to understand, operate, and adapt its own system.
09 Where should an organization begin? +
Begin with the point of uncertainty. If leaders cannot see how the system actually operates, begin with observation—often through a Tuesday Assessment. If the gap is understood and the need is a coherent management-system foundation, a Readiness Kit may be the better entry. If the system exists and the environment is changing, Foundry Intelligence or a scoped advisory engagement can support measurement and adaptation.
Begin with Reality
Don’t begin with the answer.
Begin with the operating system you actually have. We can help you see it clearly, decide deliberately, and build what comes next.
