domains / families / business / intended-vs-implemented

intended-vs-implemented

separate

The method for finding the gap between what a system is supposed to do and what the code actually does — the class of bug generic scanners miss because they have no model of intent. Defines what counts as documented intent, what counts as implementation evidence, which mismatches matter, and how to avoid hand-wavy findings. Use when auditing AI-built code, reviewing access control against documented permissions, or checking whether a codebase matches its own documentation.

When to use

• A linter scans code in a vacuum. It can tell you the code is *internally* consistent; it cannot tell you the code does what you *meant*, because it has no model of your intent. The highest-value security and correctness bugs live in that g…

When not to use

• sink-level security analysis
• performance audits
• auditing when documented intent is absent or stale
• fabricating intent to manufacture gaps

Skill page

Source