Decisions are classified into three tiers consistent with the project's own governance model. Tier 1 decisions are day-to-day technical choices made by working groups. Tier 2 decisions are cross-system or architectural choices requiring broad documented consensus. Tier 3 decisions are foundational or governance choices requiring a community-wide process.
This page is updated as decisions are made. The canonical record lives in the GitHub repository under docs/architecture/decisions/ as individual Architecture Decision Records (ADRs). What you see here is the public-facing summary.
2025-12-01
PROJECT ESTABLISHED AS COMMUNITY-GOVERNED OPEN SOURCE
Integral is established as an open source project governed by its contributor community. No individual holds unilateral architectural authority.
Decision
The Integral project is established as a community-governed open source project from inception. All significant decisions require documented community consensus through the three-tier process. No individual, including the project's founder, holds unilateral authority over architectural or governance decisions.
Rationale
A project building a system premised on democratic governance must itself be democratically governed. Establishing this from inception rather than transitioning to it later avoids the structural capture that founder-authority creates. The project's integrity depends on practicing what it proposes.
2025-12-01
ITC NON-TRANSFERABILITY IS ARCHITECTURAL, NOT POLICY
The transferable field in the ITC credit schema is permanently set to false at the architectural level. It cannot be changed by governance decision.
Decision
ITC credit non-transferability is implemented as an architectural constraint enforced at the schema and API level — not as a policy enforced by governance. The transferable field in the CreditBalance schema is permanently false and cannot be set otherwise through any governance decision or software update.
Rationale
Transferability would allow credit accumulation by receiving others' credits — which would recreate wealth dynamics structurally identical to money. Making this a policy creates the risk of later erosion through governance pressure. Making it architectural removes it from the domain of governance entirely. This is the most critical single design constraint in the ITC system.
2025-12-08
FRS OPERATIONAL IN PHASE 1 — NOT DEFERRED
The Feedback and Review System must be operational from the first working node. Deferring FRS to Phase 2 is not acceptable.
Decision
FRS modules FRS-1 (signal intake), FRS-2 (diagnostic analysis), FRS-4 (recommendations), and FRS-5 (sensemaking interface) are included in the Phase 1 minimum viable module set. Deferring FRS was proposed as a way to simplify Phase 1 scope — this proposal was rejected.
Rationale
The feedback loop from FRS to CDS is the architectural property that makes Integral a viable cybernetic system rather than a static governance structure. A Phase 1 node without FRS is not a simplified Integral — it is a different system. The scope reduction from deferring FRS violates the architectural faithfulness principle. FRS-1 through FRS-5 can be implemented in simplified form, but they must be present.
2025-12-10
DEFERRED FIELDS INCLUDED IN ALL PHASE 1 SCHEMAS
All critical data schemas must include nullable deferred fields from Phase 2 and 3 — to prevent breaking migrations when those phases are built.
Decision
All Phase 1 data schemas must include deferred fields from Phase 2 and Phase 3 specifications as nullable or defaulted fields. No Phase 2 or Phase 3 module may require a schema migration of a field that was predictably needed but omitted from Phase 1 schemas.
Rationale
Breaking schema migrations in a live system with real data are costly, disruptive, and often impossible to execute cleanly. The cost of including a nullable field in Phase 1 that is only used in Phase 3 is negligible. The cost of a schema migration after Phase 1 nodes are running with real community data is very high. Build the skeleton to fit the full body from the start.
PENDING // In deliberation
TECHNOLOGY STACK SELECTION
The Phase 0 decision on programming languages, database, API protocol, and deployment model. Open for community deliberation now.
decision_record // integrity.note
// This record is append-only.
// Past decisions are not altered or removed.
// If a decision is reversed, a new entry records the reversal.
// Canonical source: /docs/architecture/decisions/ on GitHub.
total_decisions:
4 ratified // 1 pending
last_updated:
2025-12-10
phase:
0 // foundations