Quality Gate Architecture Decision

Summary

This document explains why different portfolio repositories use different governance controls instead of forcing the same Gatehouse integration everywhere.

The key architectural decision was:

Use the right control at the right layer.
Do not apply the same governance mechanism to every repository by default.

This is a scope-control and architecture-maturity decision.

Scope

This document is an architecture decision record for portfolio and documentation governance patterns.

It is not a production control design, customer evidence archive, certification claim or enterprise GRC implementation plan.

Context

The portfolio contains several repositories with different risk profiles:

RBAC-Lite
ESP32 IoT Security Governance Lab
Local-First WordPress DevSecOps Kit
technical-documentation
Gatehouse / infrastructure change quality gate

All of them relate to governance, validation, documentation or controlled change. However, they do not all have the same risk model.

A single heavy governance integration across every repository would look consistent on the surface, but it would be architecturally weak if the control did not match the actual risk.

Decision

The decision was to apply governance controls according to project risk:

RBAC-Lite
  -> access-control quality gate integration

ESP32 IoT Security Governance Lab
  -> local embedded / edge-device quality gate profile

technical-documentation
  -> documentation quality gate

Local-First WordPress DevSecOps Kit
  -> repeatable local environment, runbooks and safe baseline documentation

Gatehouse
  -> general change-governance pattern and quality-gate reference

This keeps each repository coherent and avoids unnecessary platform complexity.

Why RBAC-Lite received the strongest quality gate integration

RBAC-Lite is the repository where a change can directly affect access-control behavior.

Its risk chain is:

user
  -> role
  -> permission
  -> visibility
  -> partner isolation
  -> audit trail
  -> compliance evidence

A change in RBAC-Lite is not only a feature change. It may be a control change.

That means review questions are different:

Can a user see different data?
Does partner isolation still hold?
Did a permission boundary change?
Is the rollback path known?
Is there evidence for the change?
Can the decision be audited later?

For that reason, a stronger quality gate is justified in RBAC-Lite.

The gate is not decorative there. It belongs to the core risk model of the project.

Why ESP32 used a local embedded quality gate instead

The ESP32 project has a different risk model.

Its core concerns are:

embedded / edge-device boundary
firmware baseline
public-safe device assumptions
device / edge impact
test evidence
rollback thinking
non-production scope

For this repository, a local embedded Gatehouse-style profile was a better fit than integrating the repository into a central Gatehouse engine.

The local gate demonstrates the same governance thinking, but keeps the ESP32 repository independent and understandable.

This avoids unnecessary cross-repository coupling.

Correct framing:

Gatehouse pattern applied locally to an embedded / edge-device context.

Not:

Central Gatehouse platform integration.

That distinction matters.

Why technical-documentation uses a documentation quality gate

The technical-documentation repository is a method library and documentation hub.

Its main risks are not runtime behavior or access-control behavior.

Its risks are documentation risks:

private material accidentally included
unclear public/private boundary
overclaiming project maturity
unscoped production-readiness language
missing documentation boundary sections
weak handover or review structure

Therefore the correct control is a documentation quality gate.

This gate validates documentation hygiene and boundary discipline rather than access-control or embedded-device change behavior.

Why Local-First WordPress DevSecOps Kit was not over-gated

The Local-First WordPress DevSecOps Kit demonstrates a repeatable local development environment.

Its core value is:

local-first setup
Docker Compose baseline
repeatable onboarding
safe local boundaries
runbooks
handover documentation
recoverability thinking
AI boundary notes

A heavy Gatehouse integration would have increased complexity without improving the core demonstration.

For that repository, the more appropriate maturity signal is a clean local environment, good runbooks and clear boundaries.

Over-gating it would have created architecture noise.

What would have been less mature

A less mature architecture decision would have been:

Put every repository behind the same Gatehouse integration because it looks consistent.

That would have created superficial uniformity, but not better architecture.

The risk would be:

unnecessary cross-repository coupling
heavier maintenance burden
unclear ownership of rules
policy-engine complexity before it is needed
harder review for portfolio readers
scope creep

A good portfolio architecture should not grow a platform before there is a platform problem.

Architectural principle

The principle is:

Right control, right layer, right weight.

More specifically:

If the project changes access-control behavior, use access-control governance.
If the project documents embedded / edge-device boundaries, use an embedded boundary gate.
If the project stores documentation patterns, use a documentation quality gate.
If the project demonstrates local environment repeatability, keep the control focused on repeatability, runbooks and safe boundaries.

This is the difference between governance discipline and governance theater.

Interview framing

A concise explanation:

I did not force the same quality gate model into every repository. I selected the control based on the risk profile of each project. RBAC-Lite received the strongest Gatehouse-style integration because access-control and partner-isolation changes are control changes. ESP32 received a local embedded quality gate because its risk is device/edge-boundary documentation, not central policy-engine reuse. technical-documentation received a documentation quality gate because its risk is documentation hygiene, public/private boundary and claim discipline. The principle was right control, right layer, right weight.

Portfolio value

This decision shows:

risk-based architecture thinking
scope control
avoidance of unnecessary platform complexity
governance controls matched to project context
understanding of access-control risk
understanding of embedded / edge boundary risk
understanding of documentation hygiene risk
ability to document architectural reasoning

The value is not only that quality gates exist.

The value is that they were placed selectively and intentionally.

One-sentence summary

The portfolio uses different quality gates because the repositories have different risk profiles; this is a deliberate architecture decision to apply the right control at the right layer without creating unnecessary governance complexity.