-
-
Google Cloud and HELM architecture
-
View and export the complete plan
-
Review before saving
-
Update the plan with evidence
-
Answer related questions together
-
Compare possible directions
-
Turn a direction into action
-
Start with what you have
-
HELM architecture
Military Slices
Inspiration
I wanted to help veterans, not kill trees.
Kill trees is my shorthand for the physical footprint behind brute force AI. Compute, energy, cooling, water, data centers. When a system reprocesses everything it has ever known in order to answer one question, that cost lands somewhere real.
So I asked a narrower question. Why process an entire lifecycle when only a bounded portion of it is material to the decision in front of you right now?
I retired after twenty years in the United States Navy. Military transition is where that question stopped being abstract for me. Career, education, family, location, money, time, and purpose do not resolve independently. They interact. Move the location and the school changes. Change the school and the timeline changes. Change the timeline and the money changes.
The world had built tools for every piece. But I wasn't pieces.
Then I noticed the shape was not unique to me. Everything has a lifecycle. Careers, cases, claims, treatments, contracts, estates. Each one is a long horizon process where evidence accumulates, decisions depend on other decisions, and a human holds authority they should not have to surrender to use software.
That is where HELM begins.
What it does
HELM is Human Enabled Lifecycle Management. Military Slices is its first implementation and its proving ground.
The problem is not context reduction. Reduction on its own is compression, and compression that drops evidence is data loss with better marketing. HELM has to control four things simultaneously: context, state, authority, and human burden.
That produced the question the entire system is built around. What is the smallest governed context necessary for a valid decision, and what is the shortest governed path between human intent and outcome, without compressing away evidence, correctness, or human authority?
To the veteran using it, Military Slices mostly asks one thing. What matters now?
About 95% of what makes Military Slices special happens under the hood. Underneath that one question sit governed state, uncertainty, provenance, dependency handling, rejection, authority boundaries, Resolver behavior, bounded agents, human Gates, persistence, and defined failure behavior.
The visible simplicity is not a design flourish. The simplicity is what the engineering produced.
One separation holds the whole architecture together. HELM governs how. HELM Domain Packs govern what. Slices govern where.
How I built it
The algebra.
HELM makes explicit the distinctions a language model blurs by default.
Relevant is not actionable. Observe is not activate. Explore is not commit. Capability is not authority.
Those are constraints on operations, not slogans. A decision that is valid against one governed state can become invalid when the state it depended on changes. A rejection has to change what the system does next, not just what it displays. Unknown is permitted to remain unknown, because forcing a value is how a system launders a guess into evidence.
So every operation answers the same three part question before it runs. When is this operation valid, against which state, and under whose authority?
I did not invent new mathematics. I made existing distinctions explicit and enforceable.
The geometry.
A lifecycle is a large multidimensional state space. Evidence, decisions, uncertainty, dependencies, time, preferences, constraints.
A Slice is a bounded execution surface cut from that space. The current objective receives the governed projection of state that the objective requires, not the entire lifecycle.
That creates an aperture problem. Open it too wide and you pay for noise, coupling, and cost you never needed. Close it too far and you drop the dependency that would have made the answer invalid.
The goal is not minimum context. The goal is the smallest governed context that preserves a valid decision.
Context compression.
On a representative Resolver benchmark, HELM reduced the state presented for resolution by 90.37% compared with full state, while preserving the governed information the test required.
That is a state reduction measurement. It is not a claim about energy, compute, water, cost, or environmental impact, and I am not going to dress it up as one.
Turn compression.
Machine work is only half of the waste. The other half is human.
Do not ask again what governed state already knows. Do not make someone reject the same option twice. Do not manufacture an LLM conversation around deterministic work. Do not route a machine resolvable intermediate step through a person when authority already permits resolution.
And do not compress away the decisions that are actually consequential. Those belong to the human.
Context compression reduces unnecessary machine work. Turn compression reduces unnecessary human work. Both are bounded by correctness and authority. Human attention is a resource too, and transition burns it faster than almost anything else I have been through.
The Google stack.
Military Slices runs as a FastAPI application on Google Cloud Run. Firestore persists canonical versioned state. Gemini through Vertex AI provides model capability, and the Google Agent Development Kit provides bounded agents constrained by structured outputs. Supported document and image inputs are extracted ephemerally with human review before persistence.
Cloud Run hosts the application. Firestore persists state. Gemini and ADK supply bounded capability. HELM governs what any of them are permitted to do inside a lifecycle.
Challenges
At some point I stopped asking whether HELM worked and started trying to break it.
What if state changes between authorization and execution? Authorization is bound to the state version it was granted against, so a stale approval fails instead of silently acting on a world that already moved. Optimistic concurrency on versioned writes turns a race into a rejection.
What if an external action succeeds but the acknowledgment never comes back? That is the case that eats naive systems. Writes are idempotent and external effects are reconciled rather than assumed, so a lost response does not become a duplicated action or a phantom one.
What if new evidence invalidates a dependency three decisions upstream? Lineage is tracked, so invalidation propagates and the affected decisions are revalidated instead of quietly inheriting a fact that is no longer true.
What if the model is capable of something it was never authorized to do? Capability is not authority. The Slice bounds the work, and HELM's bounded Probe can surface something for examination without gaining authority to act on it.
What if the human says no? Rejection is state. It persists, it constrains what gets proposed next, and it does not get relitigated by the next agent that wanders through.
Every one of those turned into containment work, provenance work, and failure path work. None of it is visible in the interface. All of it is why the interface can afford to be quiet.
Accomplishments
Military Slices is deployed on Google Cloud, with governed state persisting across individual model calls and subsequent interactions.
I built a governance architecture and then made it disappear.
Military Slices does not present a veteran with a dashboard of everything. It presents the bounded thing that is material now, with the evidence behind it and the authority still in the veteran's hands.
The compression result matters to me less as a number than as proof of the premise. Most of a lifecycle is not relevant to most decisions inside it, and you can prove which part is relevant instead of guessing.
The part I am most satisfied with is the boring part. The system fails in defined ways. It refuses stale authorizations, it keeps unknowns unknown, and it does not invent a fact to keep a conversation moving.
What I learned
The question kept getting better.
I started with how much context does the AI need. That became how much of the lifecycle does this decision need. That became how much of the journey does the human actually need to traverse.
That progression is the whole evolution from context optimization to lifecycle governance. The first question is about a model. The last one is about a person's time and authority.
I also learned the interface goal is inverted from most AI products. Those systems get louder as they learn more about you.
As the system learns more, the foreground should get quieter.
What's next
Military transition is HELM's first proving ground, not HELM's destination.
The next meaningful architectural test is changing domains. If HELM is genuinely domain independent, the Domain Pack changes, the Slice changes, and the governing core does not need to be reinvented.
If the core needs reinvention, it was never a core.
That is the test I want to run next.
