Quality as Architecture

In one line: make required controls observable and testable, and distinguish enforced boundaries from guidance that people or agents may miss.

Instructions, reviewer agents, local hooks and server controls serve different purposes:

Layer	Contribution	Limit to verify
Instructions and memory	Carry approved conventions and context	Loading, currency and compliance are not guaranteed
Skills and review	Guide workflow and identify defects	Can be skipped or misapplied; agreement is not an independent oracle
Local hooks	Evaluate registered events with configured commands	Alternate paths, unsupported events or missing registration may bypass them
Server/action-boundary controls	Enforce permitted transitions or required candidate checks	Effective settings, identities, bypasses, failure modes and revocation matter

A control is not established because its file exists or its installation command succeeded. Demonstrate an allowed path and a denied/adverse path at the actual boundary, under the real actor/environment. Record what is automated, what is advisory and what remains unassessed. Reassess when configuration, dependencies or scope change.

For example, integration evidence uses the actual migration-built schema. PostgreSQL RLS tests use the effective runtime identity; superuser and BYPASSRLS roles bypass policies, including forced RLS. Append-only storage needs actual integrity, privilege and retention controls. A typed approval record needs authenticated authorization, concurrency and current-revision checks in its receiving service; a schema alone supplies none of those. PostgreSQL RLS, gate architecture.

These layers are complementary but may share inputs and blind spots. Protect accepted requirements from unilateral implementation edits, preserve safe failure states, and retain accountable review and release decisions. The aim is lower reliance on memory and discipline, not a claim that human judgment has disappeared.

---