TRINITY CO // MARCH 2026
Institutions are very good at building queues.
Sometimes this is unavoidable. Certain things genuinely have to happen in order. A building must be approved before it is built. A prescription must exist before medication is dispensed. Some processes follow sequence because the world itself imposes sequence.
But many queues exist for a simpler reason: the system decided that one step should wait for another, even though it does not actually need to.
Over time these decisions accumulate. A process becomes a pipeline, the pipeline becomes procedure, and the procedure becomes invisible. Eventually the order of operations is treated as though it were dictated by law or physics rather than by design.
This paper calls that condition sequencing inefficiency.
Sequencing inefficiency occurs when tasks that could proceed independently are forced into chronological order. The resulting delay is not caused by the work itself but by the structure through which the work is allowed to move.
The companion concept explored here is dependency compression: the removal of unnecessary sequential dependencies in institutional workflows where no legal, physical, or safety requirement mandates a particular order of operations.
Put plainly:
If two things do not need to wait for each other, they should not.
The claim is not that institutions should abandon sequence altogether. Many dependencies are real and essential. The claim is narrower and more practical: in many modern systems, delay is produced not by complexity alone but by inherited sequences that no longer serve a necessary purpose.
In those systems, the queue is not inevitable. It is architectural.
I. The Inheritance of Sequence
Sequential process design once made perfect sense.
Early administrative systems operated under severe information constraints. Records were physical, verification was slow, and information rarely existed in one place at one time. Under those conditions the safest design was linear: one office checked the work, passed it along, and the next office repeated the process.
This structure solved two problems at once.
First, it controlled information flow.
Second, it distributed responsibility.
Sequential review ensured that no single official bore the entire burden of a decision. Each stage confirmed the previous one. Errors of commission—decisions made too quickly or with insufficient verification—were less likely.
The price of this caution was time.
In contemporary systems many of the informational assumptions underlying that design have changed. Digital records allow multiple actors to access the same information simultaneously. Verification processes that once required days can now occur instantly. Entire categories of administrative friction have quietly disappeared.
But the sequence often remains.
This persistence is largely a product of path dependence. Institutions preserve familiar process structures long after the conditions that produced them have changed. Once embedded, a workflow becomes part of the organisational landscape. Altering it requires redistributing authority, modifying accountability, and asking people to operate outside long-established routines.
The easier option is to digitise the existing process.
The result is a pattern now common in public administration: efficient digital entry points feeding work into deeply sequential internal pipelines. The interface accelerates. The machinery behind it does not.
II. False Dependencies
A useful distinction clarifies the issue.
Some dependencies are real.
A structure cannot be built before approval is granted.
A clinical intervention cannot occur before diagnosis.
Certain steps must happen in order because the underlying activity demands it.
Other dependencies are administrative.
They exist because a system has chosen to arrange tasks in sequence even though the tasks themselves are independent.
Consider a permitting process in which engineering review begins only after a planning determination has been issued. In many cases the engineering assessment—such as driveway gradients, drainage connections, or service interfaces—does not logically depend on the completion of the planning review. Both assessments draw on the same proposal and address different concerns.
Yet the process forces one to wait on the other.
The resulting delay is not created by the law. It is created by the workflow.
Multiply that pattern across multiple departments and the effect becomes substantial. The problem is not a single slow step. It is the accumulation of waiting states inside the system itself.
III. Dependency Compression
Dependency compression addresses this problem directly.
The principle is straightforward: map the workflow, identify which steps genuinely depend on one another, and remove the sequential links that do not.
In systems terms this reduces the critical path—the minimum time required for a process to complete.
When unnecessary steps sit on that path, the entire system slows down. Removing them does not weaken oversight; it simply prevents the process from waiting on work that is unrelated to the task at hand.
Dependency compression is not a call for recklessness. Some dependencies exist for good reasons. Safety checks, legal determinations, and procedural safeguards frequently require sequence. The purpose of compression is not to eliminate these protections but to ensure that they appear only where they are genuinely required.
The design question becomes simple:
Which steps actually depend on each other?
Everything else is negotiable.
IV. Evidence from Institutional Reform
Examples of dependency compression are increasingly visible across institutional systems.
Planning and permitting reforms provide a particularly clear illustration. Jurisdictions that have attempted to accelerate development approvals often discover that the principal delays do not arise from the complexity of any single assessment but from the sequential arrangement of multiple independent reviews.
Washington State’s Local Project Review reforms, for example, emphasise consolidated permit review, defined completeness determinations, and statutory processing timelines. These measures do more than impose deadlines. They implicitly challenge the assumption that each component of the review must occur as an isolated chronological stage.
Singapore’s CORENET X platform reflects a similar shift. Rather than requiring separate submissions and review cycles for multiple agencies, the system encourages coordinated submission and concurrent evaluation around a shared building information model. Agencies continue to exercise their individual responsibilities, but the workflow no longer assumes that each must operate as a sequential gate.
The lesson in both cases is straightforward: digitisation improves institutional performance only when it is paired with workflow redesign. Moving a sequential process online does not eliminate the queue. It simply relocates it.
V. Analogues in Technical Systems
Comparable patterns appear outside government.
Software build systems frequently suffer from excessive dependency chains in which one task blocks another unnecessarily. Modern build architectures address this problem by identifying which tasks genuinely rely on one another and allowing the rest to execute concurrently.
Retail technology provides another example. Traditional checkout systems impose a rigid sequence: queue, scan, pay, exit. Sensor-driven retail environments can track item selection and process payment asynchronously, collapsing steps that once required explicit ordering.
These examples do not imply that institutional systems should imitate commercial platforms. The risks and responsibilities are different. They do demonstrate, however, a common structural principle: systems become slower than necessary when independent operations are treated as dependent ones.
VI. Why Institutions Preserve the Queue
If the problem is visible, why does it persist?
Three forces tend to reinforce sequential systems.
First is risk diffusion. Sequential workflows distribute responsibility across multiple actors. When decisions pass through a chain of reviewers, accountability is shared. Removing those stages can feel dangerous even when the underlying safeguards remain.
Second are political incentives. Interface improvements are visible and easy to fund. Workflow redesign is internal, contentious, and likely to disrupt established departmental boundaries. Governments therefore often modernise what the applicant sees while leaving untouched the structure that governs what happens after submission.
Third is cognitive comfort. Linear processes are easy to understand and monitor. Parallel systems require stronger coordination and clearer communication. For organisations accustomed to hierarchical control, the shift can feel destabilising.
The queue persists not because it is necessary, but because it is familiar.
VII. AI, Human-in-the-Loop Discovery, and Dependency Mapping
The concept of dependency compression did not emerge from automated analysis alone. It arose through a human-in-the-loop process in which real-world observation interacted with AI-assisted exploration.
The initial insights came from practical encounters with institutional systems: noticing situations in which work appeared to be waiting on steps that did not obviously require it. Dialogue with AI then helped test and refine those observations, exploring whether the same structural pattern appeared across different domains.
This interaction produced a recursive loop:
human observation ↕ AI reframing and exploration ↕ human refinement
AI in this context functions less as an autonomous theorist than as a cognitive instrument. It allows rapid iteration between example and abstraction, helping surface patterns that might otherwise remain isolated observations.
Once the concept is articulated, AI can also assist in a second role: mapping dependency structures within complex systems. Institutional workflows often contain hundreds of decision points and handoffs. AI-assisted analysis can trace these relationships, identify repeated gating patterns, and reveal where chronological order reflects genuine constraint and where it merely reflects historical design.
VIII. Architectural Parallels
There is a further, somewhat unexpected parallel.
Large language models themselves operate by compressing dependencies.
Transformer architectures evaluate relationships between tokens through attention mechanisms that allow many contextual relationships to be assessed simultaneously. Rather than reasoning through long sequential chains, the system evaluates patterns across the entire input in parallel before producing an output sequence for human readability.
In simplified terms, reasoning in LLMs is less like a chain and more like a field collapsing into a path. Sequence might be how we render something fundamentally simultaneous – translated into time so it makes sense to us. And that observation is enough to make my sense of thought as something linear start to look like a convenient illusion.
Did I just write that or think it out loud?
At any rate, the comparison should not be overstated. Institutional systems operate within legal and political environments that impose constraints very different from those of machine inference. Yet the parallel is suggestive: both human organisations and computational systems become inefficient when they treat independent elements as though they must wait on one another.
IX. Limits of Compression
Dependency compression is not a universal prescription.
Some sequences exist for reasons that extend beyond operational efficiency. Legal due process, democratic accountability, and safety regulation all require structured deliberation. In these contexts delay may be the cost of legitimacy rather than the result of poor design.
The purpose of dependency compression is therefore diagnostic rather than doctrinal. It provides a method for asking a simple but powerful question:
Which parts of this process genuinely need to wait?
Where the answer is “none,” the queue is not a safeguard. It is a design choice.
X. Conclusion: The Institutional Critical Path
Institutional delay is often discussed as though it were an unavoidable feature of complexity. The evidence suggests something slightly different. In many systems the primary source of delay is not the difficulty of individual tasks but the sequential structure through which those tasks are forced to pass.
Dependency compression offers a way to see this structure clearly. By distinguishing between necessary dependencies and inherited sequences, institutions can redesign workflows so that independent work no longer waits unnecessarily.
The result is not a reckless acceleration of decision-making. It is a quieter form of reform: the removal of queues that never needed to exist.