Two Paths Through the First Gate

Mostafa Dhouib·9 min read

Two Paths Through the First Gate

The short answer. Some projects turn on a fact nobody knows yet. Whether a controller will talk to you. Whether an undocumented protocol can be decoded. Whether a data source will be granted. The usual response is to assume the favourable answer and start building, which means an unfavourable answer strands everything spent so far. The alternative is to design the engagement so both answers lead to a working product. One monitoring project did not know whether the machine controller could be read at all, so it was structured to decode the controller directly if the answer was yes and to instrument the surrounding physical signals if the answer was no. The gate resolved the unknown and neither outcome wasted the capital.

Every project has unknowns. Most of them are tolerable, in the sense that being wrong costs a bit of rework.

A small number are different. They are the facts on which the whole approach depends, where being wrong does not mean rework. It means the plan has no path forward at all, and the money already spent bought nothing.

The unknowns that behave this way

They share a shape. The answer is binary, it is external to you, and it cannot be determined by analysis.

Access to a system you do not control. A controller with an undocumented protocol. A device that may or may not expose a readable port. A vendor system whose API may or may not include the field you need.

Permission from a party who has not yet decided. A data feed that requires approval from someone outside the project. An integration that depends on a partner agreeing to something they have not been asked.

Behaviour of a closed system under conditions nobody has tried. Whether a device tolerates being polled at the rate you need. Whether an undocumented format is stable across firmware versions.

In each case you can research, estimate and form a view, and you cannot know until you try. Analysis does not resolve them, which is exactly what distinguishes them from ordinary design risk.

What assuming the favourable answer costs

The standard approach is to assume it works out, because the project is only attractive on that assumption and nobody wants to be the person who raised it.

So a dashboard gets built, an ingestion pipeline gets built, a data model gets built, all of them shaped around telemetry that has not yet been proven obtainable. The read is attempted somewhere in the middle, after most of the budget is committed.

If the answer is no, the position is bad in a particular way. There is a substantial amount of working software with nothing to feed it. The client has paid for most of a system and owns none of a system. And the conversation about what to do next starts from a sunk cost rather than from a decision, which is the worst possible starting point because every option now looks like an admission.

Designing for either outcome

The monitoring project is the clearest example of the alternative.

The question was whether the machine controller could be read at all. It was an older unit, the protocol was not publicly documented, and the vendor was not going to help. Nobody could say in advance whether a usable data stream could be obtained from it. The project's whole value proposition depended on getting machine state out.

Rather than assuming it could be read, the engagement was shaped around the fact that it might not be.

If the controller could be read, the work was to decode the protocol and pull machine state directly. Richer data, more precise, closer to the source.

If the controller could not be read, the work was to instrument the physical signals around it instead. Current draw on the motor circuit. Vibration. Temperature. Cycle timing from a sensor watching the moving part. Coarser data, inferred rather than reported, and sufficient to answer the questions the project existed to answer, which were whether the machine was running, how hard, and whether its behaviour was changing.

The crucial property is that everything downstream of acquisition was identical in both cases. The same ingestion, the same storage, the same alerting, the same dashboard. The two paths differed only in the acquisition layer, which means the gate decided one component rather than the architecture.

How to actually structure it

Four things make this work in practice rather than as a nice idea.

Put the unknown in the smallest, first, separately priced milestone. The gate milestone does one thing: resolve the fact. It is small enough that the client can absorb its cost as the price of knowing, and it is first, so nothing has been built on the assumption.

Specify both paths before the gate runs, including their cost. This is the part teams skip, and skipping it destroys the whole structure. If the fallback is only sketched, then a no answer turns into a renegotiation under pressure, which is the situation the design was meant to prevent. Both paths need a scope and a number before anyone learns the answer.

Draw the architecture so the branch is contained. Identify the layer where the two paths differ and define its interface. The acquisition layer produced the same shape of reading in both cases, so the rest of the system did not know or care which path had been taken. If the branch propagates past one layer, you are designing two systems rather than one system with two front ends.

Say what the fallback does not give you. The physical instrumentation path produced inferred state rather than reported state. It could tell you the machine was drawing current consistent with a cutting operation. It could not tell you which program step it was on. The client needs that difference before the gate, so a no answer is a known reduced outcome rather than a disappointment.

Why clients accept this

It sounds like a confession of uncertainty, and the reaction is usually the opposite.

A supplier who presents one plan that depends on an unverified fact is either unaware of the risk or has decided not to mention it. A supplier who names the fact, says plainly that nobody can know it yet, and shows two costed routes to a working system has demonstrated something that no amount of reassurance demonstrates.

It also changes what the first payment buys. Instead of buying the start of a build, it buys the answer to the question that determines the build. That is a smaller purchase and a much easier one.

The honest limit

This structure costs design effort before anyone has committed to anything, and it is not always worth spending.

It applies to genuinely binary, externally determined unknowns. It does not apply to ordinary design risk, where the answer is a matter of degree and the usual response of building, measuring and adjusting is correct. Applying it everywhere produces an engagement made entirely of gates, which is unsellable and also exhausting.

There is a harder limit. Sometimes the fallback is not good enough. If the project only has value with precise machine state, then inferred state is not a second path, it is a different and smaller project. The right thing then is to say so before the gate rather than to present a fallback that technically works and does not meet the need. A fallback that nobody would have commissioned on its own is not a fallback.

And the gate itself can be inconclusive. A controller that responds intermittently, or a format that decodes for some messages and not others, resolves to maybe. Deciding in advance what counts as a yes, in terms specific enough to check on the day, is as important as designing the two paths.

FAQ

Which project unknowns need this treatment? The ones that are binary, externally determined, and not resolvable by analysis. Whether an undocumented controller can be read, whether a party outside the project will grant a data feed, whether a closed device tolerates the polling rate you need. Ordinary design risk, where the answer is a matter of degree, should be handled by building and measuring instead.

What goes wrong if you assume the favourable answer? You build the ingestion, storage and interface around data that has not been proven obtainable, and attempt the acquisition after most of the budget is committed. A negative answer then leaves working software with nothing to feed it, and the conversation about what to do next starts from a sunk cost rather than from a decision.

What does a two-path gate look like concretely? One monitoring project did not know whether the machine controller could be read at all. It was structured to decode the protocol and pull machine state directly if the answer was yes, and to instrument the surrounding physical signals such as current draw, vibration, temperature and cycle timing if the answer was no. Both paths led to a working product.

How do you keep the branch from spreading through the design? By identifying the single layer where the paths differ and defining its interface up front. In the monitoring case the acquisition layer produced the same shape of reading either way, so ingestion, storage, alerting and the dashboard were identical in both outcomes. If the branch propagates beyond one layer, you are building two systems rather than one with two front ends.

What has to be agreed before the gate runs? Both paths, scoped and costed, and an explicit statement of what the fallback does not provide. Physical instrumentation gives inferred state rather than reported state, so it can show current draw consistent with an operation without identifying the program step. If the fallback is only sketched, a negative answer becomes a renegotiation under pressure, which is what the structure exists to avoid.

When does this approach not work? When the fallback is not genuinely acceptable. If the project only has value with precise machine state, inferred state is a smaller and different project rather than a second path, and that should be said before the gate. The gate can also return an ambiguous answer, so what counts as a yes has to be defined specifically enough to check on the day.