The Chenla Operating System
How we organize what we know.
Most consultancies accumulate a set of principles, a methodology, a folder of SOPs, and a toolkit. The pieces live in different places, written in different voices, by different people, at different times. Over a few years they drift, contradict each other, and quietly stop being followed.
The Chenla Operating System is what we built instead: a single layered structure where principles flow into frameworks, frameworks into standards, standards into the workflows our team completes every day, and tools that support the work at each level.
This page describes the layers. The contents of most layers stay internal. What you can see publicly is enough to understand how we think.
The Five Layers
1. Principles
The values and lenses that guide decisions. Revised rarely; durable across project types, client kinds, and market cycles. Principles answer the question 'what kind of firm are we trying to be.'
Public surface: a small set of operating principles. Internal: deeper reasoning, decision precedents, and the lessons that produced each principle.
2. Frameworks
The named methodologies that organize how we deliver. A framework gives a project shape: what to look at, in what order, with what discipline. Frameworks are revised when delivery context shifts materially.
Public surface: The Canopy Framework, our named approach to construction project management. Internal: service-specific delivery frameworks for individual disciplines.
3. Standards
The documented procedures. Standards translate principles and frameworks into specific repeatable steps. Reviewed quarterly, revised annually.
Public surface: the client-facing onboarding SOPs. Internal: communication templates, internal escalation criteria, and procedures that vary by client kind or project sensitivity.
4. Process Workflows
Standards encoded into the workflows our staff complete every day, in our internal platform. Daily Site Reports, Daily Project Reports, period-close checklists, handover packages. The platform makes the standards mandatory at the point of work, so adherence is structural rather than aspirational.
Public surface: the existence and shape of this layer. Internal: the specific workflows, fields, validation rules, and the platform itself (we use it as a service-delivery instrument, not a product offering).
5. Tools
The specific instruments that support the work: documentation standards, modelling conventions, reporting templates, communication patterns. Tools are replaced when better instruments emerge.
Public surface: the categories of tools we use. Internal: tool selection rationale, configuration, and the ways individual instruments connect to the layers above.
From documents to enforced practice
Most firms have SOPs. Most firms' SOPs are not followed.
That is not a failure of discipline. It is a structural fact about documents. A procedure written down once and read once a year cannot survive contact with daily work. The gap between doctrine and practice is what every consultancy lives in.
The Chenla Operating System is built around the observation that procedures do not change behavior unless they are encoded into the work itself. The Standards layer documents what should happen. The Process Workflows layer is where the documented standards become mandatory at the point of execution. A site engineer cannot submit a Daily Site Report without completing the fields the SOP requires. A project cannot reach handover without the closing checklist completed.
This is the difference between a written rule and an enforced one. It is also why we are willing to publish our standards in full: copying the documents does not produce the result. The result lives in the workflow layer, which is harder to copy and takes longer to build than the documents that name it.
Revision Cadence
Each layer has its own rhythm. Visible revision dates on every public artefact carry the cadence below.
Why we publish at all
Most operating systems stay private. Publishing them is unusual and easy to misread as either marketing or arrogance.
We publish for three reasons. First, legibility: clients, collaborators, and future hires should be able to see how we think before they engage us. Second, accountability: a published standard is one we can be held to. Third, durability: documents revised in public have to stay coherent in a way internal-only documents do not.
The trade-off is real. Some of what is below the surface here would be useful to a competitor. We take the trade because the same publishing discipline that exposes the layers is what keeps them coherent over time.
Related Insights
What Clients Don't Pay For
May 19, 2026
Earlier this year we wrote an internal standards reset for our team. The single line that reorganised the firm was a short list of what clients don't pay for.
Read more →
If It's Not in the System, It Doesn't Exist
March 3, 2026
Most project stress doesn't come from complexity. It comes from partial memory. Structure first. Clarity follows.
Read more →
The Cost of Familiar Friction
December 22, 2025
Ten years ago I chose a keyboard because I liked the sound. This week I finally switched. The difference was immediate. Not dramatic. Just absence.
Read more →
Clarity Through Structure
December 10, 2025
Rebuilding our website and knowledge base revealed more about the business than any attempt at writing SOPs. Sometimes structure gives clarity long before clarity gives structure.
Read more →
Define Once. Repeat Reliably.
August 20, 2025
A single clear definition can scale better than endless ad-hoc fixes — in systems and in leadership.
Read more →
Rebuilding from the Inside Out
July 22, 2025
We are rebuilding our office from the inside out. Not just for aesthetics, but for how we want to collaborate, delegate, and grow.
Read more →Want to see how this works on a real project?
The fastest way to understand a layered system is to see it in operation. We'd welcome a conversation.