Governance and Standards
docs(governance): D6 — governance category completion
@@ -8,7 +8,7 @@ quality: complete short_description: "Formal decision records, licensing posture, contributor model, and compliance requirements that govern how the PointSav platform is built, licensed, and changed — including the twelve binding architecture decisions, the BCSC continuous-disclosure posture, and the licence matrix." status: active bcsc_class: public-disclosure-safe last_edited: 2026-05-18 last_edited: 2026-05-19 editor: pointsav-engineering paired_with: _index.es.md --- @@ -38,6 +38,20 @@ Start here for procurement, security, and compliance evaluation. - [[contributor-model]] — The three-tier contributor model: open community, paid integrators, and the canonical vendor tier; how work flows between them. - [[canadian-simple-copyright]] — The Canadian-simple copyright posture: licence selection, attribution requirements, and the Canadian legal context. - [[legal-and-ip-structure]] — The three-corporation IP topology: how intellectual property transfers from contributors to vendor to customer, with squash-and-merge as the atomic IP-transfer event. ### Engineering sovereignty - [[sovereign-replacement-initiative]] — The formal program that records every third-party dependency in a structured ledger, enforces quarantine isolation, and retires each dependency when a native replacement reaches structural parity. - [[moonshot-initiatives]] — The nine active engineering programs building native replacements for quarantined third-party dependencies, from the kernel layer up through the build toolchain. - [[sovereign-airlock-doctrine]] — The staged-commit protocol that enforces a structural separation between staging identities (commit authors) and canonical push identities, with no direct path between them. ### Platform disciplines - [[ontological-governance]] — The four throttled control ledgers and human-verification loop that prevent automated classification drift from undermining the integrity of long-lived institutional data. - [[anti-homogenization-discipline]] — The architectural posture that resists AI writing assistants pulling contributors toward a single voice, defaulting to flagging rather than silent rewriting. - [[api-key-boundary-discipline]] — The rule that all external LLM API credentials belong exclusively at the gateway service and never at inference engines or downstream consumers. - [[favicon-matrix]] — The icon matrix governing visual identity across all platform surfaces: one distinct glyph per service, OS, and application, enforced at the asset-pipeline layer. ## See also