Sidecat Sideinfra and the believing problem
Sideinfra is the part of the Sidecat work that asks a different question from most developer tools. Not just "where is the code?" or "what depends on this?" but: why should an agent believe this artifact is current, accepted, proven, and safe to act on?
That distinction matters because coding agents do not share the quiet context a human team keeps in its head. A person may know that a note is stale, a demo was rejected, a test only proves an old design, or a script is scar tissue from last month. An agent sees a file. If the system gives it only search results and prose, it can collapse "present in the tree" into "accepted truth."
Finding is not believing
Many useful tools solve finding problems: code search, ownership files, build graphs, dependency maps, tickets, CI logs, and dashboards. They are still useful for agents. They are not enough.
The failure mode we are designing against is a believing problem. A path can exist without being declared. A declared surface can be absent. A design can be accepted before it is proven. A test can pass without proving the current claim. Evidence can be real and still be stale at the current revision.
Sideinfra treats those as separate questions. It derives judgments over what was observed, what was declared, what Sidecat authority decided, what evidence proves, who owns the surface, and whether the source pins are still current. The answer should be calibrated, not a bare boolean.
Sidecat governs; Sideinfra explains
Sidecat remains the authority service for work items, gates, evidence, receipts, decisions, and external effects. Sideinfra does not become a second truth service beside it.
Instead, Sideinfra reads Sidecat projections and repository state, then builds explainable intelligence for an agent to load before acting. It can say: this surface exists, it is declared by this profile, Sidecat accepted it through this work item, no current proof is attached, and the next action should be proof work rather than more implementation.
That is the difference between "a file exists" and "the system has enough reason to believe the file belongs here."
Bazel-inspired, not Bazel-based
Bazel is an obvious influence: stable labels, declared graphs, typed facts, providers, aspects, and graph queries. Sideinfra borrows those lessons without becoming a build system.
A build system turns declared inputs into artifacts. Sideinfra is aimed at agentic software work: loaded context, work authority, proof obligations, stale claims, cleanup pressure, and next actions. The graph is not there to compile a binary. It is there to keep an agent from losing the plot.
The first shape
The current Sideinfra work is early, but the product center is now clear. Sideinfra should help agents ask:
- What exists in the repository?
- What is declared by a profile or catalog?
- What has Sidecat accepted, rejected, or deferred?
- What evidence proves the current claim?
- Who owns it?
- Is the judgment current at this revision?
- What gap remains before acting?
Gaps become the useful product surface. Exists but undeclared. Accepted but unverified. Rejected but still present. Proven but stale. Declared but absent. Those are the moments where an agent needs more than a search result.
The first landed slice
The first useful command shape is intentionally small:
sideinfra explain. Given a Sidecat work subject, it loads a
sidecatd projection, records the profile revision used to interpret it,
and returns a judgment record with provenance, gaps, and a next action.
A current work item can now come back as accepted, unverified, owned,
and current, with gaps such as accepted_unverified and a
suggested next action such as verify-proof. That is not a
dashboard and not a second authority service. It is a context packet an
agent can load before editing.
Why this matters for Sidecat
Sidecat is being built by agents, with agents, under a governance model that should make serious work more recoverable instead of more ceremonial. That only works if the project can resist its own sprawl.
Sideinfra is how we make that resistance concrete. New scripts, tests, docs, packages, and source surfaces should carry role, owner, proof, lifecycle, and deletion pressure. If an artifact is not current evidence, it should say so or get out of the way.
The short version is the one we keep coming back to: Sidecat coordinates and governs agentic work. Sideinfra is the intelligence client for understanding what work should happen and why.
- The Sidecat Dev project