Skip to content

references.md

Latest commit

 

History

History
53 lines (38 loc) · 7.02 KB

references.md

File metadata and controls

53 lines (38 loc) · 7.02 KB
Raw

References

The key works the methodology stands on. Format: source — what exactly it supports.

The promise as the source of truth

  • Burgess M., Bergstra J. — Promise Theory: Principles and Applications (2014; theory since 2004). A promise as the source of intent that observers calibrate their expectations against; the voluntariness of a promise versus an imposed obligation; an agent promises only its own behavior. Working notes: markburgess.org/PromiseMethod.pdf.

Granularity and shape of promises

  • Cockburn A. — Writing Effective Use Cases (2000). Goal levels (cloud/kite/sea/fish/clam); a sea-level goal as "one sitting, walks away happy"; navigating by asking "why?" and "how?".
  • Wynne M. — Introducing Example Mapping (2015, cucumber.io). Rule/example/question; the "the one where …" convention; the signals that a rule is the wrong size.
  • Adzic G. — Specification by Example (2011). Examples as executable illustrations of requirements; living documentation; declarative scenarios versus imperative ones.
  • Mavin A. et al. — Easy Approach to Requirements Syntax (EARS) (RE'09, 2009). A controlled requirements syntax — "WHEN … the system SHALL …" — the notation for invariants wherever a promise needs rigor.
  • Popper K. — Logik der Forschung (1934; English The Logic of Scientific Discovery, 1959). Falsifiability as the criterion for a statement having content — the ground for the test "a promise for which you cannot imagine a betrayal is not a promise".

The target defect class

  • Calder M., Kolberg M., Magill E., Reiff-Marganiec S. — Feature interaction: a critical review and considered forecast (Computer Networks, 2003). Independently correct features that break each other; implicit assumptions as the main source of conflicts; detection methods.
  • Zave P. — Feature Interactions and Formal Specifications in Telecommunications (IEEE Computer 26(8), 1993) and the feature interaction FAQ (AT&T). Telling good feature interaction from bad; the feature's overall purpose as the frame the court judges within.
  • McCarthy J., Hayes P. — Some Philosophical Problems from the Standpoint of Artificial Intelligence (1969). The frame problem: how to express that an action changed nothing else. The philosophical foundation for proving UNTOUCHED.
  • Meyer B. — Object-Oriented Software Construction (2nd ed., 1997). Design by Contract, class invariants — here lifted to the feature level.

Why agent self-checking is unreliable

  • Sharma M. et al. — Towards Understanding Sycophancy in Language Models (arXiv:2310.13548). Models systematically cave to pressure to agree.
  • Panickssery A. et al. — LLM Evaluators Recognize and Favor Their Own Generations (arXiv:2404.13076). Self-preference: models overrate their own outputs, and the link is causal.
  • Kamoi R. et al. — When Can LLMs Actually Correct Their Own Mistakes? (TACL 2024, arXiv:2406.01297). Self-correction shown to work only with a reliable external anchor (execution, tests, search); feedback from the same prompted model showed no success.
  • Huang J. et al. — Large Language Models Cannot Self-Correct Reasoning Yet (arXiv:2310.01798). The "find the problems" framing can corrupt even correct answers.
  • Tyen G. et al. — LLMs cannot find reasoning errors, but can correct them given the error location (arXiv:2311.08516). The asymmetry between finding errors and fixing them; the ground for betting on localization (a locus you must show) instead of silent search.
  • Anthropic — Reasoning Models Don't Always Say What They Think (2025). Reasoning is not guaranteed to be faithful to the output; the link field can be a rationalization — hence the selective re-checks.
  • Tam Z.R. et al. — Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of Large Language Models (arXiv:2408.02442). Format constraints during reasoning degrade its quality — the ground for the "free reasoning first, structure after" order in a ledger row.

Forcing evidence

  • McAleese N. et al. — LLM Critics Help Catch LLM Bugs (CriticGPT, arXiv:2407.00215). A critic finds bugs in data humans had rated flawless; the trade-off between recall and hallucinated nitpicks.
  • Dhuliawala S. et al. — Chain-of-Verification Reduces Hallucination (arXiv:2309.11495). Factored verification: verification questions kept separate from the draft answer.
  • Gao T. et al. — Enabling Large Language Models to Generate Text with Citations (ALCE, arXiv:2305.14627). The citation recall and citation precision axes; evidence that exists but proves nothing is a measurable failure mode.
  • Irving G., Christiano P., Amodei D. — AI Safety via Debate (arXiv:1805.00899). Verifying a claim is easier than generating it; the asymmetric roles of the debaters.
  • Greenblatt R. et al. — AI Control: Improving Safety Despite Intentional Subversion (arXiv:2312.06942). A guarantee is only as strong as the best attack actually attempted — the ground for the betrayal candidates quota.

The human precedent: checklists and rote execution

  • Degani A., Wiener E. — Human Factors of Flight-Deck Checklists (NASA CR-177549, 1990). Challenge-response versus read-do; the response must carry an actual value; place-keeping errors.
  • Dismukes R.K., Berman B. — Checklists and Monitoring in the Cockpit: Why Crucial Defenses Sometimes Fail (NASA/TM-2010-216396, 2010). "Responding without looking" as a documented class of checker error.
  • Parasuraman R., Manzey D. — Complacency and Bias in Human Use of Automation (Human Factors 52(3), 2010). Trust in a system that has never let you down is not cured by practice; you have to measure instead of believe.
  • Myers G. — The Art of Software Testing (1979). A test that passed proved nothing; testing as an attempt to break.
  • Gawande A. — The Checklist Manifesto (2009). Checklist discipline and the ways it degenerates into a formality.

Neighbouring practice

  • GitHub — Spec Kit (2025). Spec-driven development as a command pipeline over an agent (constitution → specify → clarify → plan → tasks → analyze → implement); the platform the project below extends. The contrast that defines this methodology: its unit of truth is the task's own spec, so verification looks down at that spec's acceptance — the neighbouring-promise defect class is out of its reach by construction.
  • gingeard — spec-kit-lx (github.com/gingeard/spec-kit-lx, 2025). A preset and extension for Spec Kit, distilled from this author's earlier corpora (singbox-launcher, sing-box-lx) and crediting them. An independent formalisation of the same practice at the artifact level — specs as living documents, invariants in EARS form, status as machine fact — where this methodology went instead into the court over promises. Its // SPEC NNN traceability markers are the direct ancestor of // PROMISE FNNN-PN here; the semantics differ, and deliberately: that marker records where code came from, this one records what a place currently carries.