INTEGRAL:
FROM THEORY
TO FIRST NODE
A Development Guide for Contributors of All Kinds
Who This Document Is For
Developers
BUILDERS
Data structures, interface contracts, phase-by-phase build scope, and architectural principles for writing code that fits the full system.
→ Start at Section 3
Theorists & Domain Experts
THINKERS
Development philosophy, how the build strategy connects to the white paper, and where domain expertise shapes architectural decisions.
→ Start at Section 1
Cooperative Practitioners
ORGANIZERS
What a Phase 1 node looks like in practice, how to prepare a community before software exists, and how to engage with the contributor community.
→ Start at Section 6
New Arrivals
EXPLORERS
Read the Preface, then the white paper abstract, then return to Section 2. That sequence gives the clearest orientation before deciding where to engage.
→ Start at Preface
00
PREFACE
What this document is, how it relates to the white paper, the central challenge of building minimally while building faithfully, and how to read it depending on background and interests.
01
THE DEVELOPMENT PHILOSOPHY
Why we build in vertical slices. The distinction between architectural faithfulness and functional completeness. The specific proof of concept Phase 1 must achieve. How complexity scales over time in response to real operational need rather than theoretical completeness.
02
THE FIVE SYSTEMS AT A GLANCE
Plain-language descriptions of all five systems. How they depend on each other. The master data flow map. What "minimalistic but faithful" means in practice with concrete examples of acceptable versus unacceptable simplification.
03
THE MINIMUM VIABLE MODULE SET
For each of the five systems: which modules are included in Phase 1, which are deliberately deferred, and the rationale for every decision. The line between acceptable scope reduction and unacceptable principle violation, applied module by module.
04
CRITICAL DATA STRUCTURES
Why data architecture comes first. The five core cross-system data contracts. Field-level schemas for every critical object — CertifiedDesign, LaborEvent, MaterialConsumptionEvent, CreditBalance, ITCLedgerEntry, FRSSignalPacket, DiagnosticFinding, Recommendation. API boundaries and interface versioning.
05
THE PHASED EXPANSION PATH
Phase 0 through Phase 3 — foundations, first node, module expansion, and federation. What triggers each phase transition. Expected but non-fixed timelines. The principle that expansion is driven by demonstrated need, not theoretical completeness.
06
HOW TO CONTRIBUTE
Contributor types and entry points. GitHub repository structure. Branching, issue, and pull request workflow. Issue templates. Discord versus GitHub — what goes where. The three-tier decision-making process for the project itself.
07
GUIDING PRINCIPLES FOR BUILDERS
Five principles every contributor should internalize before writing code: build the skeleton to fit the full body, interfaces before implementation, non-transferability is architectural not policy, the feedback loop must close from day one, and document decisions not just code.
A–C
APPENDICES
Appendix A: Complete mapping of all 45 white paper modules to development phases. Appendix B: Glossary of 40+ core terms defined precisely in Integral's usage. Appendix C: Recommended reading and reference systems across foundational theory, tools, and community practice.
CONTRIBUTE TO THE BUILD
The development guide lives in the project GitHub repository. Issues, pull requests, and discussions are open to all contributors.