Improve / IMP-5

Return the bureau feed to 3.2 Proposed

Use this page to review an example of a proposal, written by hand from the finding in IMP-2. A person decides. Nothing here changes a real system.

ProposedWaiting for a person
LiveNot started
MeasuredNot started

Why this change

All 70 runs that read feed 3.3 were denied. Runs still on 3.2 in the same hours were denied 16% of the time.

Median DTI on those runs went from 0.27 to 222.28, and median reported income from 47,000 to 52. That looks like a change of unit in the feed, though the telemetry alone cannot confirm it.

Expected: affected runs return to about 16% denied. That is an assumption until measured.

The change

Example, no repository connected
bureau_agent/config.yaml
− record_feed_version: "3.3"
+ record_feed_version: "3.2"

Statistics chose what to change. A model only writes the text, and may not add or remove a finding.

Checks before a person sees it

Some are computed here, and others do not exist yet
CheckResultBasis
The two ranges do not overlapPassed100% against 16% denied in the same hours, 70 and 152 runs.
One change at a timeNeeds checkingPolicy 2026.10.1 arrived 0.66 h after feed 3.3. Returning only the feed to the old version keeps the two changes apart.
Easy to undoAssumedOnly one fixed value changes. .
Independent outcome checkNot built
Auga may propose thisNot built
Stays inside the boundaryNot built

The page is a prototype and a working draft. Auga computes the measured figures from Rootplant credit-4217, a synthetic file of 400 runs. The proposal and the rollout are simulated. Dashed links show planned features and open a note about them.

Draft pull request

Not built
What it will do

Auga opens a draft pull request (PR) with the evidence, the expected effect and how to undo the change. Configuration comes first and code last, and a person always approves.

Why Improve needs it

Here a proposal enters your organisation's own review and release process.

Today

The feature is not built.

Cause chain in Evidence

In Auga
What it will do

The link opens the graph at this change, with its grade and the path to the outcome. A result can then show how the change had that effect.

Why Improve needs it

Measuring shows that something moved. Evidence can show why, and which setting to change. Proposals need that answer.

Today

Evidence exists. Its screening stops at 15 signals, and in our test suite that kept real links out of the graph.

Simulation before rollout

Prototype
What it will do

The simulation replays history against the proposal. It shows which runs the proposal would have changed, before any real traffic reaches it.

Why Improve needs it

The simulation shows a reviewer how many runs the change would affect. It cannot show what would have happened afterwards.

Today

Mandate Simulator is a separate prototype for stages, and it is outside the repository.

Proposal writer

Not built
What it will do

The proposal writer turns a finding into a concrete change and a written reason. Statistics choose what to change, and a model only writes it down.

Why Improve needs it

A cause is not an action. Knowing that DTI drives denials does not say what to edit. A person wrote the proposal on this page by hand.

Today

The proposal writer is not built. The rule stays that a model may not create or remove a link in the graph.

Repository connection

Not built
What it will do

The repository connection links your organisation's repository and maps each signal in the telemetry to the file and line that sets it.

Why Improve needs it

No proposal can become a pull request without the repository connection. Write access needs far more trust than receiving filtered run data.

Today

The repository connection is not built. The diff on this page is an example, and no repository is connected.

Independent rule check

Partly
What it will do

Auga also checks every measured improvement against the result of a rule, and the agent cannot learn to satisfy that rule.

Why Improve needs it

If an automatic judge scores success, proposals can start to follow the preference of the judge rather than the outcome.

Today

auga/judgebias.py exists. The fix that lets it run on Inbox data is PR augalabs/augapro#113, which was not merged at the last check.

Improve's own mandate

Partly
What it will do

Auga follows the same stages as agents, area by area. It earns the right to suggest in text, then to open configuration PRs, then code PRs.

Why Improve needs it

Self-improvement should not get more rights than the evidence supports, and the stage should fall when a proposal does harm.

Today

Mandates govern agents today (/mandates). Nothing applies them to Auga's own proposals.

Data boundary

In Auga
What it will do

The proposal writer and the repository connection run on your organisation's side of the data boundary. This page shows what crossed the boundary.

Why Improve needs it

Writing a good change needs prompts and code, which today's boundary is built to keep out.

Today

Auga edge and its receipt exist (/boundary). A design for content with consent was sketched, but the docs still say something else.

Decision review

In Auga
What it will do

Proposals join the same queue as guarded decisions, with the evidence attached, so a person answers in one place.

Why Improve needs it

Approve and Reject on this page should write to the same review, not to a new inbox.

Today

Decision review exists (/review) for guarded decisions and wording. Proposals are not in it.

The ledger

In Auga
What it will do

Each step is signed into the ledger: finding, proposal, approval, rollout, result. An auditor can follow one change from start to end.

Why Improve needs it

A system that changes itself is acceptable only if every change can be traced afterwards.

Today

The signed ledger exists (/ledger) for guarded decisions. These types of entry do not exist.