The intention
has to survive
Lusser’s Law explains why good parts can still make a fragile whole.
Five independent, necessary steps at 95% each yield about 77.4% overall success in a simple model without recovery. These are illustrative probabilities, not measured service performance.
The problem lives between “works” and “happens”
A calendar works. A transportation service works. A learning service works. A research service works. Yet the meeting you meant to prepare for can still arrive before the preparation does.
In Where Intention Becomes Real, I argued that the apparent superpower of a future bundle comes from carrying a person’s purpose across services. A conversation changes a calendar. The calendar coordinates a ride. The journey becomes an opportunity to learn. The learning prepares a meeting whose research is already organized.
There is a hard condition inside that promise. The intention has to survive the whole route.
A principle from reliability engineering helps explain why this is harder than collecting good applications—and why a dependable environment could be worth much more than the list of its components.
Lusser’s Law, with its assumptions attached
Lusser’s Law describes the product rule for the reliability of a series system. When every component is necessary and their failures are statistically independent, the probability that the whole system works is the product of the individual reliabilities. The NIST engineering handbook’s series model sets out these conditions and the corresponding formula.
R =r₁ × r₂ × … × rₙ
For five required steps, each with a 95% chance of success, the result is 0.95 multiplied by itself five times: approximately 77.4%. Ten such steps yield about 59.9%.
| Required steps | Each step succeeds | All succeed |
|---|---|---|
| 1 | 95% | 95.0% |
| 5 | 95% | 77.4% |
| 10 | 95% | 59.9% |
| 20 | 95% | 35.8% |
Good individual performance does not guarantee a good result across the sequence. A series system can be less reliable than its least reliable component.
What this does and does not establish. These are calculations under a specified model, not estimates of how often anyone’s day fails. An optional lesson is not a required component. A disruption repaired before the deadline need not count as failure. The success criterion, time window, and dependencies must be defined before multiplying probabilities.
The handoffs are part of the system
A useful thought experiment separates five service results from the four transfers between them. A service succeeds when it produces its agreed output from correct input. A transfer succeeds when that output reaches the next service with the context and authorization the next step needs. Those are distinct requirements in this deliberately simplified example.
The calendar can store the new time perfectly while the ride retains the old time. The research can be accurate while the lesson addresses yesterday’s question. Each part can work locally while the connection fails.
If the required handoffs are absent from the reliability calculation, the calculation describes a system the person does not actually use.
Count the connections.
Assume five services succeed 95% of the time each. Four handoffs succeed 90% of the time each. Every counted requirement is necessary, independent, and unrecovered within the defined time window.
77.4%
0.95⁵ ≈ 0.774
The five service results alone. This leaves the four handoffs out of the model.
50.8%
0.95⁵ × 0.90⁴ ≈ 0.508
All five service results and all four handoffs. The intention now has nine requirements to survive.
All rates are hypothetical. Change only the four handoffs from 90% to 99%, and modeled overall success rises to 74.3%, while service quality stays the same. That improvement is possible within the arithmetic; it is not a claim about an existing bundle.
Integration has to earn the improvement
Putting five services behind one interface does not change the multiplication. It may add an identity service, an orchestrator, and another network dependency. A more elegant experience can conceal a more fragile system.
The engineering opportunity is to change what the person depends on: improve the transfers, remove unnecessary dependencies, detect stale information, and provide a workable alternative when the first route breaks.
Shared context can help the next service receive the right purpose. Confirmation can establish that a proposed booking became an accepted booking. A useful exception process can repair a change without asking the person to reconstruct the entire day.
Those mechanisms have to work. They add their own dependencies and costs. Their value is established by whether the intended outcome becomes more dependable within the person’s actual limits.
The strongest bundle would therefore sell continuity that survives exceptions. The person arrives prepared even when the meeting time changes. She keeps the evening she intended to protect even when the original preparation plan needs repair.
The product is the probability that the person’s intention survives the arrangement.
A life can recover
A person’s day is not a sealed device whose first failed part necessarily ends the mission. There can be another ride, a different preparation window, a downloaded brief, or a shorter lesson. The useful result may survive the failure of the original route.
Reliability engineering also considers parallel and redundant arrangements, where an alternative can keep the system working. For a personal bundle, the practical question is whether a fallback can preserve the outcome in time, within budget, and within the person’s permissions.
Two ride options do little good if the second cannot arrive before the meeting. A second source of research does not help if nobody notices that the first brief is missing. Recovery needs detection, enough time, and a viable path.
And apparent alternatives can share a failure. Two services may depend on the same network, payment authorization, or account. One outage can defeat both. You cannot infer their combined reliability by multiplying marginal success rates when the independence assumption does not hold.
The general probability rule can instead use the chance of each next requirement succeeding given that earlier requirements succeeded. In practice, dependable claims require measured outcomes and an understanding of shared causes. A neat product of advertised percentages is not enough.
Preserve the right outcome
There is a human judgment underneath every reliability target: what counts as success?
Suppose the intention is to be ready for a meeting without losing an evening with a child. A system that rescues the meeting by consuming the evening has preserved one event and broken the larger intention.
Similarly, an authorization check can interrupt a sequence for the right reason. Removing that check may raise a crude completion rate while making the environment less trustworthy. Permission, correctness, and the person’s boundaries belong in the definition of success.
The system must also allow the intention to change. If the person decides the meeting is no longer worth the tradeoff, cancelling it can be a successful exercise of agency. Reliability does not mean forcing the original plan through every later objection.
This is why the bundle needs a continuing relationship with its person. It must know which commitments matter, which arrangements are replaceable, and which new circumstances require a decision.
The hidden work becomes a class advantage
Without a dependable environment, a person often supplies the recovery personally: checking, reminding, copying, confirming, and chasing the exception. The day works because someone keeps returning to the gaps.
That labor can make a collection of unreliable connections appear reliable. Its cost is paid in attention. Counting successful outcomes alone would miss the effort required to keep them successful.
The subscriber’s advantage would be both a greater chance of reaching the intended outcome and less personal work required to protect that chance. She can stop monitoring a sequence without abandoning it.
That deepens the argument in The Subscription Class. Two people may have comparable access to intelligence. One must still provide the integration and recovery that the other receives as part of the environment.
The distinction may look like composure, initiative, or an extraordinary ability to follow through. Some of it is the surrounding system’s ability to absorb an ordinary failure.
The claim a bundle has to prove
Lusser’s Law does not prove that one provider will win, that integration must outperform separate services, or that paying for a bundle creates a superpower. It identifies the difficulty the promise has to overcome.
A credible provider would have to show how often a defined intention is fulfilled within its constraints, how much intervention it requires, and what happens when a dependency breaks. Measurements would need to include the unglamorous recoveries as well as the demonstrations that go perfectly.
My prediction is that this becomes an important basis of competition. The valuable environment will keep more human purposes intact across more ordinary disruptions. Its components can remain imperfect while its arrangements become more dependable.
The superpower begins when a person can reasonably trust that what she meant will survive the journey into what happens.
Sources and scope. The engineering law is sourced; its application to personal bundles is my argument. Numerical examples are hypothetical calculations, not observed product rates.
- NIST/SEMATECH e-Handbook: Series model — assumptions and product formula.
- NIST/SEMATECH e-Handbook: Parallel or redundant model — alternative system structure and its assumptions.
- Lusser’s Law on Wikipedia — an accessible overview of the named law.