Charter to code (ADR-0003)¶
The mapping from each Constitutional Commitment to the specific code path that enforces it. Summarises ADR-0003 for the docs-site reader.
Implementation depth tiers¶
Each enforcement is documented at one of three depths:
- Tier 1 — Code shipped, unit tests assert correctness, build fails on regression
- Tier 2 — Tier 1 plus continuous-audit job re-verifies against historical data
- Tier 3 — Tier 2 plus inclusion in scope of annual ISAE 3000 sustainability assurance review
The mapping¶
Article I — Anti-sale¶
Source: Articles § 6.1(b), (d), § 6.2, § 11(a). Structural, not coded — enforcement at the share-register and Bolagsverket level.
Engineering responsibility: make the constraint legible. Current Articles text and shareholder list (with Class designations) are published at trust.vettedinference.com/#steward-ownership, populated from trust/content/steward-ownership.yml.
Owner ticket: VI-117 (this ADR), VI-1208 (Foundation Share transfer), VI-1209 (quarterly procedural audit).
Depth: Structural (legibility deliverables at Tier 1).
Article II — Dividend cap¶
Source: Articles § 5, § 11(b).
Enforcement: Auditor's annual statement (§ 8) confirms compliance with § 5. Engineering-side allocation calculator at gateway/app/billing/treasury.py enforces the 30%/30% split at every quarter-close.
Tests: tests/billing/test_treasury_split.py, tests/billing/test_treasury_invariants.py (property-based via Hypothesis).
Owner ticket: VI-1006 (Treasury allocator).
Depth: Tier 2 (computed at every quarter-close); Tier 3 from FY2027.
Article III — No defence, no dual-use¶
Source: Articles § 11©.
Enforcement: Three-stage screening at customer onboarding — self-declaration, automated EU sanctions + dual-use Annex I keyword + internal blocklist match, manual review for high-risk industry flags. Implemented in gateway/app/onboarding/dual_use_screen.py.
Tests: tests/onboarding/test_dual_use_screen.py, tests/onboarding/test_screen_audit_log.py.
Owner ticket: VI-205 (Customer onboarding KYB pipeline).
Depth: Tier 1 at launch (manual high-risk review); Tier 2 within 6 months (scheduled retrospective audit); Tier 3 from FY2027.
Article IV — Methodology publication duty¶
Source: Articles § 6.1(f), § 11(d).
Enforcement: License-header CI gate (every methodology Python file carries SPDX-License-Identifier: AGPL-3.0-or-later); quarterly methodology changelog automation (scheduled GitHub Actions); production methodology drift detection (asserts production version matches a tagged public commit).
Tests: tests/ci/test_license_headers.py, tests/ci/test_changelog_freshness.py, tests/ci/test_production_methodology_match.py.
Owner ticket: VI-1004 (Quarterly methodology changelog automation).
Depth: Tier 2 (continuous CI checks); Tier 3 target FY2027.
Article V — Zero retention default¶
Source: Articles § 11(e).
Enforcement: Three layers — Caddy reverse-proxy log format (no body capture), gateway middleware gateway/app/middleware/no_retain.py, daily retention sweep gateway/app/audit/retention_sweep.py.
Tests: tests/middleware/test_no_retain.py, tests/audit/test_retention_sweep.py, tests/infrastructure/test_caddy_no_body_logging.py.
Owner ticket: VI-208 (Retention middleware), VI-411 (Daily retention sweep).
Depth: Tier 2 (continuous daily sweep); Tier 3 target FY2027.
Article VI — Revenue concentration cap¶
Source: Articles § 11(f).
Enforcement: Daily compute of top-customer share of trailing-90-day revenue at gateway/app/billing/concentration_monitor.py; affiliation grouping at gateway/app/billing/affiliations.yml (manually curated, board-reviewed quarterly); 20% early-warning threshold and 25% mitigation-required threshold both auto-create board-pack tickets.
Tests: tests/billing/test_concentration_alert.py, tests/billing/test_affiliation_grouping.py.
Owner ticket: VI-1006 (Treasury allocator parent), VI-1006c (Concentration monitor).
Depth: Tier 1 at launch; Tier 2 by Q4 2026 (continuous monitoring with public metric).
Article VII — Locality of impact¶
Source: Articles § 11(g).
Enforcement: Locality calculator at gateway/app/treasury/locality.py maintains per-quarter set of compute regions used by paying customers and geocodes candidate restoration projects against the 200km radius. Allocations failing the locality check require explicit two-thirds board approval and public minute. Public ledger publishes per-allocation locality status.
Tests: tests/treasury/test_locality.py, tests/treasury/test_allocation_signoff.py.
Owner ticket: VI-1207 (Locality allocator).
Depth: Tier 1 at launch; Tier 2 by Q4 2026.
Article VIII — Quarterly governance vote¶
Source: Articles § 11(h).
Enforcement: Eligible-voter snapshot taken at notice-of-motion (six weeks before close), signed against Sigstore root and published. Vote table append-only and hash-chained at selma/app/governance/vote.py. Threshold tally at vote close: 60% in favour AND 25% turnout. Constitution version increments on threshold met; minority report attached.
Tests: tests/selma/test_vote.py, tests/selma/test_eligibility_snapshot.py, tests/selma/test_vote_ledger_integrity.py.
Owner ticket: VI-1701 (Quarterly governance vote system).
Depth: Tier 1 by Selma launch (Q4 2026); Tier 2 by Q1 2027.
Why this mapping is public¶
A constitutional commitment that lives only in legal text is fragile in two ways. First, legal text is interpreted by humans and is therefore subject to drift; engineering staff and product staff who are not in the loop on the legal text will, over years, design features and policies that quietly conflict with it. Second, an outside reader — auditor, customer, regulator, journalist, future hire, future board member — cannot easily verify that the company actually behaves the way the legal text says it does.
The remedy is a publicly-readable mapping from each constitutional commitment to the specific code path that enforces it, the specific test that asserts the enforcement, and the specific ticket that owns it. That mapping is ADR-0003 in full; this page is its docs-site summary.