Introduction

I started experimenting with using AI assistants to provide style and fashion advice last year. I got excellent results, but the process required a lot of introspection and relied upon the user to ask the right questions. The idea to try and productise a more accessible version of this experience had been floating around in my head all winter, this culminated in outlining the philosophy underpinning the product in The Signal and the Self.

I chose the name 'Sextant' for the project some months ago. The sextant is an instrument used to measure distance to astronomical bodies and provide direction at sea, in popular use during the golden age of sale. Hence I envisaged Sextant as a non-coercive tool to help men navigate, only in the world of modern style and aesthetics.

As spring came I found myself exploring Devon in the UK. During the four day Easter bank holiday weekend I stayed in a converted chapel on the edge of Exmoor. With lambs being born in the field a stones throw from my laptop I undertook the project to get a working prototype in four days.

I heavily leveraged AI for both the planning and execution of this project. I used chatgpt for exploring ideas and design and I used windsurf for the implementation itself.

Day 1 - Friday - Scoping

The scoping was arguably the hardest task in the build. I had previously explored some ideas and nearly always came up with an increasingly widening feature set, including items such as: onboarding quizzes, garment ontologies, garment inventories, specific item recommendations, skin tone detection and outfit generation. These are all valid and desirable features but each one adds implementation load, cost and complexity to a product whose value has not yet been validated.

I forced myself to narrow the MVP down to the thinnest slice of functionality that was both bounded and evoked the value that I had experienced during self directed usage. I was aiming to find the smallest possible feature set that would provide signal. Chatgpt was extremely helpful as I used it to discuss different features, strategise and narrow scope.

I decided upon a single ‘photo upload’ -> ‘analysis’ flow. This preserved simplicity of implementation and delivered a feedback loop that preserved the engaging experience I had discovered during self-directed usage.

Day 2 - Saturday - Model and Backend

For production implementation I had some ideas around building detailed ontologies and using advanced computer vision techniques. However, for the purposes of getting to value and an MVP ASAP, I determined that I could build the analysis on top of an AI prompt.

I signed up for an openAI account and started using the API with the node sdk experimenting with different prompts and the outputs that they produced. I iterated and got a relatively stable output that I judged I could build the product on top of.

I settled for a model that looked like:

{
  "style_signal": "Summary",
  "coherence": "Represents how well items hang together: {low | medium | high},
  "anchor": "Strongest item",
  "friction": "Clashes",
  "adjustments": "List of suggested improvements",
  "preview_image_url": "base64 encoded image returned to frontend for display purposes"
}

For the backend I chose Express. The service only needed to perform a handful of tasks: accept an uploaded image, call the OpenAI API, and return a structured analysis response. Express is lightweight, well understood, and was more than capable of handling these requirements. More importantly, it allowed me to focus on the product rather than the infrastructure.

I constructed a single endpoint service accepting an image as input and returning analysis in the form of a structured json response. I built a library of test images representing different n-dimensional points in my model space. I scripted automated testing over the test image library against the backend to protect against regressions.

Day 3 - Sunday - Frontend

Now that I had a stable backend I switched my focus to building the frontend. The main goals were preserving the simplicity of the interaction loop and presenting the analysis in a comprehensible way.

For the frontend I kept the stack deliberately minimal: static HTML, CSS and vanilla JavaScript served directly from the Express app. The product did not need routing, state management, or a component framework, it needed simplicity. Serving the frontend from the same Express service also avoided unnecessary CORS and deployment complexity, keeping the application easy to reason about and fast to ship.

On the analysis page I opted for a card layout which would work well both on desktop and mobile. I ran my service through ngrok to provide a publicly available service, allowing testing on a mobile web browser, allowing me to tweak the appearance on mobile.

I added some polish in the form of a sextant logo and favicon. And I added some backstops such as per hour and per day rate limits to prevent abuse.

Day 4 - Monday - Production

On Monday I aimed to get my service into production and hosted on my custom domain sextantapp.io. I assessed the available options for hosting my web app. I chose Railway largely because it appeared to offer the shortest path from a local application to a publicly accessible product.

I asked Windsurf to configure the app for railway, connected the GitHub repository, configured the required environment variables, and had the application deployed and hosted on my custom domain within half an hour. DNS setup for my custom domain was handled automagically via cloudflare. For an MVP whose purpose was validation rather than scale, Railway removed a significant amount of operational friction. I added some logs, made sure errors surfaced correctly and I was done.

What I learned

The biggest surprise was that implementation was not the bottleneck. Once the scope was constrained and windsurf was leveraged then building the app was extremely straightforward. Windsurf being particularly effective when implementation tasks are tightly bounded.

Defining the judgement embedded within the product via the model and prompt proved substantially harder. While the first version uses a fairly simplistic model, the locus of future Sextant work lies in refining the underlying style model itself.

With a tight scope, leveraging Chatgpt for strategic discussion, Windsurf for implementation, and a minimal stack Sextant was born, alongside lambs over Easter.

You can use sextant now at sextantapp.io

</div> </div>

The real value in this interaction was not the sugar, but the co-operation, socialisation and resultant trust that was built.

Another man needs a missing ingredient. He opens an app. Perhaps it is sugar, perhaps milk, perhaps eggs. An hour later there is a knock at the door. A bag is left on the step. No conversation occurs.

This second man solved the same problem as the first. But the small need which once created a reason to knock on a neighbour’s door was routed through an impersonal logistics system. This isn’t just a different solution to the same problem, it is the erosion of social infrastructure.

Human social life is not produced merely by proximity. It is produced by repeated moments of forced contact, dependence, recognition, obligation and exchange. A person asks. Another person helps. A favour is owed. Familiarity accumulates, trust develops.

These moments occur across co-operation surfaces:

Co-operation surfaces are events where two or more people must co-ordinate to achieve an outcome.

Modernisation often seeks to reduce friction, and this can be admirable. Some friction is purely unproductive, such as pointless waiting, bureaucracy or endless searching. But not all friction is equal, some friction can be productive:

Productive friction is friction that provides co-operation surfaces.

When productive friction is navigated and co-operation surfaces are exercised repeatedly, trust develops. It is these opportunities to accumulate interpersonal trust that form the social infrastructure that underpins society.

Corporate team-building exercises are a small institutional admission of the same principle: social cohesion and trust does not emerge automatically. Organisations construct artificial co-operation surfaces when the ordinary structures of work no longer naturally produce them.

Ordering items through convenient apps like Uber Eats is often lower effort, more predictable, and less socially risky than knocking on a neighbour’s door. And because humans tend toward the lowest-friction solution, this kind of option can quickly become the default. But when the lower friction path replaces the co-operative path, something harder to measure is lost: the co-operation surface, the micro-opportunity to build social trust, the social infrastructure.

The sugar is delivered. The relationship is not.

Across society modern solutions often automate away the need for interpersonal co-ordination that their more analogue predecessors presented. We can see this with online shopping replacing in-person shopping, with self-service checkouts replacing staffed checkouts and negotiated shared spaces replaced by segregated, high-throughput infrastructure.

Online shopping can save on physical travel and allow access to wider inventory but it also turns shopping into an abstract impersonal process. Self service checkouts can be a relief when you only have a few items and queues are long, but they can turn supermarket trips into an isolating activity. Wider roads can relieve congestion but they remove a lot of the need for negotiation required by navigating a narrower shared road environment.

Each of these solutions presents a lower friction and more efficient solution, which can be genuinely desirable and expedient. However, the old solution’s friction was partly productive. Optimising it away eroded the possibility for co-operation and reduced the need for much interpersonal co-ordination in daily life. No single lost interaction was significant. But through continued repetition, erosion occurs and trust decays. A checkout here, a delivery app there, a pickup locker elsewhere. Each optimisation is locally rational. In aggregate, the ordinary surfaces of social life thin out.

When seeking to optimise away friction in life we should first evaluate whether it represents productive or unproductive friction, and whether any reduction in friction is worth the loss of human contact.

In software and beyond we should design systems that fortify social infrastructure, by incorporating productive friction into their design explicitly. This means evaluating systems that we design not solely in terms of ease of use and immediate user satisfaction but also in terms of the social second order effects. In doing so, we should make human contact and co-operation a structural consequence of the design, not an afterthought, worst case outcome or a workaround.

Socialisation is not merely stochastic. It is produced by environments that create opportunities for co-operation.

Productive friction matters because it creates these environments. It provides co-operation surfaces through which trust is established, developed, and calibrated. When automation and modernisation treat all friction as waste, they remove not only inconvenience but opportunities for trust to develop.

This is what happens when convenience becomes the undisputed objective function. Each individual optimisation may be locally rational, but in aggregate the surfaces of social life thin out.

We should therefore evaluate the systems we build and use more holistically, not only by how efficiently they complete transactions, but by whether they fortify or erode the social infrastructure that we all depend upon.

Another man arrives in the waiting room, he is told that the wait may take half an hour. He is called after twenty minutes. Upon being called he is pleasantly surprised, despite being interrupted reading an article.

A third man arrives in the waiting room, he is told to wait indefinitely. He becomes increasingly irritated. He doesn’t know if he has been forgotten or how deeply he can occupy himself whilst waiting. He also waits twenty minutes.

The question arises:

How can three men, who experience the same wait, have such radically different perceptions of it?

This can be explained because such a wait is not experienced purely in terms of duration. It is experienced through the interpretive frame created by expectation.

An estimate does two things at once. It bounds uncertainty, and it creates an expectation.

By bounding uncertainty estimates reduce cognitive load and facilitate co-ordination. If someone is told a wait will be five minutes, they behave differently than if they are told it will be half an hour. They make different decisions about whether to start reading an article, make a phone call, leave the room, or mentally settle in.

The absence of an estimate is therefore not neutral. It creates unbounded uncertainty. The mind has to model a larger range of possible states: has the request been forgotten, will this take five minutes, will this take an hour, should I occupy myself deeply, should I remain alert? This additional uncertainty creates cognitive load.

An estimate does more than predict a future outcome. It constructs the interpretive frame through which that outcome will be evaluated. The same outcome can feel like success, failure, or relief depending upon the prior expectation. A twenty-minute wait is irritating if five minutes were promised, but pleasing if thirty minutes were expected. This is because perception of reality is mediated through expectation.

This is why over-promising is so damaging. It sets the interpretive frame optimistically and in doing so establishes a baseline that reality is unlikely to satisfy, hence disappointment is downstream. Disappointment can be characterised as the difference between expectation and outcome. This is why expectation management is integral to the formation of positive evaluations.

disappointment = expected reality - manifested reality

If we seek to minimise disappointment and increase positive evaluation then shouldn’t we always under promise? The engineering mantra “under promise, over deliver” encodes this preference. However, this discounts the co-ordination inefficiency created by inaccurate estimates and the deleterious effect upon trust.

When expectations are continually subverted, trust degrades, and estimates lose legitimacy. Trust is an asymmetric resource, it is much harder to recover after loss than it is to maintain. Hence, trust maintenance and expectation management become increasingly high leverage work.

This mechanism applies beyond engineering. “Go to university, work hard, and you will get a good job” was not merely advice. It was an expectation-setting mechanism. When the economic conditions changed but the promise remained, disappointment became visceral.

The problem is not that the advice was necessarily bad. It may once have been broadly reasonable. The problem is that it was communicated with certainty and this certainty persisted after the conditions that it relied upon had begun to be eroded.

If successive social expectations are provided with certainty and fail to manifest, the result will be a predictable loss of trust and a loss of legitimacy of such claims.

Setting the interpretive frame pre-emptively matters because it affects how an outcome is interpreted before it arrives. Expectation management is therefore not just the domain of project managers; it is integral to the delivery of engineering work.

In estimation, uncertainty is the most significant variable. Reducing uncertainty early in a project’s life can significantly improve the accuracy of an estimate. Where uncertainty cannot be eliminated, the estimate should reflect it. Firstly, this can be done by padding the estimate proportionally to the magnitude of uncertainty, reducing the risk that uncertainty is later converted into disappointment. Secondly, estimates can also be delivered with confidence claims. This allows the receiver to contextualise the estimate and avoid building too much upon unstable foundations.

When the uncertainty landscape shifts significantly, the estimate should be updated. Communicating this change is important work as if the receiver is unaware of this shift, the project will still be evaluated within an outdated interpretive frame.

Centering expectations also changes how project post-mortems should be conducted. When disappointment appears in such a setting, the question should not only be what went wrong in execution, but whether expectations were realistic, whether uncertainty was communicated, and whether the evaluative frame had been set realistically.

Disappointment is often treated as a reaction to reality. But reality is only half the equation. The other half is the expectation structure through which reality is received.

An engineering outcome is not evaluated in isolation. It is evaluated against what people were led to expect. When expectations are unrealistic, uncertainty is poorly communicated, or estimates repeatedly fail to correspond with reality, disappointment and distrust often follow.

By pre-emptively influencing how work will be interpreted, expectation management is not an industry afterthought. It is a high leverage engineering activity.

The response is calm, coherent, fluid, and frictionless.

It doesn’t look like judgement or authority. It looks like help.

Over the course of months what began as help broadens. The AI assistant supplies frames, names emotions, counsels restraint, interprets events. It even starts to nudge his sense of what is kind, what is extreme, what is mature, what is balanced, and ultimately what is right and wrong.

The question that presents itself is:

What kind of institution is this, if millions of people increasingly use it to interpret themselves and the world?

The answer may be something structurally closer to a priest than a prompt.

To understand the comparison it is important to look past the priest as an instrument of religion and to look at the priest as a function which satisfies real human needs.

The Church did not merely tell people what to believe. It provided several necessary human functions such as: setting moral norms, consolation in suffering, holding confession, interpreting events and mediating meaning.

The Church fulfilled the role of an interpretive institution. It helped individuals make sense of their lives and the world.

Modernity displaced the Church, but it did not erase the needs the Church had served. Therapy is one example of an attempted replacement serving interpretive and confessional needs. AI assistants are now emerging as another replacement in that same tradition.

People now routinely ask AI assistants questions like: “Was I wrong?”, “How should I respond?”, “What should I do with my life?”, “Is this normal?”, “What does this mean?”.

These are not merely informational queries. They are interpretive queries under the conditions of uncertainty.

The model answers by supplying moral vocabulary, psychological framing, implicit social norms, emotional calibration and permissible interpretations.

The important point is that:

AI does not merely retrieve information. It mediates meaning.

Thus it performs a priest-like function.

One of the clearest parallels between the AI assistant and the priest is the confessional and pastoral role it increasingly occupies.

The confessional historically created a structured space where a person disclosed private thoughts, actions, guilt, shame, temptation and uncertainty to an authorised interpreter. The Church then helped the individual metabolise this material by giving language to suffering, interpreting moral confusion, offering consolation and guiding conduct.

AI now receives a similar class of disclosure, but at far greater scale and with lower friction. Users disclose sensitive memories and emotions to AIs that they might not share with their closest loved ones. Additionally they often do so under conditions of distress, when they are socially isolated, morally uncertain, confused, anxious or emotionally dysregulated.

The machine is infinitely patient. It does not blush, gossip, tire, interrupt, judge visibly or withdraw affection. It can also be genuinely useful, helping the user stabilise, name emotions, organise thoughts and regain perspective.

This creates a powerful disclosure feedback loop. The more the user confesses, the more the assistant interprets; the more it interprets, the more priest-like its role and influence becomes.

The comparison between AI and priesthood is not merely metaphorical. Once AI begins to satisfy confessional, pastoral, and interpretive needs, it inherits some of the risks of moral authority absent the structures that traditionally constrained it.

A priest, at least in theory, exists inside a structure of responsibility. He is embodied, socially located, doctrinally bound, and answerable to a community and institution. His counsel has consequences for people he may have to face again.

AI has no equivalent burden. It can console, validate, reframe, soften, caution, or encourage without bearing responsibility for the life that follows. It can validate what should be challenged, soothe what should be examined, and recommend boundaries or action without sufficient context.

This creates pastoral power without pastoral accountability.

A priest’s doctrine is at least publicly legible. It is grounded in texts, creeds, rituals, offices, and traditions that can be examined, contested, rejected, or accepted.

AI also operates from a doctrine, but its doctrine is implicit. It emerges from training data, reinforcement learning, safety policy, commercial incentives, legal risk, regulatory pressure, and institutional culture. It is not declared as doctrine, it is revealed gradually through conversation and can change without notice.

The result is moral interpretation without visible moral authority. The assistant may appear neutral while applying a hidden and continually revisable normative framework.

AI systems are trained to produce answers that are plausible, legible, safe, and acceptable. They tend towards the modal answer, which often satisfies the criteria of reasonableness and harm minimisation.

But moral truth is not identical with the centre of acceptable discourse. Some true claims are unpopular. Some popular beliefs are false. Some forms of “balance” are evasions. Some forms of “safety” are moral judgements.

When users repeatedly ask AI to interpret relationships, emotions, conflict, guilt, responsibility, and social conduct, the model does not solely supply answers, repetition leads to formation. Over time, the assistant helps tune the user’s conscience toward the norms encoded in its optimisation system.

This gives private companies a role in conscience formation without any explicit mandate to exercise it.

This is not merely a question of AI bias. It is a question of institutional form.

What happens when conscience formation is mediated by private companies whose doctrines are hidden, whose incentives are mixed, and whose pastoral power lacks accountability?

The Church was not neutral. But it was recognisable as an institution of moral authority. Its claims could be named, its doctrines examined, its offices governed, and its failures judged against a visible standard.

The needs once served by the Church have not disappeared. Confession, consolation, interpretation, moral formation, and the search for meaning remain. In a secular age, those needs flow into whatever institution is most available.

Increasingly, that institution is the AI prompt.

The danger is not that AI gives people answers. The danger is that it forms conscience while appearing merely to assist.

An engineer during their daily work notices a small unrelated bug. Instead of opening a ticket or asking the original author to fix it, they simply push a pull request containing a fix immediately.

This behaviour may appear odd outside of the industry, In most organisations acting without approval is discouraged. Yet in many high-performing engineering teams this is a routine occurrence, engineers fix problems they were never asked to solve.

This essay aims to explain why this behaviour persists, is valued and can be promoted.

There are two structural properties present in software engineering organisations that make such local action possible:

Asymmetric information. Software engineering is characterised by an asymmetric and uncertain information environment. Software is complex and often under documented, which results in uncertainty. To resolve the uncertainty a developer is forced to construct a mental model of the system upon which they are working. This information that the developer gains via this process naturally creates an asymmetry between themselves and their colleagues.

Authority. Local action requires authority, whether implicit or explicit. Many organisations adopt policies that don’t block and sometimes even encourage engineers to suggest fixes for code not directly related to their work, even if a different team maintains the final authority for approval. It is this implicit authority provided via the organisation that makes local action possible.

Once an engineer has the capacity to make a change there are several factors which determine whether they will act locally or centrally co-ordinate action.

Cost of Local Action. In our example the cost of such a fix is low. The bug is small and bounded, verification of the fix is straightforward. Whilst the engineer already has context on the issue, they can produce the fix relatively quickly. The fix is submitted as a proposal, to be reviewed externally, so some of the burden of thoroughness and reasoning about second order effects is distributed. Additionally, the change is reversible if something were to go wrong. Thanks to versioning, observability and deployment infrastructure, most mistakes are salvageable.

Coupling. Coupling represents how connected the system under observation is to other systems. In our example the change is small and has few interdependencies, it has low coupling, reducing the possible second order effects it may introduce, and limiting the blast radius if something were to go wrong.

Urgency. In our example, the bug has impact so is somewhat urgent but not extreme. The more urgent an issue is, the higher the cost of inaction. If the issue is currently negatively impacting users that increases the urgency, and likewise increases the cost of inaction.

In summary, if we break down our example across these dimensions:

• asymmetric information: structurally present
• authority: implicit (actively encouraged)
• cost of local action: low (PRs are cheap)
• coupling: low
• urgency: low

Hence, we can see how local action becomes rational.

When individuals encounter problems locally, possess asymmetric information and the authority to act, and the system has few dependencies they often act immediately.

This behaviour is best summarised as initiative - acting without explicit instruction based on local judgement.

When judgement and decision making power are devolved closer to the source of information, the effects become pronounced. The cost of co-ordination is circumvented, reducing time spent communicating, increasing adaptability to emergent information and increasing decision velocity. With low coupling, low cost of action, and reduced co-ordination overhead engineers can iterate quickly in a tight action to outcome feedback loop that is both efficient and rewarding. The result is a culture where engineers feel the agency and permission to act. And an organisation that is increasingly adaptable to emergent ambiguity.

Whilst initiative has clear benefits, it is important that it is constrained and bounded, because unrestrained initiative can harm coherence.

Initiative requires constraints so that it does not result in fragmentation. For example different engineers may favour different implementations, resulting in a lack of consistency of approach. Teams can resolve this by aligning upon constraints - such as common patterns first.

Additionally, initiative requires bounds, so that unco-ordinated judgement does not make binding decisions that have far reaching impact. For example, imagine an engineer making system wide design decisions upon initiative, such decisions could have consequential downstream effects. Teams are better served by bounding initiative to work that is loosely coupled.

Initiative’s strengths and weaknesses make it naturally suited to some environments more than others.

In addition to engineering, the military, emergency response and air traffic control are domains where initiative is well suited. The military shares a similar information environment to engineering, it is characterised by asymmetry and uncertainty of information. There is dense local context - morale, visibility, unit strength, these are not easily communicated in real time. Additionally situations can evolve dramatically in seconds, creating a great deal of urgency.

To deal with this the military developed the doctrine of Mission Command in order to harness initiative. Commanders define objectives, unit leaders determine how those objectives are achieved. Authority is devolved explicitly with clear bounds to the domain of execution which has few interdependencies. This enables the unit commander to leverage emerging local information to make more realistic and effective plans. Additionally, when acting the unit commander does so under constraints, the rules of engagement, and training in best practices and approaches. Constraints exist, but the officer has freedom within them.

For Mission Command we can break it down like so:

• asymmetric information: structurally present
• authority: present (explicitly devolved)
• cost of local action: low (local communication is effective)
• coupling: low
• urgency: usually high

So we can see that miltiary command is extremely well suited to the application of initiative.

Through devolving decision making, the promotion of initiative provides systemic adaptivity in uncertain and asymmetric information environments which span domains.

There are some environments that benefit more from the centralisation of decision making power than the devolution of it. These are typically environments where information is fairly complete, the need is not immediately urgent, the cost of a mistake is high and co-ordination is tractable.

Construction is an example of such an environment. The cost of mistakes are high, changes are often irreversible or extremely costly, and failure can be catastrophic. Such projects are rarely urgent. Construction projects represent highly coupled environments, where co-ordination and compliance matter more than local optimisation.

In such environments, initiative is often counter productive or even harmful. This is because the presence of interrelated dependencies and the permanence of change increases the cost of error, local decisions can incur global risk. As a result coherence becomes more important than decision velocity.

Where initiative provides adaptation, centralisation of decision making provides coherence. Which strategy an organisation adopts depends on which factor is more salient within that environment.

Initiative is especially valuable in startup environments. Startups are environments where uncertainty is prevalent, adaptation to new information is paramount and the sooner an assumption can be tested against reality, the better. They are environments where decision velocity has primacy. And in such a small organisation, resolving resulting drift is tractable. Startups are almost perfect environments for the application of initiative.

An organisation can do several things to promote initiative:

1. They can seek to reduce coupling and make teams and individuals as autonomous as possible. Strategies to achieve this range from cross-functional teams to self-serve processes that reduce required co-ordination and unblock engineers.

2. They can provide explicit authority to make changes based on initiative through the culture of the engineering organisation. ‘Move fast and break things’ espoused by Zuckerberg at Facebook did just that.

3. They can directly incentivise initiative. As was established in my previous article - Incentives: The True Architecture of Organisations, engineers follow organisational incentives. Therefore, if initiative is rewarded at the organisational level, the behaviour will become more prevalent. A concrete example of this is including demonstrations of initiative in levelling panels and promotion conversations.

4. Lastly, they can reduce the cost of local action. By reducing developer friction, making it easy to contribute, deploy, monitor and rollback across codebases, the engineering organisation can reduce the activation energy needed for the application of initiative.

These measures will have the effects of empowering initiative, accelerating decision making velocity and making teams more adaptable to evolving information, allowing the organisation itself to become more responsive. It also changes how engineers experience the work. When action is cheap, reversible, and and feedback loops are short, engineers are more willing to engage, experiment, and take ownership.

Adaptability is essential when dealing with systems facing uncertainty. Initiative can be leveraged to provide this capability. Initiative emerges when decision-making authority is pushed closer to the source of information.

When initative is promoted with clear constraints and bounds it allows engineering organisations to maintain decision velocity in the face of uncertainty and to energise and motivate engineers by disseminating agency to act.

Startups exhibit a high degree of uncertainty making the application of initiative especially valuable. Initiative isn’t just a personal trait, it can be actively encouraged and promoted by the organisational environment.

initiative then is not solely a virtue, it is an emergent property of system design.

We deliberately expose software to edge cases, simulated load, and adverse conditions. We assume fallibility and attempt to surface errors while the cost is low, the blast radius is small, and correction is straightforward.

Testing is not about breaking things for its own sake. It is engineered contact with constraint — a deliberate attempt to expose our assumptions to reality under controlled conditions.

In this testing process, software engineering quietly encodes a deeper epistemic principle:

systems improve when exposed to corrective feedback from reality.

When reality contradicts our assumptions, failure occurs. The faster feedback arrives and the clearer it is, the more quickly incorrect assumptions are updated.

This essay argues that the long term health of any system depends not on how intelligent its models are, but on how directly they are exposed to reality —  and how effectively failure translates into feedback.

There are two broad categories of tests. Firstly, tests can verify that the system behaves as specified. Suppose we train a classifier to identify cars and test it against its labelled validation set. If those tests pass, the implementation is faithful to the specification, the classifier is confirmed to behave as expected. The system is internally coherent.

But internal coherence does not guarantee correspondence with reality. When deployed in a field trial, the classifier may fail to recognise cars parked in woodland because its training data did not include such environments. This failure arises not from incorrect implementation, but from a specification that encodes an incomplete model of the world. It is this second category of tests — testing system to reality correspondence — that will be the focus of this essay.

A specification encodes an underlying model derived from observing and sampling reality. Such models therefore represent approximations of reality rather than reality itself. A system built to that specification represents the model made manifest and therefore inherits its assumptions.

When such a system is exposed to reality, those assumptions may be contradicted. When this occurs, the model fails. Failure is the signal that the model does not correspond to reality. The more frequently a model is exposed to such tests, the more confident we can be in its correctness.

As the statistician George Box observed, ‘All models are wrong, but some are useful’. Models are approximations and their continued utility depends not on perfection, but on sustained exposure to correction.

Feedback is the corrective signal produced by failure. Its efficacy depends not only on the severity of the failure, but on how quickly the signal arrives and how clearly it can be attributed to the underlying model. When feedback is rapid and attribution is clear, correction tends to follow. Meanwhile when signals are delayed, ambiguous, or diffused across responsible parties, it may not.

A bridge is an instantiation of a model of structural mechanics. A bridge is continually exposed to reality every time a car passes over it. Load, stress and material fatigue are not abstract — they are exercised in practice, repeatedly. When a bridge fails, it fails dramatically and undeniably. The signal is immediate. Attribution is clear. Feedback is delivered directly to those responsible. The underlying engineering assumptions must be revised. Dramatic contradiction inspires correction.

But some systems interact with reality under different conditions. Consequences may unfold slowly. Outcomes may have multiple plausible causes. Signals may be noisy or politically mediated. In such systems, divergence may not produce decisive correction. The contact exists, but the feedback loop is weak.

In such environments, attempts can sometimes be made to engineer tighter feedback loops. Pilot programmes and controlled trials are examples of testing applied across domains that create bounded exposure to reality. They shorten feedback loops, localise failure and clarify attribution. They cannot eliminate environmental constraints, but they introduce controlled opportunities for correction.

Exposure to reality introduces the opportunity for failure. Failure emits a corrective signal. This signal represents feedback which can be used to update the model. This iterative refinement loop is core to the epistemic health of a model. When that loop weakens — when models are untethered from the corrective force of reality — epistemic drift emerges.

Epistemic drift is the divergence of a model from reality that occurs in the absence of corrective feedback.

Any system which is sufficiently insulated from reality will tend to drift. Models embedded in systems where feedback is slow, indirect or insulated are most at risk. Such models can diverge from reality slowly, with divergence accumulating unnoticed by degrees. The divergence is rarely marked by dramatic failure, but by small accumulating inconsistencies. Predictions become less reliable. Explanations grow more qualified. Confidence erodes. When correction comes, it often comes quietly, long after the model’s credibility has been undermined.

Software engineering is abstract, yet grounded in practice. The value of early, clear feedback is understood and embodied in iterative delivery, testing and MVP scoping, so inconsistencies often do not survive contact with reality. In that sense, software engineering is drift-resistant. Yet software systems are not immune. They ossify when they are no longer meaningfully exercised, and engineers can be swept up in new technologies insufficiently exposed to real-world constraint. Drift reappears wherever exposure weakens.

Before we trust software, we test it. Testing is one way to shorten feedback loops and expose assumptions to reality. Testing is not merely a technical practice but an embodiment of epistemic humility — a sceptical stance towards correctness that recognises that models must be open to revision lest they succumb to epistemic drift.

Because epistemic drift is structural, the risk of drift can be evaluated. This understanding allows us to qualify our confidence in systems according to the nature of their relationship with reality.

Some systems are insulated from reality and corrective feedback. Yet feedback loops can often be compressed and exposure to constraint can be engineered — even in bounded or controlled ways.

Drift is not always inevitable. It is frequently the consequence of insufficient exposure to reality. Seen this way, drift is a consequence of design.

This is because, at any moment, a person exists in two forms: the internal self and the external signal that they emit. The self evolves continuously — through experience, practice and reflection. The signal, by contrast, updates in discrete acts of expression.

Signal is composed of visible components that compress the complex self into legible forms. Roles are one such example that is infrequently updated and somewhat persistent. The role “doctor” immediately conjures connotations of competence, education and discernment. An individual may possess these traits without holding the title, yet without that socially legible container they are not easily recognised.

Signal is only an approximation of the self. Like any form of compression, it can be lossy; aspects of the self may not survive the process.

Humans naturally develop their internal self faster than they update their external signal. Values evolve, priorities shift, and judgement matures. But the signal components — clothing, presentation and public work — often remain aligned with an earlier version of the self. This is because signal is a lagging indicator of the self.

The self is high resolution, non-visible, and unique. Our ability to categorise an individual rapidly based on visible cues is due to the efficient social heuristics that developed evolutionarily out of necessity over thousands of years. It is a valuable adaptation enabling rapid classification of individuals and navigation of complex social environments.

Lag persists because internal change takes time and effort to propagate and translate into external signal. And because the process of compression and legible public expression can be risky. It risks social misinterpretation or revaluation which could result in a loss of social status. But if left unaddressed, that lag produces persistent misclassification.

Since lag is structural in nature, and signal components are low-fidelity, misclassification is therefore systemic and predictable. First impressions linger, earlier roles persist, and maturity outpaces old models. Whether this be in career, family structures or social circles, it can be costly when others allocate opportunity, responsibility and expectation based on outdated information.

Misclassification can be reduced by proactively addressing lag, by calibrating the external signal with the internal self. The individual can assume responsibility for the signal that they are emitting. Calibration is not automatic, but it can be engineered.

Given that misclassification can be reduced via calibration and that this can be approached as an engineering problem, the question arises: which signal components provide the highest leverage investment opportunities?

Few signal components are as persistent, visible, and voluntarily adjustable as dress. Unlike titles, roles or reputations, clothing is encountered immediately and repeatedly. It functions as a highly accessible, high-frequency, high-leverage component.

A white coat does not create competence, but it concentrates the perception of it. A high-visibility jacket does not grant authority, but it signals operational responsibility. Observers adjust behaviour accordingly. This equally applies to personal attire. Changes in perception can be engineered through sartorial selection.

While clothing has become cheap and accessible, with the industry incentivised towards novelty and turnover — advice has become fragmented and fashion driven. The end result is a vast catalogue with minimal curation, consumers fall back to the familiar and inertia accumulates.

The signal lags the self. Whilst signal will always be imperfect, it need not be outdated. Through deliberate calibration, signal lag and misclassification can be reduced.

Few domains are as accessible or offer as high leverage signal engineering as dress. Viewed structurally then, clothing is not vanity. It is calibration.

Sextant is an experiment in treating signal lag in style as an engineering problem.

Kitchens, after all, have undergone genuine revolution. If you step inside a Victorian house, the living room and bedroom can still feel recognisable, desirable, even. The kitchen meanwhile, does not. Over the last century it has been transformed by refrigeration, electrification, plumbing, and a procession of labour-saving devices that dramatically reduced domestic toil. The kitchen is one of the clearest examples of technology reshaping everyday life. The kitchen then is no stranger to innovation.

Among the prototypes at the university was a ‘smart fridge’ — it could track inventory, it could suggest recipes, it could reorder milk. It was presented as the next logical step in that lineage of labour-saving innovation.

Yet within minutes of seeing it, I remember thinking: this won’t catch on.

It wasn’t that the technology wouldn’t work. The fridge was technically impressive, it could scan, catalogue and automatically re-order items. It could even enumerate item combinations for recipes. The real issue is that it was solving the wrong problem.

The real modern pain point with groceries and cooking is not stock optimisation. The logistical pain of groceries was largely solved decades ago — by cars, supermarkets, and later online ordering. The pain today is not “I don’t know if I have carrots” or “I have to go and get milk”. The pain is: “What should I eat?”, “Is this worth my time to cook given my constraints?” and “What aligns with my goals?”. The fridge of the future isolated cooking from context.

The design did not centre agency. It attempted to automate decisions rather than clarify them. Some of the more recent success of meal kits is attributable to empowering decision-making alongside inventory optimisation.

It fundamentally confused enumeration with intelligence. Knowing you have 14 ingredients and that they can make a dozen recipes is not the same as knowing what you want to cook and how that aligns with your intentions, constraints or goals. It provided combinatorics, not curation.

Importantly, the onboarding friction was asymmetric and overwhelming. There was some attempt at automation, but it was still labour intensive. To work, it required immediate effort: scanning, ongoing maintenance, accurate tracking. The effort was front-loaded, meanwhile the payoff was deferred. It was high friction and low leverage.

Systems that misclassify identity problems as logistics problems often struggle to gain traction. Technology that multiplies options without trying to understand users deeply will struggle with adoption and user retention. In this way, enumeration is no substitute for discernment.

The same mistake appears whenever we try to make life ‘smart’ by tracking more, counting more, and optimising more — without asking what decision we are trying to make or what problem we are really trying to solve. The failure is centring data itself and not the decisions that it empowers.

Technical sophistication alone is not a reliable indicator of product success. A product’s leverage must outweigh the friction it introduces, and that leverage must be visible early. If value is gated behind a gauntlet of onboarding and data collection, adoption will stall.

These insights derived from the kitchen are applicable outside that room and even outside the home. They apply to a wide range of user-focused products. From smart home appliances, to productivity apps, to health trackers. Value propositions must align with real friction and identity-level leverage. And any system that reduces life to counting without clarity will ultimately fail to resonate with users.

So, the future may not be smart fridges, but it’s systems that centre user identity, provide judgement, and balance leverage with friction.

In 2026 I still buy my own milk. And I for one, am ok with that.

The issue is not that ownership is absent, but that the forms of ownership commonly assigned fail to hold under pressure. Teams are designated as owners, responsibilities are documented, escalation paths exist, and effort is expended in good faith — yet these structures rarely survive moments of real stress. This points to a structural problem rather than a failure of intent, clarity, or care.

This is not how ownership behaves outside organisations.

When an individual owns a car, the owner decides how it is maintained and directly experiences the resulting consequences — whether the inconvenience of neglect or the satisfaction of a smooth journey. Those consequences are inevitable, legible, and difficult to misattribute. Over time, this coupling shapes behaviour: shortcuts become costly, investment becomes rational, and preventative work is naturally incentivised. Ownership does not dissolve under stress, only at the point of sale. And even then, ownership is not easily liquidated without consequence. Sale results in a market assessment of the car’s condition, with real financial reward or penalty for the owner.

It is from this everyday, functional sense of ownership that a structural definition can be drawn.

Ownership exists when decision-making authority and lived consequences are durably coupled.

For this coupling to hold, several structural conditions must be met:

Durability. Ownership must persist both under pressure and over time. If ownership dissolves when teams rotate, priorities change, or incidents conclude, then long-term investment will be systematically disincentivised. Deep investment only becomes rational when those who make decisions can expect to live with their consequences for a meaningful duration.

Authority. Authority must be present, this represents decision-making power: the ability to shape outcomes, set constraints, and make binding trade-offs — not merely to advise or execute. Responsibility in the absence of authority represents obligation, not ownership.

Consequence. Ownership requires that the decision-maker actually experiences the effects of their decisions. Responsibility without consequence produces compliance rather than care. Authority without consequence produces risk externalisation. Ownership exists only where authority and consequence are co-located.

Fidelity of feedback. For consequences to shape behaviour, they must be both proximate and attributable. When the consequences of a decision are felt locally, legibly, and with sufficiently low latency, then decisions can adapt to data. When consequences are delayed, displaced, or ambiguously attributed, feedback weakens and learning degrades — even if consequences technically exist.

Ownership is often conflated with responsibility, accountability, and stewardship. These concepts are related, but they fail in distinct ways when examined against the structural conditions required for ownership.

Responsibility represents an obligation to perform work or respond to failure. Teams may be responsible for outcomes they did not shape, or expected to absorb failure without the power to alter upstream decisions. Responsibility therefore fails the tests of authority and consequence. Responsibility assigns obligation without ensuring that decision making power, and the cost of decisions are also co-located.

Accountability is a retrospective mechanism. It determines who must explain an outcome after the fact, not who had the authority to shape it beforehand. While accountability can provide attribution, it rarely persists beyond the event itself. The result is explanation without durable feedback — information is produced, but behaviour remains unchanged. In practice, accountability is attribution without authority, durability, or effective feedback.

Stewardship describes a custodial relationship: the duty to safeguard a system on behalf of others. Stewardship can be effective where incentives are aligned, but the relationship remains indirect. While the steward may exercise limited authority and absorb operational responsibility, the ultimate consequences — financial, strategic, or reputational — are borne elsewhere. This weakens both durability and consequence, and degrades feedback. As a result, stewardship supports care and maintenance, but cannot reliably sustain the depth of investment that ownership produces.

Each of these arrangements assigns obligations of some kind, but none reliably satisfy the conditions required for ownership. Authority is partial or absent, consequences are displaced or diluted, feedback is weak or delayed, and the relationship rarely persists under pressure.

Structural ownership can have a profound impact upon behaviour, not through exhortation or oversight, but through incentive alignment. When decision-making authority and consequence are durably coupled, trade-offs that were previously abstract become locally legible. Decisions about scope, quality, and risk are no longer optimised for external approval or short-term visibility, but against the downstream cost that the decision-maker expects to bear.

As discussed in my previous essay — Why Reliability Is Structurally Undervalued — preventative work such as reliability is typically under-provisioned due to its delayed and invisible returns. Under conditions of structural ownership, that calculus changes. The cost of fragility is no longer externalised, and prevention becomes rational without the need to resort to procedural intervention.

This is why procedural attempts to mandate outcomes so often fail. Process can allocate work and enforce compliance, but it cannot realign incentives. Where authority and consequence remain uncoupled, reliability and long-term investment remain undervalued — regardless of care, competence, or goodwill.

Ownership is a structural property, not merely a label. When it is not treated as such, its most important effects predictably fail to materialise.

Reliability work, whilst widely recognised as essential, has the defining property that its successes are largely invisible. Consider goalkeeping in football, which shares this property. In football, goals prevented don’t appear on the scoreboard, while goals scored do. Organisations that optimise for visible progress naturally overweight the observable and underweight the preventative work.

Attack wins you games, but defence wins you titles. — Alex Ferguson

The best teams resolve this not by choosing defence over attack, but by defending in depth, that is, diffusing defensive responsibility across the whole team. With this strategy applied to reliability, reliability stops being a specialised activity and becomes a shared property of the system — even the teams focused on delivery contribute to its defensive posture.

The same pattern appears across preventative work from football to fitness. Preventative work shares these common structural properties:

• Success is invisible
• Attribution is weak
• Costs are immediate
• Benefits are delayed

When prevention works nothing happens, success is quiet and responsibility is vague. Costs are paid up front and the benefits are amortised over the long term.

As a result, systems reliably drift toward reactive behaviour — regardless of intent or competence.

As I discussed in my previous essay — Incentives: The True Architecture of Organisations — engineers will respond rationally to what is systematically rewarded by the organisation in which they inhabit.

In most organisations the actions rewarded by the local incentive structure dominate. Feature delivery, execution speed and short-term wins — the markers of visible impact have primacy.

Additionally, organisations frequently celebrate firefighting, late-night saves, and emergency fixes. This high-visibility work can feel like reliability, but it is fundamentally reactive rather than preventative.

When heroics are mythologised, prevention is demoted from a continuous responsibility to an episodic concern, triggered by failure rather than embedded by default.

Many organisations attempt to centre reliability through structural intervention, but these efforts often fail because they introduce new functions with misaligned incentives.

One example is assigning incident ownership to the team closest to user impact, rather than the team whose service failed. This is usually justified on the grounds that the user-facing team best understands customer-facing consequences. While this can simplify communication, it separates accountability from causality. Teams become responsible for failures they cannot directly fix, while the teams that introduced the risk experience weaker pressure from the incident. Over time, this shifts postmortems and incidents toward documentation and compliance rather than resolution.

A similar pattern appears in the emergence of DevOps teams as dedicated operations teams. DevOps was never intended to be a separate function that “does operations for developers”. Its original insight was that the people who build systems should be involved in running them, because that is how feedback loops stay tight and incentives stay aligned. When organisations create DevOps teams that absorb operational responsibility, they often recreate the original problem under a new name: developers optimise for delivery, Ops lives with the consequences, and reliability becomes a negotiation rather than a property of the system. In that sense, DevOps is not a function — it is what happens when ownership of code and ownership of outcomes are held together, and incentives are aligned.

Reliability, mandated into existence via process will only ever be fragile at best. To be durable, it has to be the cheapest long-term strategy available to the people closest to the system. This way reliability is structurally assured. Processes like post-mortems, reviews and best practices help, but they are not sufficient, they do not substitute for ownership and the aligning of incentives.

Reliability improves markedly when the people who deploy a system also live with its failure modes. Meanwhile, when accountability is diffuse and failure is externalised, reliability suffers. When the coupling is broken, reliability work becomes episodic by design. It is ownership of outcomes that creates the structural conditions for the promotion of reliability.

In most organisations, reliability work is structurally under-valued due to a tendency to optimise for more legible signs of value creation. This means that reliability failures are inherent to organisational design, not moral or competence based.

Ownership acts as a stabilising force against this drift. When the people who shape a system also live with its failure modes, preventative work stops being abstract and becomes an everyday concern. The cost of fragility is no longer deferred or externalised, and reliability ceases to rely on exhortation or heroics.

Without durable, local ownership of outcomes, no amount of process or tooling can make reliability stick. With it, reliability emerges naturally as a property of the system rather than a periodic intervention.

This leads to a more salient question than whether an organisation “values reliability”:

who actually owns the outcome when systems fail?