abstraction-architect

Abstraction Architect Knowledge Base

The question this knowledge base answers:

Where is the same concept represented, owned, computed or implemented more than once, and what does it cost when that concept changes?

Structural entropy accumulates in ways that look locally reasonable. A support team implements an eligibility check because the domain one was hard to reach. A config value is added next to the code that reads it. A DTO is copied because the original had a field the new caller did not want. Each decision is defensible; the sum is a codebase where a single conceptual change touches nine files and misses two.

The two evidence tracks

Everything here rests on one distinction, developed in references/theory.md section 9 and operationalized in references/evidence-tracks.md.

The track determines the nature of the evidence. The dimension determines the gate.

• Form is the same mechanism written more than once. The risk is premature extraction, the instrument is the count, and the Rule of Three is the gate for D5.
• Knowledge is the same fact holding more than one authoritative representation. The risk is drift between owners, the count is the wrong instrument, and two representations are sufficient behind a much stricter semantic proof.

The discriminating question for the knowledge track: can these representations legitimately disagree? If yes, there is no finding, whatever the surface similarity. If no, two is enough.

When to use this skill

Load it when:

• Deciding whether to extract, centralize or inline
• Asking who canonically owns a fact, a policy, a threshold or a piece of state
• Auditing for duplicated knowledge, competing authorities, redundant models, or stored state that is derivable
• Evaluating whether an existing abstraction is paying for itself
• Running /abstraction-architect:audit, which spawns the auditor agent that loads this skill

Do not load it for the concerns listed in references/scope-boundaries.md, which names the owner of each.