A graph traversal, not a plausible paragraph.
Helio loads the records your engineering organization already keeps into one property graph.
Four steps, each one checkable
Connect the records you already keep
Helio reads services, owning teams, people, dependency edges, on-call rotations and decision records. GitHub issues, pull requests and commits add recency signals. The public demo uses a synthetic company of 185 nodes: 120 people, 20 services, 5 teams and 40 decisions.
Turn the question into a traversal
A question is mapped onto the edges that can answer it. Ownership follows OWNED_BY. Impact follows HAS_DEPENDENT. History follows SUPERSEDES. Paging follows ON_CALL. Text search is used only to find a leaf, never to invent a relationship.
Return the answer with its evidence
The response carries the nodes, edges and dates it used. Volume and recency are separate signals, so the person with the most commits is not automatically the owner. If an edge is missing, the answer says the graph has no record instead of filling the gap.
Let a person check it
Every claim can be opened in the trail or the graph console. That is the difference between a plausible paragraph and an answer a team can defend during an incident or a postmortem.
payments-gateway, three questions
The sample company is small enough to check by hand. It is also shaped like the problems that make text search fail: a departed top contributor, a three-hop dependency cascade, and a decision that replaced an older document.
Who owns payments-gateway?
The Platform team owns it. The former payments lead has the most commits (14), but the last touch was 2026-04-15 and that person left in April. Decision D-21 (2026-04-15) named the Platform team as the accountable owner, and its on-call engineer committed on 2026-09-28. Ask the Platform rotation.
What breaks if it goes down?
Eight services sit downstream across three hops: checkout-api, dispute-service, mobile-bff, config-service, notifications, webhook-relay, fraud-scoring and recommendation. config-service has no owner and no on-call engineer recorded, so the cascade has a gap.
Why is there a second payment provider?
A March document says "single provider, Stripe." Decision D-19 (2026-05-06) established "dual provider, Adyen primary, Stripe fallback" and supersedes the earlier document. The graph shows the March doc as obsolete rather than presenting both as current.
What Helio does not do
- It does not monitor production, page an engineer or replace an incident tool. It answers who to page and what depends on what.
- It does not decide that a document is current just because it ranks well. A newer decision has to supersede it in the graph.
- It does not promise perfect answers. It promises that an answer can be checked, and that a missing edge is reported as missing.
- It does not require you to move every document. The graph holds relationships; the source systems stay where they are.
How Helio works: common questions
- Is Helio a search engine for documents?
- No. Helio can point at documents, but its answers come from relationships: which team owns a service, which services depend on it, who is on call, and which decision superseded an older one. Text search is used at the leaves to resolve a name.
- Does the language model answer from its own knowledge?
- No. The model interprets the question and phrases the result. The facts come from the graph. If the traversal returns an empty set, the answer reports the gap.
- How current is the graph?
- It depends on the sources you connect. Git activity and GitHub issues update on sync. On-call rotations and decision records update when those systems change or are re-imported. Every answer shows the dates it relied on so staleness is visible.
- Can we see it without connecting our data?
- Yes. The public demo uses a synthetic company. Open the agent or the graph console and ask about payments-gateway, config-service or the Stripe/Adyen decision.
Ask a question you already know the answer to
That is the fastest way to judge a company brain. Start with the demo, then open the trail and compare it with what your team believes.