40 Radically Different Infrastructure Primitives, From Reach and Expect to Ignorance and Stop
This list deliberately leaves “tiny version of Redis, Kafka or SQLite” territory behind. That was the first list of 20 primitives. The more interesting search space is a primitive that introduces a new operation, one developers might eventually feel should have existed all along. Some research paper or niche project has probably explored pieces of these. They’re meant as category-level concepts, not smaller copies of familiar products.
Forty primitives
1. Reach. Store a current state plus transition rules and continuously maintain which states are reachable from here: REACHABLE(current_state). A database answers what is; Reach answers what can happen. Uses: AI agent safety, workflows, infrastructure, manufacturing, cybersecurity attack paths.
2. Unreach. The inverse. Declare a forbidden state and keep checking whether the system still has any path that could reach it: FORBID(data_loss). If a configuration change suddenly opens a path to the forbidden state, Unreach emits an event. Could be surprisingly useful for security and infrastructure.
3. Undo. Make reversibility an infrastructure primitive. Before an application performs an operation, it registers enough information to reverse it. DO(action) automatically creates UNDO(action). Unlike transactions, reversal could happen minutes or days later and across external systems. Irreversible actions complicate things. That’s part of what makes it interesting.
4. Consequence. Feed it an event and get back everything that event causally changes. CHANGE server=A.offline returns affected services, customers, jobs and dependencies. Dependency graphs exist, but the primitive here is continuous consequence propagation, not graph storage. If this changes, what else changes?
5. Why. A tiny explanation engine. Applications record decisions plus their inputs. Later: WHY request_827 denied? returns “rule 14 failed because account.status was suspended.” Instead of logs that humans must pick through to rebuild causality, explanations become a native artifact produced when decisions happen.
6. Because. Reverse Why. Given an outcome, find the smallest set of inputs responsible for it. Especially interesting with complex rule systems and AI-assisted systems. “What actually caused this result?” turns into a query instead of forensic work.
7. Regret. Remembers decisions and later scores them against what happened. Record decision X; when the result arrives, Regret works out whether another available decision would have done better. It could underpin continuously learning operational systems without being an ML framework itself.
8. Assumption. Software registers the assumptions it depends on: ASSUME currency=="USD", ASSUME latency<500ms, ASSUME schema.version>=4. The engine watches reality and announces when an assumption stops holding. That’s subtly different from monitoring. You’re recording the hidden premises the software was written under.
9. Expect. Programs declare future events they expect: EXPECT payment_confirmation WITHIN 30s. If it happens, the expectation disappears. If it doesn’t, the absence itself becomes an event. Most event systems are good at noticing things that happen. Absence is awkward. Expect makes “something should have happened but didn’t” the primitive.
10. Eventually. Similar, aimed at distributed systems. Declare a condition that must eventually hold: EVENTUALLY replicas==3. The engine ignores temporary violations but detects when eventual consistency looks like it has turned into permanent inconsistency.
11. Before. A temporal-ordering primitive. Declare relationships like payment before shipment, authentication before access, approval before deployment. Feed it events and it flags violations. It could become a remarkably small compliance and security engine, because it evaluates sequences, not single events.
12. NeverTogether. Declare combinations of states that must never coexist, such as production=true AND debug_access=true. The engine watches state across several systems and catches forbidden combinations. Ordinary policy engines don’t do this. Here the primitive is cross-system coexistence.
13. Witness. When something important happens, automatically keep the minimum evidence needed to prove later that it happened. Not logging everything: building evidence packages on purpose. Timestamp, relevant state, hashes, causal inputs and signatures, sealed as one immutable witness.
14. Alibi. The opposite forensic question. Given an accusation like “service A changed record X,” determine whether the available evidence proves A couldn’t have. Odd name, interesting security primitive: machine-verifiable negative evidence.
15. Missing. An engine built around information that should exist and doesn’t. Feed it normal observations and expected structures, and it detects meaningful absence: missing invoice numbers, telemetry, sequence numbers, files, transactions, heartbeat periods. Most software is built to process presence, not absence.
16. Unknown. Uncertainty as a first-class data type. Values aren’t just true, false, present or null; they carry what’s known, unknown, inferred or assumed: country=France confidence=.72 source=X. Unlike a probabilistic database, the interesting part is tracking the boundary between known and unknown as data moves through applications.
17. Contradiction. Feed it statements from different systems and it keeps finding claims that can’t all be true. customer.status=active from the CRM and customer.status=closed from billing produce a contradiction object instead of one value silently winning. Promising for data integration, OSINT and AI pipelines.
18. Consensus. Give it the same fact from several sources and it maintains the best-supported current version. This isn’t replication consensus. It’s semantic consensus: five feeds say a vessel is at X, two say Y, and the engine keeps the evidence behind each claim plus the current winner. Very interesting for OSINT.
19. Decay. Information loses authority with age, by rule. A location might be unreliable after five minutes while a birth date practically never expires. The engine doesn’t just TTL-delete; it lowers confidence as time passes. Useful for AI context, intelligence, caches and digital twins.
20. Fresh. The companion question: is this answer fresh enough for this particular decision? A weather reading can be fresh enough for one operation and stale for another. Instead of stamping universal TTLs on data, freshness depends on intended use.
21. Belief. Maintain what a system currently believes, not just what it stores. New evidence strengthens, weakens or replaces beliefs while the supporting evidence is kept. It sits between databases and probabilistic reasoning without becoming a full AI system.
22. Claim. Every datum is subject, predicate, value, source and time, and conflicting claims coexist. The engine never silently overwrites disagreement. A strong fit for OSINT, journalism, AI retrieval and heterogeneous databases.
23. Promise. Software creates machine-readable promises: I will produce X by T. Other components can depend on the promise before the result exists. Fulfillment, failure and expiry are native states. It sits between futures in programming languages and durable workflow infrastructure, moved across process boundaries.
24. Intent. Store intended actions apart from executed ones. A program writes INTEND transfer(X, Y, 100), validators inspect it, and only later does it become COMMIT. A generic safety layer around autonomous agents and sensitive infrastructure.
25. Shadow. Every important operation can run against a shadow state before it runs for real. The application sees predicted changes and invariant violations, then decides whether to go ahead. This is the Counterfactual Store reduced to one commercially understandable primitive.
26. Fork. Cheap persistent branches of application state. FORK production AS experiment17, modify the fork, query it, then discard or merge. Unlike database snapshots, writable branching is the core abstraction, not an admin feature.
27. Merge. The companion: given two independently changed states, work out which changes can safely coexist, which conflict, and why. Git does this for files. Merge would try it for structured application state.
28. Boundary. Applications declare boundaries instead of permissions. “Customer information must never cross from the EU region to the US region.” Boundary watches data movement and flags violations no matter which application moved the data. A potentially interesting compliance primitive.
29. Taint. Attach an invisible property to data and carry it through every transformation. If confidential input contributes to an output, the output stays confidential. Information-flow and taint analysis exist in research and security tools, but runtime taint propagation as a tiny infrastructure primitive could be interesting.
30. Origin. Every value carries enough to trace itself back through its transformations. Unlike the broader Provenance idea, keep it brutally minimal: origin(value). An API receiving a number could ask where that number ultimately came from. Increasingly relevant as AI-generated values flow into ordinary software.
31. Mutation. Store transformations, not objects. Current state is just the accumulated result. Event sourcing is obviously adjacent, but picture it cut down to a tiny embeddable engine where transformations are the primary storage and materialized state is disposable.
32. Difference. Store only what sets one entity apart from another. Define a baseline once, and millions of entities store deviations from it. Useful wherever huge populations of objects are nearly identical: configurations, digital twins, devices, containers, simulations.
33. Exception. The inverse of a conventional database. The engine assumes everything is normal unless told otherwise and stores only deviations from expected state. Ten million sensors reporting normal cost close to nothing; only departures become durable data. Distill reduces streams. Exception makes “normal doesn’t need storage” the data model itself.
34. Surprise. Feed it observations plus expectations, and it keeps only events whose information content clears a threshold. Predictable? Forget it. Surprising? Keep it. One step past Distill: storage grows with unexpectedness, not volume.
35. Question. A database whose primary objects are persistent queries, not records. Register QUESTION "Are any production machines overheating?" and incoming data keeps changing its answer. Precomputing is adjacent, but Question flips the abstraction completely: developers declare what they need to know instead of what they need to store.
36. Ignorance. Give the engine a question and it tells you exactly which missing information stops it from answering. Not “unknown” but “I could answer this if I knew A and B.” Potentially big for agents: instead of hallucinating or gathering data blindly, an agent gets the minimum information-gathering task.
37. Sufficiency. Given a decision and the available evidence, decide whether there’s enough information to make that decision under declared rules. CAN_DECIDE loan_application_17? returns no, income verification missing. It could sit in front of humans, workflow engines or AI agents.
38. CheapestTruth. Given a question and several information sources with different costs, find the cheapest sequence of queries that settles the answer with enough confidence. An agent wouldn’t hit ten APIs by reflex. The primitive might decide API #3 alone is enough, or that #1, followed by #7 only when #1 is ambiguous, minimizes expected cost.
39. Stop. A surprisingly neglected primitive: decide when more computation or information gathering is no longer worth it. Feed it incremental results, costs and a sufficiency rule, and it emits STOP. This could matter enormously for AI agents, search, crawling, optimization and expensive inference. Today’s systems are much better at deciding how to start work than when enough is done.
40. Doubt. Keep challenging stored conclusions when their supporting inputs change. Instead of recomputing everything, a conclusion turns doubtful when the evidence under it moves, triggering selective re-evaluation. Dependency invalidation, applied to knowledge instead of caches.
The four worth deeper thought
Under the money-first screen, four of these stand out.
Surprise creates different storage economics: pay for information, not bytes. A system producing predictable data costs almost nothing to retain, while unusual behavior takes the storage. That could become a very different observability architecture.
Expect is almost embarrassingly simple, which is a point in its favor. Software is full of “X should happen within Y” logic, rebuilt again and again with timers, cron jobs, queues and monitoring rules. Turning the absence of an expected event into a first-class event could give a tiny but highly reusable primitive.
Ignorance may be the most novel. AI agents have a basic problem: they often don’t know precisely what they don’t know. An engine that takes a question, the available facts and rules, and returns the minimum missing facts could become infrastructure for deciding what an agent retrieves next. That isn’t another vector database, agent framework or RAG system.
Stop may have the clearest economic argument. Inference, agent loops, searches and API calls all cost money, and everyone’s focused on making models do more. A primitive whose only job is to say “you have enough; another $0.40 won’t materially improve this answer” goes straight at compute spend.
Ignorance plus Stop
For the next project in the mold of AltSql or BareProxy, something that can be defined as a very small engine and actually prototyped, the order to investigate is Expect, Surprise, Ignorance and Stop.
Ignorance and Stop together are the intriguing pair. One tells an intelligent system exactly what it still needs to know. The other tells it when it knows enough.
That’s close to a new control layer around AI reasoning, not another AI model.