The repository index on Czar Forge

Every engineering team carries more than its code. There are the design notes that explain why a service was built the way it was, the tickets that record what broke and how it was fixed, the runbooks that say what to do at three in the morning, and the documentation that is almost but not quite current. Most of it is read by searching and hoping. A platform team or an ML team on a Czar Forge indexes all of it on the appliance and questions it in place, with the passage every answer came from, and none of it leaves the building to be indexed.

What is in the index

The repository index on a Czar Forge holds the team's code, design notes, tickets, runbooks, and documentation, drawn over the routes declared at commissioning: source control, ticketing, the documentation store, and whatever else the team chooses to include. The team decides what is indexed, repository by repository and system by system. A repository that should not be visible to the agents is simply not included, and nothing in the index is visible to anyone outside the team's own network.

The index is kept current from the same declared routes. A merged change, a closed ticket, or a revised runbook appears in the index without anyone exporting it, and the record shows when it did.

Questioned in place

An engineer asks the index a question the way they would ask a colleague who had read everything: why this service retries the way it does, what happened the last time this alert fired, which runbook covers a failover for this cluster, where the convention for this kind of migration is written down. Retrieval finds the passages, Inference composes an answer from them, and the answer arrives with the passages it came from, so the engineer can read the source and decide whether to believe it.

That citation is not decoration. An answer without its passage is an opinion; an answer with it is a pointer into the team's own material, which the engineer can confirm in a moment. When the model is wrong, the passage shows it, and the team learns where the index needs better material rather than trusting a plausible paragraph.

Retrieval and Memory

Two of Substrate's seven services do the work. Retrieval holds the index and finds the passages. Memory keeps what has been learned across questions and tasks: which answers an engineer confirmed, which corrections were made, which parts of the codebase the team has marked as authoritative and which as stale. The agents on a Czar Forge read from both. A coding agent asked to change a service reads the service through Retrieval and its history through Memory. An incident diagnostics agent reads the runbook, the recent changes, and the last few times a similar alert fired.

Where the team has used Adaptation to tune a model on its own code and conventions, the answers get better in a particular way: the model reads the team's code as the team reads it rather than as a general model would. Evaluation scores the index's answers against questions the team has already resolved, so the team can see where to trust it.

Why the index is the team's

An index built in a vendor's cloud is a copy of the team's material that the team does not hold. Whatever is promised about what the vendor keeps, the copy exists, the route exists, and the questions the team asks, which say a great deal about what the team is working on and what is broken, travel the same way. On a Czar Forge the index is on the appliance, inside the perimeter, and the questions stay with it. The Forge can run with no route out at all; where routes exist, Local Bridge permits only the ones declared and denies everything else. The index is as much the team's as the repositories it was built from.

Agents on a Czar Forge prepare and propose; a named engineer merges, promotes, or releases. Nothing reaches production, a customer, or the outside without that person, and every step is on the record the team holds. The index is what the agents and the engineers read before any of that; it changes nothing on its own.

When the team grows

A team that outgrows one Czar Forge joins more Czars as a Czar Grid, and the index becomes one index across the pool. Nothing is reindexed by hand and nothing is rewritten. Czar Forge is offered only to technology and AI teams; a team of another kind runs its own index on Czar, configured for its own material.

A team's knowledge is spread across its code, its tickets, its notes, and the memories of the people who were there. The repository index gathers the written part onto the appliance, where every engineer and every agent can question it in place, and where the answers come back with their sources. What the team knows stays where the team is.