Worksona.fp: First Principles of Structured Work
#worksona#first-principles#worksona-theory#foundation#knowledge-work#systems-design
David Olsson
These principles were not designed. They were uncovered.
Across 110 projects — multi-agent orchestration systems, industrial ML deployments, organizational simulations, pharmaceutical pipelines, market research platforms, browser-native tools — we kept encountering the same failure modes. Different domains, different tech stacks, different teams, same breakdowns. Not bugs. Structural problems. Failures that only become visible under scale, uncertainty, or change.
We named them. We generalized them. We tested whether they held across executors — whether the same constraint that explains why an LLM agent fails also explains why a human team fails. It does. Every time.
What follows is the resulting compendium: sixteen irreducible structural constraints governing any complex knowledge work system. We call it worksona.fp.
The Core Observation
Most work-system failures are not capability failures. The system had the capability. It applied it in the wrong context, passed incomplete state across a boundary, or proceeded when it should have refused. These are structural failures — and they are almost entirely predictable before they happen, if you know what to look for.
The principles below describe what to look for.
The Principles
Principle 1: Competence Is Always Local
No capability is universally valid. All competence exists within a bounded region of work where assumptions, metrics, and guarantees hold. Global behavior must emerge from the coordination of locally valid regions — not from any single generalized rule, role, or policy.
This is the foundational principle. It explains why a senior analyst who is excellent at synthesizing research produces poor results when asked to manage stakeholder politics — same person, different validity region. It explains why a language model that handles document summarization confidently should not be trusted to make financial projections without explicit recontextualization. The region changed; the capability did not notice.
Principle 2: Validity Is a Precondition for Action
Work must not proceed outside its region of validity. Executing a capability when its assumptions do not hold is not a degraded mode — it is an error. Systems must refuse, reroute, or escalate rather than proceed optimistically.
Optimistic execution is one of the most common failure patterns we observe. A system or team that "does its best" when the inputs are out of range is not exhibiting resilience. It is producing outputs that look valid and are not, which is worse than producing no output at all.
Principle 3: Guarantees Must Be Structural
If an outcome matters, it must be enforced by structure. Rules that exist only in documentation, intent, training, or memory will fail under scale. Guarantees must be explicit, checkable, and enforced at runtime.
A hard safety constraint in a manufacturing ML system is structural. A note in a README saying "do not deploy to production without review" is not. One of them survives team turnover, time pressure, and Friday afternoon deploys. The other does not.
Principle 4: Composition Is the Primary Failure Surface
Most failures occur at boundaries, not within regions. Safe behavior cannot be achieved by chaining work blindly. It requires explicit overlap protocols with shared representations, declared invariants, and enforced handoffs.
When we audit systems — software or organizational — we find that each individual component works. The orchestration layer fails. The handoff corrupts state. The boundary assumption is unstated. Composition is where complexity accumulates and where structural debt surfaces first.
Principle 5: Transitions Are First-Class Objects
Handoffs must be designed, not implied. Every transition must explicitly declare what state is preserved, what state is transformed, and what state is discarded. Implicit context transfer creates silent corruption.
The most expensive bugs we have encountered are not logical errors — they are state transfer errors. The receiving component inherits partial context from the sending component, proceeds on flawed assumptions, and produces results that are plausible but wrong. The failure is invisible until it compounds.
Principle 6: Refusal Is Correct Behavior
Inability to guarantee correctness is not failure. When no valid region can safely act, the correct response is refusal, escalation, or request for clarification. Proceeding without guarantees is the real failure.
Systems that never refuse are systems that cannot be trusted. A system that confidently answers every question — regardless of whether the question falls within its validity region — is not capable; it is brittle. Refusal is the mechanism by which a system signals the boundary of its competence. Removing that signal removes the boundary.
Principle 7: Metrics Encode Alignment
Alignment is not expressed through tone, intent, or values. It is encoded through explicit metrics that define acceptable trade-offs between risk, cost, speed, and certainty within each region of work.
This principle is uncomfortable because it implies that a team without explicit metrics is not aligned — regardless of how well they communicate or how much they share stated values. Two people with identical values and no shared metric will make different trade-off decisions under pressure. The metric is not a bureaucratic formality. It is the operational definition of what "good" means.
Principle 8: Uncertainty Narrows Validity
Uncertainty is structural, not psychological. Regions of novelty, ambiguity, or conflict require narrower applicability, stronger guarantees, and more conservative routing. As uncertainty increases, validity regions must contract.
A system deployed in a familiar, well-characterized domain can operate with wide validity regions and loose guarantees. The same system deployed in an unfamiliar domain must narrow its claims, increase its verification overhead, and escalate more aggressively. Uncertainty is not a property of the executor's confidence — it is a property of the environment. It must be responded to structurally, not emotionally.
Principle 9: Observability Is a Safety Requirement
Unobservable systems cannot be governed. Routing decisions, invariant checks, refusals, and transitions must be observable to enable debugging, audit, and trust. Opacity guarantees eventual misalignment.
We added this principle after seeing how often observability is treated as a "nice to have" feature added after a system is working. It is not a feature. It is a prerequisite. A system that cannot explain what it decided and why cannot be corrected when it decides wrongly — and all systems eventually decide wrongly.
Principle 10: Intelligence Resides in Structure
Scalable intelligence does not reside in memory or interpretation. It is encoded in the structure that constrains behavior. Executors perform work; structure determines what work is possible.
This is the principle that most directly contradicts the instinct to solve scaling problems by finding smarter executors. The instinct is wrong. Intelligence encoded in a single executor — human or machine — does not transfer, does not replicate, and does not survive turnover or context loss. Intelligence encoded in structure does.
Principle 11: Additive Scaling Requires Isolation
Systems scale safely only when new regions do not entangle existing ones. Each region must remain locally scoped, with interactions governed exclusively through explicit, versioned overlaps. Implicit coupling accumulates systemic risk.
The pattern we see repeatedly: a system is extended by adding new capabilities adjacent to existing ones, without clearly defining boundaries. Interactions accumulate. Eventually a change to any part affects every part. The system becomes impossible to reason about and costly to modify. Isolation is not complexity — it is the precondition for long-term modifiability.
Principle 12: Governance Must Be Runtime-Enforced
Post-hoc review does not scale. Governance must occur during execution through invariant enforcement, controlled routing, and refusal — not after outcomes are produced.
Post-hoc review is evidence that a governance signal arrived too late. By the time the review happens, the work is done, the output is distributed, and the cost of correction is high. Runtime enforcement prevents the violation from completing. Review audits the logs of a system that is already governed.
Principle 13: Evolution Is Mandatory
Static structures decay in dynamic environments. Regions, interfaces, and guarantees must be versioned, refined, and deprecated intentionally. Stability arises from controlled evolution, not rigidity.
The failure mode here is mistaking structural stability for correctness. A system that has not changed in two years is not a well-governed system — it is a system that has been accumulating invisible misalignment with a changing environment. Intentional deprecation and versioning is the mechanism that prevents structural debt from silently accumulating.
Principle 14: Executors Share the Same Constraints
Differences in executor type do not change structural laws. Human workflows, automated systems, and hybrid organizations fail for the same reasons and succeed under the same constraints. Structure governs all execution.
This is the principle that makes worksona.fp portable. We did not write these principles for AI systems. We discovered that the principles we had validated for AI systems also explained human organizational failures — and vice versa. The executor is a variable. The structural constraints are not.
Principle 15: Critical Constraints Must Be Unavoidable
Anything essential must be impossible to bypass. The system must prevent violation, not rely on reminders, training, or good intentions. If correctness depends on remembering, it will fail.
Documentation that requires humans to remember to follow it fails under load, urgency, and time. Training that requires recall fails under novel conditions. The only reliable enforcement mechanism for critical constraints is making them unavoidable — structurally enforced so that the non-compliant path does not exist.
Principle 16: Structure Is the Primary Output
Artifacts are transient; structure determines long-term outcomes. Systems that optimize visible outputs over structural integrity accumulate invisible debt that surfaces only under stress, scale, or change.
This is the hardest principle to act on because the artifact is visible and the structure is not. A delivered document, a shipped feature, a completed project — these are legible. The structural integrity that determines whether the next document, feature, or project will be easier or harder to deliver is not legible until it degrades. Principle 16 asks us to account for it anyway.
What These Principles Are Not
They are not a methodology. They do not prescribe a process. They do not tell a team how to work — only what structural properties their work system must satisfy to remain reliable under stress.
They are not specific to AI. The most common mistake when reading these principles for the first time is to interpret them as AI safety guidelines. Some of the language comes from that domain, but the principles themselves describe structural properties that predate machine learning by decades. Every principle in this list was violated by human organizations long before the first transformer was trained.
They are not complete. worksona.fp is a living document. Principle 16 is marked optional because we are still testing whether it has the same predictive power as the others under empirical conditions. We expect to add, refine, and deprecate as the corpus grows.
How We Use Them
Every significant design decision in the Worksona portfolio is evaluated against these principles. Not as a checklist — as a diagnostic. When a system is misbehaving in ways that are hard to explain, we ask which principle is being violated. We have not yet found a systemic failure that does not map to at least one of the sixteen.
The principles also drive our scoring practice. We rate each project in the portfolio against all sixteen, score them on a 0–10 scale, and track the distribution over time. The projects that score lowest on Observability (Principle 9) and Structural Guarantees (Principle 3) are the ones that produce the most support burden. The correlation is reliable enough that low scores on those two principles are now leading indicators of technical debt before the debt becomes visible in output quality.
The diagnostic pattern is the most practical use. When a system fails, map the failure to a principle. The principle names the structural property that is absent. The remediation is to introduce that structural property — not to add process, training, or documentation, but to encode the guarantee into the system's structure so it cannot be bypassed.
That is the entire discipline. Structure first. Execution follows.
worksona.fp is maintained as part of the Worksona corpus. The full compendium, including scoring rubrics and worked examples from the portfolio, is available in the project documentation.