Every claim cites a fact

A nineteen-minute film of StellarView running a whole delivery lifecycle with a team of agents and people: from the method a House chooses, through the backlog, a real meeting, the plan and the launch, to what the team keeps. Every screen in it is the real product. The seats are agents, the voices are synthetic, and the drawings are labelled as drawings.

Our sprint meetings have six seats: five are agents and one is a person. Each meeting starts from a frozen snapshot of git, the tracker, the build record and the cloud account. Every claim an agent makes carries the id of the fact it rests on, and a claim that cites no fact, or an id that is not in the snapshot, is struck before it is said. The last refinement cost $1.34 in model calls, including the $0.21 pre-read. Of the four outcomes its pre-read aimed for, it reached one, and only partly. No backlog order was set, because setting it is a person’s job. Below is nineteen minutes of the whole lifecycle on real screens, and a list of what does not work yet.

Watch the real meeting (9:23) · Jump to how it closed · What does not work yet

StellarView is not an app builder and not a chatbot. It is a platform that runs the lifecycle around the code, with agents in seats next to people. Agents propose. A named person decides.

What is in the film

at	what
0:05	The mission, who it is for, the seats, why it is not a thin wrapper
2:01	HAL, the template studio: every prompt a file; the skills beside them
3:34	One engine, your lens: Scrum, Kanban, SAFe, Waterfall, ITIL, Pulse
5:51	The Backlog room: an order set by a person, with a reason
7:31	Pulse: every meeting read; we see, predict and influence
9:16	A real refinement meeting: the pre-read, the room, the close
11:38	Two doors into an epic: attach one, or cut one from documents
14:27	A filled epic: phases, diagrams drawn live, the Gap Command Center
16:02	Planning picks the Commander; launch; Mission Control in full
18:30	What does not work yet
18:55	The close

Three kinds of team

We built this for three kinds of team, and they want different things from it.

• People coming up in a craft: architecture, design, project management, Scrum, cloud, development. The delivery knowledge is in the product and it teaches as it works.
• Teams that want a complete head start: foundations, documentation, support, cloud and distribution, ready on the first day.
• Strong teams that are not changing. They do not want a new process. They want the new power inside their own method, their own models and their own prompts. For them the platform has to bend, and it has to be available, documented and actually work.

The third group is the one most tools ignore, and the numbers say it is large. The State of Agile survey puts resistance to change and culture clash at the top of what blocks adoption, at 47 per cent (Digital.ai, 17th State of Agile, 2024). DORA’s 2025 report puts it plainly: AI “magnifies an organization’s existing strengths and weaknesses” (dora.dev). So the method is a setting, not a religion.

Not a thin wrapper

A wrapper has no domain. This one is a domain: the domain of software delivery itself, counted on disk rather than claimed. HAL serves 134 prompt templates and 31 skills. There are 8 domain registries, 28 galaxies (one per product, each with its own keys), and 943 throw new Error sites in the backend. A unit slung to EC2 can pull its image, read the Fleet’s manifests and be reached through Systems Manager; it opens no port to the internet.

For the hardcores: every one of those prompts is a file, opened and changed in HAL. The meeting agendas are templates too. Change refinement’s template and the next refinement meets differently. Nothing that steers the machine is hidden in code.

Your method, one engine

A House picks its lens once: Pulse, Scrum, Kanban, SAFe, Waterfall or ITIL. The lens renames every room, sets the meetings and their agendas, and adds the gates that method has. SAFe’s Epic Owner approves an epic before it can be ready. A team that works differently names its own lens. What the engine does at each of the twelve steps is the same under every lens, and agents always flow; the lens changes how people meet, not how the units work.

Pulse: the time between

Pulse is our name for how the people keep time over agents that flow. It starts from a plain observation: the time between any two actions costs the same whether people are working or waiting, and something not happening now costs just as much. So Pulse goes after the time between.

• We see. Every meeting starts from a snapshot, and every claim cites it.
• We predict. Before an epic is planned, every branch in flight is merged in a throwaway copy, so the plan is made against what the code will be. Every upcoming meeting carries a checklist (agenda, pre-read, notes), so the one with no agenda shows.
• We influence. Before a meeting, a pre-read goes out, written from the last meeting’s record: why we meet, the solutions on the table, what each person should think about first, and what we want to arrive with. If nobody is asked to know what the future expects, nobody arrives with it.

The meeting in the film is real. We made the pre-read for a refinement ($0.21), ran the room live with five agent seats and one person, and filmed it by replaying its own record afterwards, which costs nothing. With the pre-read, it cost $1.34 in model calls, read from the ledger: five turns at $0.20 to $0.25 each. And it did not go well, which is the point. Sue closed it against the pre-read: of the four things we meant to arrive with, we had one, and only partly. No order was set, because a person had not set it. What the person got was seven minutes that named exactly what was theirs to decide: an owner and a date for the merge to staging, and an order for the sprint’s epics. That is the system working.

No claim was struck in this meeting, and none has been in any meeting on record: the seats cite. The rule is in the code (Meeting.evidenceRule) and has a test (evidence-rule.test.js). It checks that every cited fact exists in the snapshot. It does not check that the sentence says what the fact says; the stage shows each claim’s facts beside it for a person to read.

From documents to a plan

There are two doors into an epic: attach one that exists on the board, or cut a fresh one from documents. Either way it is filled the same way. Requirements say where each one came from: typed, parsed, or derived, and “not stated in the document” when it was not. The plan is phases in dependency order, work units grounded in the code, and a diagram per phase drawn with it. Whatever the documents leave open is a gap, written down as a question and never filled in to keep things moving. Client questions go to the client; research questions go to the machine. Ready means filled, saved, every gap answered, and one person accountable.

Launch, and the instruments

Planning chooses the Commander. At launch each epic becomes a unit, slung where it should run: a container on this machine or an EC2 instance, authorised by a named person and never by the system itself. What a unit builds ships through the fleet to ECS in your own account. Mission Control shows it as it flies: the star, the room, the instruments, the machine under it, and a trajectory where every mark is something that happened. The launch in the film, a local launch of seven units on 22 September, reports yellow because two were held, and it says which and why.

The same screens are honest about the account. On the day we filmed it, one machine was running, five were stopped with no reason recorded, and six volumes were still billing. The screen says so in red.

The model under the film

Every film we make writes a model of itself as it is made: each line with who said it, when, in whose voice and over which screen; each teaching term anchored inside the words that said it; each term with its canonical source and the StellarView file that makes it real; each line said in a meeting with the facts its seat cited. This film’s model has 94 beats, 43 topics and 90 cites, and a learning path in nine steps, in the order a person should learn it rather than the order the film shows it. The same model carries the Spanish, as a pack laid over it, every string tied to the English it came from. A second film, made in our Learning Design Studio, walks through that World.

What it cost

The meeting: $1.34, from the ledger. Filming it by replay: nothing. The voices, the drawings and the assembly run on one machine. The honest expensive parts are elsewhere: the people who review, and the questions only a client can answer.

What does not work yet

• A meeting cannot write the Backlog order itself. ROTOR proposes; a person sets it, by hand.
• A lens’s sprint length and gates do not act on their own yet.
• Past client meetings (Fathom) do not feed the pre-read yet. It reads our own last meeting.
• A unit is slung into a container or EC2, not yet into ECS. ECS is where the app it builds goes.
• The strike checks that a cited fact exists, not that the sentence is true to it. A person reads that.
• Each galaxy has its own keys, but 29 backend files still read credentials (GitHub, Jira, Claude, AWS, Fathom, Confluence) straight from the process environment. Isolation is not finished.
• There is no public download yet. It runs for partners today, on their machine or in their own AWS account.
• The voices are synthetic, the seats are agents, the Flybys are drawings. All of it is labelled.
• The Pulse name covers two bodies of work, the published Pulse Operations doctrine and the lens in this film, and we have not reconciled them in writing yet.

Try it, read more

Daily notes and downloads are in the Journal. Explore the Stellarverse, the proof site with every film, at stellarverse.stellarview.net. The earlier parts: the Launch Engagement and Launch Day.

Credits

Filmed on our own StellarView, our own team and our own repositories. Client names are blurred in every frame. Sue, Cakes and Wolfie are agent seats with synthetic voices. Click any still to see it large, and use the arrows to walk through them all.