Architecture Premise Audit

Determine whether the project is built around the right system archetype, not merely whether its current modules are internally consistent. Audit read-only unless the user separately requests changes.

Boundaries

• Work at the whole-project or named broad-system boundary requested by the user.
• Derive the expected product model before treating repository terminology, architecture docs, tests, or benchmarks as authoritative.
• Treat passing proof as evidence about an implementation, not proof that the mechanism should exist.
• Complexity is a finding only when it lacks a required product need, owner, lifecycle, consumer, scaling contract, or failure contract.
• Do not turn a broad audit into implementation, issue creation, or a second review workflow.
• Ask only when one missing fact would reverse the verdict and cannot be bounded with an explicit assumption.