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.
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.
Initial source: Xuanxu Technology GIS Publishing Agent Chinese case report; contributed by Yuke Xiong.