Concepts/Concept

ADPS Agent Systems Blue Book · Engineering Concept

Failure-to-Rule Loop: Make an Incident Change the Next Run

Require every repeated failure to change a rule, test, template, or capability asset.

Version
v0.4
Definition status
Candidate concept
Issued
2026-08-02
Source case
Xuanxu Technology GIS Publishing Agent
Case contributor
Yuke Xiong
License
CC BY 4.0

Start with a template collision

A viewer template used Python string.Template while its JavaScript contained ${...}. Python interpreted the JavaScript placeholders, producing blank legends or a generation error. Writing “template issue” in a retrospective would not prevent the next generated pipeline from repeating the failure.

Definition

A failure-to-rule loop requires an incident record to produce a verifiable system change. The record holds the symptom, signature, root cause, immediate handling, prevention action, and source. The prevention action points to a rule, default, template constraint, test, or generated capability asset.

runtime failure -> structured incident card -> review -> rule or asset change
        ^                                            |
        +------------ verify on a later case --------+

The loop ends when later behavior changes, not when the document is finished.

Boundary

Repeated, enumerable, testable failures are good candidates for rules. Open failures may remain under human judgment or offline analysis. A model may draft a card, but an unverified root-cause guess must not become a runtime rule.

Provenance

  • Initial case: Xuanxu Technology GIS publishing agent, contributed by Yuke Xiong.
  • Lineage: SRE postmortems, corrective actions, failure journals, and regression tests.
  • ADPS contribution: every incident action links back into runtime rules or capability assets and is tested on a later run.
  • Definition status: candidate concept.