Skip to main content

The Canonical Technology Stack

The canonical stack is the S4U reference profile, not a requirement that every enterprise replace its established technology. Select the profile explicitly during inception. An alternative stack must implement applicable controls and provide equivalent evidence; its difference alone is not a methodology defect.

Appendix M describes the Python/PostgreSQL/React reference choices. Within an adopted profile:

  • Mandatory means required for that profile’s stated capability/control contract.
  • Default means a preferred starting point with documented reasons for alternatives.
  • Forbidden means prohibited within the defined profile and scope, not a universal ban on a library in every possible use.

Three load-bearing rules:

  1. Single source, pointers elsewhere. Each normative rule has one declared home. Project instructions point to the adopted version and record genuine local differences. scripts/check-single-source.sh detects long verbatim copies, not every semantic contradiction or paraphrase. Organizational authority and approved project constraints remain above derived cards and templates.
  2. Decisions remain traceable. Select the profile in an ADR. Changes to an accepted decision use supersession or an approved factual erratum as appropriate; do not silently rewrite ADR-0001. Changes to business/security meaning require that owner’s approval.
  3. Evolve from evidence. Evaluate compatibility, maintenance, dependencies, performance, cost and security. Prior-project experience informs a proposal but does not guarantee suitability elsewhere. Pin supported versions and evaluate upgrades.

Structured logs and real integration environments produce useful evidence. A particular logging library or container package does not itself prove conformance. Keep control purposes portable and adapter assumptions explicit.