How Flagridge caught its own rules not reaching the work

Flagridge is our group's own product: a method for running software delivery through agents and written rules.

Technologies
AI agents, written rules
Industry
Software delivery
Engagement Model
Own product
Team
Product and engineering
Timeline
Since October, ongoing

A written rule helps only if it reaches the place where the work is done. We read the logs of our own working sessions, not the status reports, and found that the method's core had no mechanism for delivering its main rules into the session. The fix was released with pass marks written down before anything was measured. It is an internal finding on the group's own product, not a client delivery.

The result

The result today is a finding, not a figure. The gap between the rules as written and the sessions as run was located and fixed. Whether the fix holds is being measured against pass marks written down before the measurement began, not against an earlier run. The verdict comes only once a set of qualifying sessions is complete. When it does, it will be added here with its source and period.

The task

The core of the method holds the rules that decide which agent takes a piece of work and what each stage must produce. Those rules matter only if the agent doing the work has them. Inspection showed that no mechanism carried the core's main rules into the working session. A rule could be written, reviewed and released, and still be missing from the session where the work was done.

Here “what runs” means the working session, where agents carry out the rules, not a product in front of users.

The approach

  1. Read the logs, not the reports.

    A report said the rules existed. The logs showed whether a session had received them. Passing tests would not have shown the gap either, because tests cover the code, not whether the rules reach the work.

  2. Write the pass marks before measuring.

    The specification of the fix set its pass marks in writing before anything was measured: one for whether the core rules reach every working session, others for how agents then use them. For each mark it also named the next step if it was missed, so a miss could not be explained away afterwards. The marks are not quoted here, because a mark quoted without its measurement would read as a result.

  3. Expect the gap to return.

    Three times the method's description of itself differed from what ran, and each time a measurement caught it, not a report. In July the core described standing instructions that no session ever loaded. In October came the gap described above. The third time it appears to be the measuring script itself. Since mid-October one of the agents has handed back its results by a route the script does not read, so half of the measurement no longer describes what it was built to describe. The first two gaps were corrected. The third is not fixed yet, and the page says so rather than quietly dropping the affected half.

What is not established

Whether the rules, once delivered, are followed in the session is not established.

The part of the measurement meant to answer that is the one affected by the third gap, so its readings would describe the gap, not the behaviour. They are not used.

What this means for a product owner

Two problems you probably know are this same gap in a different setting.

An idea arrives changed because what was written did not reach the people doing the work.

Delivery stalls out of sight because the status report stays green while the work does not move.

The case shows a way to read delivery from what is accepted and what runs, not from reports. Compare the rule with what happened, and write the pass mark down before you look.

We do not claim our gates cannot fail. This case shows one that did, and how the failure was found. Whether the approach carries over from a process run by agents to one run by people is a hypothesis; the case does not test it.

Limitations

The gap has recurred.

It was found three times, once in the measuring tool itself. A fourth time is possible; the method claims only that it looks for the gap in the logs and has found it each time it looked.

One installation, one repository.

Any later figure will describe that setup, not others.

The people running the sessions know what is measured.

The sessions are not blind to the measurement.

Part of the reading is approximate.

Even without the third gap, the part that judges how agents behave depends on log formats and rule wording that change between versions. Whether the core rules were delivered does not.

Where to find it

The method: flagridge.com.

Want delivery you can read from what runs?

Start with one backlog item or one stalled delivery.

Talk to us

Thank you for contacting us

Our manager will get back to you shortly. While waiting, you may visit our portfolio.

Contact us

By submitting request you agree to our Privacy Policy

By submitting request you agree to our Privacy Policy

Contact us

By submitting request you agree to our Privacy Policy