Governance
Governance
This category covers the formal decision records, licensing posture, contributor model, and compliance requirements that govern how the PointSav platform is built, licensed, and changed over time. Governance articles are the written record of decisions that have been made and the rationale behind them; they are not aspirational statements.
The twelve binding architecture decisions are the most important entries in this category for technical due diligence and regulatory review: they define where automated processing stops and human authority begins, how data is separated, and where cryptographic keys must reside. Licensing articles explain the licence matrix that governs each repository and its contents. The contributor model article describes the three-tier structure through which code and content flow from contributors to the canonical platform. The BCSC disclosure posture article documents the requirements of Canadian securities continuous-disclosure obligations as they apply to the platform and its public documentation.
Articles in this category
Institutional due diligence
Start here for procurement, security, and compliance evaluation.
- procurement-overview — What a regulated buyer acquires: customer-owned hardware deployment, no vendor-held data, no minimum-spend commitment, and the compliance properties enforced by architecture rather than contractual promise.
- security-overview — The platform's security posture: capability-based isolation, the Diode unidirectional command-flow standard, the Doorman AI boundary, the WORM audit ledger, and how each property is enforced by architecture.
- compliance-and-continuous-disclosure — How the platform produces continuous-disclosure-grade records and what that means for regulated buyers.
- bcsc-disclosure-posture — The BCSC continuous-disclosure posture and how the platform satisfies it by structure.
Formal decision records
- architecture-decisions — The twelve binding architecture decisions that constrain all future engineering; grouped by compliance weight, data separation, deployment custody, and operational integrity.
Licensing and contribution
- 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
All 20 articles in this area, A–Z
- About PointSav Knowledge2026-05-27
PointSav Knowledge is the engineering documentation wiki for the PointSav platform, serving engineers, architects, and institutional readers.
- Contact2026-05-27
Contact information for PointSav Digital Systems and Woodfine Capital Projects Inc.
- Contributing to PointSav Knowledge2026-05-27
How to propose additions, corrections, and new articles for PointSav Knowledge.
- Disclaimers2026-05-27
Disclaimer and terms of use for PointSav Knowledge, the engineering documentation wiki for the PointSav platform.
- Anti-homogenization discipline2026-04-30
Anti-homogenization discipline is the architectural posture that resists AI writing assistants pulling contributors toward a single voice, by defaulting to flagging potential issues rather than silently rewriting text.
- API key boundary discipline2026-05-01
The rule that all external LLM API credentials belong exclusively at the gateway service and never at inference engines.
- Architecture decisions2026-05-15
Twelve binding architecture decisions — recorded commitments that govern how the PointSav platform is built and constrain all future engineering work on data handling, human oversight, system separation, and deployment custody.
- BCSC continuous-disclosure posture2026-05-01
The operating discipline that treats every published artifact as potentially reviewable under Canadian securities continuous-disclosure obligations.
- Canadian-simple copyright posture2026-05-25
The platform's intellectual property vests in a single Canadian parent holding company by operation of Canadian Copyright Act § 13(3), without inter-company assignment, and is designed to be evolved incrementally as the corporate structure matures.
- governance/compliance-and-continuous-disclosure
- Three-tier contributor model2026-04-30
The Three-Tier Contributor Model organises PointSav substrate contributors into Core (4–7 salaried engineers), Paid (50–100 contracted project contributors), and Open (10,000-plus public participants), with explicit mobility paths between tiers.
- Favicon matrix and tab identity2026-05-08
The platform uses inline SVG data URIs for browser-tab favicons — eliminating a network call, scaling without pixelation on every display, and assigning two distinct vendor and customer marks to make the entity behind every tab unambiguous at a glance.
- Legal and IP structure2026-05-15
The three-corporation topology governing intellectual property transfer from contributors to vendor to customer, with squash-and-merge as the atomic IP-transfer event and strict separation preventing unaudited code or operational-record exposure.
- Moonshot initiatives2026-05-19
Moonshot initiatives are active engineering programs that build native replacements for quarantined third-party dependencies, with the goal of eliminating vendor lock-in and reducing the platform's external attack surface over time.
- Ontological governance2026-05-19
Ontological governance describes the four self-healing control ledgers that govern how service-content classifies and accumulates knowledge, and the human-verification loop that keeps extracted identity data accurate before it is permanently committed.
- Procurement overview2026-05-15
What a regulated buyer acquires when deploying PointSav: hardware the customer owns outright, data the vendor never holds, no minimum-spend commitment, and compliance properties enforced by architecture rather than contractual promise.
- Security overview2026-05-15
The platform's security posture: capability-based hardware isolation, the Diode unidirectional command-flow standard, the Doorman AI boundary, the WORM audit ledger, and how each property is enforced by architecture rather than by policy controls that can be misconfigured.
- The sovereign airlock2026-05-25
The sovereign airlock is the staged-commit protocol that enforces a hard separation between work-in-progress staging identities and canonical repository identities — two staging authors for all commits, two admin identities for canonical pushes, with no direct path between them.
- Sovereign replacement initiative2026-05-19
The Sovereign Replacement Initiative is the engineering governance program that tracks third-party dependencies, isolates them in quarantined component directories, and coordinates the active moonshot programs that build native replacements.
- PointSav Media Kit2026-05-25