Federated from workspace · Company · zaixos-company/docs/company/COMPANY_CONSTITUTION.md Do not edit canonical truth here — update the source repo, then re-run npm run docs:sync.

---

ZAIXOS Company Constitution

Document type: Corporate Constitution
Version: 1.1
Date: 2026-07-03
Milestone: M-05.5 — Company Constitution · v1.1 Constitutional Amendment
Status: Accepted
Classification: Internal — Corporate Authority — Highest company governance document
Owner: Chief Executive Officer (accountable) · Knowledge Architect (maintainer)
Authority: CHARTER.md · CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md · ZAIXOS_FINAL_EXECUTIVE_DECISIONS.md
Ratified: 2026-06-30 · IDENTITY_RATIFICATION.md · Amended 2026-07-03 · CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md

---

Preamble

This Constitution is the supreme governing document of ZAIXOS inside zaixos-company. It defines how the company operates, how decisions are made, how authority flows, and how company identity is protected across platforms and products.

Philosophical authority (WHY) resides in ZAIXOS_FOUNDER_MODEL.md when Accepted — supreme on belief, permanence, and 20-year identity signature, and subordinate to this Constitution on all governance questions. See Article I and Article XXV.

This is not a legal incorporation instrument. Entity formation, jurisdiction, and binding commercial contracts are governed by LEGAL_FOUNDATION.md and counsel outside this repository. This Constitution governs corporate authority, workspace behavior, and inheritance across the ratified four-repository baseline.

Binding hierarchy for corporate questions (Plane A — Corporate Authority Plane):

COMPANY_CONSTITUTION (this document — governance supremacy)
        ↓
ZAIXOS_FOUNDER_MODEL (philosophical supremacy — when Accepted)
        ↓
Identity documents (Vision, Mission, Values, Principles)
        ↓
docs/governance/* · docs/strategy/* · docs/brand/* · docs/legal/*
        ↓
Platform authority (ZEP, future platforms)
        ↓
Product authority (one repo per product)

Engineering sessions operate under Plane B — Runtime / Session Authority Plane per Article XXVII. The two planes coexist permanently and must not be merged.

Frozen engineering release baselines in workspace release records remain authoritative for shipped engineering scope under Plane B. They do not amend this Constitution. When release scope and corporate strategy conflict on future work, this Constitution and Accepted company strategy prevail under Plane A. When conflict is on what was frozen, the release record prevails — per Article XXIII §4 and Article XXVII.

Permanent constitutional constraints (non-waivable except by Class A amendment of this document):

Constraint	Reference
Split-apex — governance vs philosophical authority	Article I, XXV
Dual authority planes — permanent coexistence	Article XXVII
One authority per concept	Article VII, XXVIII
Cite, don't copy	Article VII
Knowledge taxonomy — one owner per knowledge class	Article XXVIII
Prohibition on unauthorized product duplication	Article X, XXIV
Platform-before-duplication; extract before second copy	Article IX
Human executive accountability	Article V, XI
AI assists — never holds executive authority	Article XI
Each product must strengthen the next	Article X
Reusable assets belong to company/platform layer	Article XIX
Company identity is global	Article II
Commercial launch markets are execution decisions	Article II, XXIV
Company experience doctrine — proof principles at company tier	Article II §7

---

Article I — Supremacy

1. Supreme company governance authority. No document inside zaixos-company overrides this Constitution on governance questions when ratified Accepted.
2. Supreme philosophical authority. When Accepted, ZAIXOS_FOUNDER_MODEL.md is supreme on all philosophical questions — belief, permanence, proof philosophy, and 20-year identity signature — and is subordinate to this Constitution on all governance questions. No document holds both philosophical and governance supremacy.
3. Workspace corporate questions. On strategy, portfolio, brand architecture, company-level AI posture, experience doctrine, and knowledge taxonomy policy, this Constitution is the root governance authority for all repositories.
4. Subordination. CHARTER.md governs repository existence and is subordinate to this Constitution on corporate governance questions.
5. Identity by reference. Vision, mission, values, and principles live in named documents — cited by reference, not duplicated in full here.
6. Platform and product constitutions are scoped to engineering and domain respectively — they implement this Constitution; they do not replace it.
7. Registry. zaixos-registry indexes workspace truth; it never owns corporate strategy bodies (SSOT policy Accepted FROZEN).
8. Split-apex permanence. Philosophical questions defer to Founder Model when Accepted. Governance questions defer to this Constitution. Executive resolutions (ZAIXOS_FINAL_EXECUTIVE_DECISIONS.md, CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md) bind strategic authorship and interpretation — they are not the philosophical apex and do not replace Founder Model.

---

Article II — Company Identity

1. Identity definition. ZAIXOS is a platform-engineering software company that builds vertical revenue operating systems on shared platforms and reusable engineering governance. See COMPANY_VISION.md.
2. AI-native scope. AI-native applies to engineering method (Layer 1) and product architecture (Layer 2) per ZAIXOS_FINAL_EXECUTIVE_DECISIONS.md OD-05 — not to unrestricted "AI company" or model-vendor identity.
3. Global company identity. Corporate, engineering, and registry surfaces use global English as primary language. Company identity is global — not defined by a single commercial launch geography.
4. Commercial launch markets. Selection of launch geography (any approved region for flagship dental SaaS) is an execution and strategy decision documented in Accepted strategy and executive decisions — not constitutional identity. Expansion to new regions requires Accepted DOMAIN_STRATEGY.md amendment — not Constitution amendment.
5. Operational honesty. Constitution and all subordinate documents must distinguish today-state from destination-state. See Value 6 in COMPANY_VALUES.md.
6. Consumer #1 is not the company. Dental Clinic Revenue Operating System (PRD-001) is the first Official Product — not corporate identity. See COMPANY_MISSION.md.
7. Company experience doctrine. Cross-product experience principles, Living Showcase proof doctrine, AI accountability patterns, preview-safe semantics, and dual-surface harmonization rules reside in Accepted COMPANY_EXPERIENCE_DOCTRINE.md — subordinate to this Constitution and ZAIXOS_FOUNDER_MODEL.md. Company tier defines proof and accountability requirements; product tier implements surface modality and domain workflows. M-17 Corporate Surface is static cite-only trust — not Living Showcase operational proof. See CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md CD-03.

---

Article III — Purpose

1. Corporate purpose. ZAIXOS exists to eliminate duplication of corporate authority and engineering governance across a portfolio of vertical products while encoding operational business knowledge in auditable software. See COMPANY_MISSION.md.
2. Mission execution. Day-to-day purpose is defined in Mission — not re-stated here.
3. Non-purpose. This company does not exist to: merge products into ZEP or company repos; operate as a generic chatbot vendor; or claim Product Factory status before M-24 factory certification evidence.
4. Evidence objective. Strategic objective (due diligence scope): invest engineering effort once, reuse across products through platforms and ZEP — measured at factory certification, not assumed.

---

Article IV — Authority Hierarchy

1. Ratified baseline (2026-06-30). Four repositories: zaixos-company, zaixos-registry, zaixos-engineering-platform, PRD-001 (Dental Clinic Revenue Operating System). No fifth baseline repo without Class A decision.
2. Flow direction.

zaixos-company (corporate authority)
        ↓ constrains
zaixos-registry (index only)
        ↓ references
zaixos-engineering-platform (engineering authority)
        ↓ consumed by
Product authority repos (domain)

3. Downward citation only. Lower layers cite upper authority. Lower layers never override company strategy, SSOT policy, or ratified workspace hierarchy.
4. No merge. Company authority shall not be merged into ZEP, registry, or any product repository — permanent rejection per EXECUTIVE_DECISION.md.
5. No split. Company authority shall not be split into separate brand-only or legal-only repositories — one company, one authority repository.
6. SSOT status. Workspace SSOT is CERTIFIED (M-04). Authority duplication in consumers is prohibited and architecture-guarded where implemented.

---

Article V — Executive Authority

1. Accountability. Chief Executive Officer is accountable custodian of this Constitution and Accepted company identity documents.
2. Ratification power. Only executives (or bodies defined in Accepted GOVERNANCE_MODEL.md) may move company documents from Draft or Proposed to Accepted.
3. Human authorship. Company vision, mission, values, principles, constitution, Founder Model, and strategy require human executive authorship — not autonomous AI generation treated as Accepted.
4. Class A authority. New product lines, new authority repositories, rebrands, constitution amendment, philosophical apex elevation, dual-plane policy change, knowledge taxonomy ownership change, and architecture reopening require Class A decision — CEO + executive council — with written record.
5. Delegation. Executives may delegate operational authority (Class C) to maintainers — not strategic authority.
6. Pre-incorporation. Until legal entity is formed per LEGAL_FOUNDATION.md, "executive" means designated company authority holders recorded in Accepted ownership documents — binding commercially only after counsel instruments exist.

---

Article VI — Decision Classes

Decision routing implements DECISION_FRAMEWORK.md. Summary — enforceable classes:

Class	Name	Scope	Default approver	AI agents
A	Strategic	New product line, repo, rebrand, constitution amendment, domain/market commitment	CEO + executive council	Forbidden
B	Structural	New platform repo, major portfolio charter, structural governance amendment	Architecture Council + CEO	Forbidden
C	Operational	In-charter feature, doc fix, minor semver within policy	Maintainer + ownership	Propose only
D	Automated	CI gates, SSOT guards, architecture tests, secret scans	System	Execute only

Rules:

1. Misclassified decisions are void until reclassified and re-approved.
2. Class A decisions must cite an Accepted company document or produce an amendment to one.
3. Emergency operational fixes do not bypass Class B for structural changes.
4. Recording: Class A → executive decision or ADR; Class B → ADR; Class C → PR or ticket; Class D → CI log.

---

Article VII — Single Source of Truth (SSOT)

1. Immutable rule (SSOT-01). Every information item in ZAIXOS has exactly one authority repository. Registry: SINGLE_SOURCE_OF_TRUTH.md — Accepted FROZEN.
2. One authority per concept. No duplicate constitution, strategy body, platform release record, or ADR text in registry or consumer repos.
3. Cite, don't copy. Consumers link to authority paths — they do not host authoritative copies. Permitted consumer indexes: citation README only (e.g. docs/company/README.md, docs/platform/README.md).
4. Registry role. Registry indexes metadata and pointers — never replaces authority content.
5. Violation remediation. SSOT violations are remediated before milestone exit evidence — not deferred. Architecture tests may enforce consumer stub-only directories.
6. Principle citation. SSOT behavior defaults: CP-18, CP-19 in COMPANY_PRINCIPLES.md.
7. Knowledge extension. SSOT-01 extends to knowledge classes — every knowledge class has exactly one authority owner per Article XXVIII. Operational detail: KNOWLEDGE_TAXONOMY_CHARTER.md.

---

Article VIII — Repository Authority

1. zaixos-company. Owns corporate identity, strategy, governance, brand architecture, legal foundation docs, Founder Model, experience doctrine, and knowledge taxonomy charter. Never hosts application code, infrastructure configs, or release artifacts.
2. zaixos-registry. Owns catalog structure, query specs, SSOT policy mirror, dependency rules index. Never owns strategy or product domain bodies.
3. zaixos-engineering-platform. Owns engineering methodology, runtime contracts, adapters, validation, platform release documentation. Never owns company strategy or product business logic.
4. Product repos. One authority repo per product. Own domain logic, product architecture, product releases. Never own company constitution copies or platform methodology copies.
5. New repositories. Creation requires Class A decision, portfolio entry (products/platforms), registry registration workflow (when operational), and evidence in executive decision record.
6. Forbidden repos without authorization. PRD-002–004 and future platform repos (design-system, ai-platform) remain unauthorized until Approved — see PRODUCT_PORTFOLIO.md.

---

Article IX — Platform Governance

1. Two platform classes.
   • ZEP — how software is engineered, validated, released.
   • Universal Business Platform (UBP) — composable frozen business capabilities (analytics, compliance, public experience, AI runtime, etc.).
2. Platform-before-duplication. Third similar capability across products elevates to shared platform — second similar capability triggers extraction plan (CP-07).
3. Platform-before-extraction. Shared engineering assets (release management, local dev, materialization) extract to ZEP before Product #2 authorization (M-12–M-14). Shared UX extracts to design-system (M-16). Shared AI assets extract to ai-platform (M-18). Copying into a second product before extraction is prohibited.
4. Freeze discipline. Frozen platform baselines are integration boundaries — services and products extend through contracts and approved modules, not by editing frozen cores (CP-09).
5. UBP posture. UBP is internal shared capability today; attachable platform medium-term; not a standalone customer-facing SKU without vertical product wrapper (OD-08).
6. UBP dedicated repo. Split of UBP to separate repository requires Class A decision with implementation evidence — not scheduled in this Constitution.
7. ZEP consumption. Every product consumer pins ZEP semver via .zaixos/platform.lock and runs ERP validation (CP-01).

---

Article X — Product Governance

1. One repo per product. Each product is an authority repository with Approved portfolio charter before repo creation (CP-13).
2. PRD-001 status. Dental Clinic Revenue Operating System — Charter Approved, Consumer #1, Official Product (OD-06). M-08 syncs portfolio documentation; substance is Approved.
3. Product duplication prohibition. No second product repository and no replication of Consumer #1 monolith pattern until M-24 factory certification passes (CP-26, RD-08). This is constitutional — not a guideline.
4. Strengthen-the-next rule. Each authorized product must increase future production capability — through platform extraction, registry registration, and reuse evidence — not merely add revenue (CP-15). Products that duplicate governance debt without extraction justification are not authorized.
5. Vertical depth. Products are vertical revenue operating systems with domain depth. Horizontal products (e.g. PRD-004 CRM) require explicit portfolio charter — Deferred until Approved (CP-14, OD-09).
6. CRM boundary. Dental CRM remains vertical capability in PRD-001 until portfolio opens horizontal CRM product. Shared CRM platform capability follows platform-before-duplication if third product requires it.
7. Inheritance. Products cite CP-{nn}, company values, and this Constitution — they do not restate company identity locally as authority.
8. Experience implementation. Products own surface implementation, domain workflows, and product-scoped experience constitutions — subordinate to Accepted company experience doctrine (Article II §7).

---

Article XI — AI Governance

1. Executive authority. AI systems and agents do not hold Class A or Class B authority. AI does not ratify company documents.
2. AI assists. AI assists engineering (Layer 1), product operations (Layer 2), and future factory automation (Layer 3) under governance — see OD-05.
3. Layer honesty. Layer 1 operational; Layer 2 partial; Layer 3 destination pre-M-24 — must be represented accurately in all company documents (CP-12).
4. Worker model. Product AI consumes Platform Contracts for live state — not documentation scraping alone (CP-11, ANPA).
5. Preview and audit. Consequential AI actions use preview-first semantics and audit trails where ANPA applies.
6. Human-in-the-loop. Consequential operational actions require human approval paths — not unbounded autonomous execution.
7. Anti-patterns (prohibited). Bolt-on chatbots without contract access; AI-generated company strategy treated as Accepted; agents approving new repos or product lines; MCP providers enabled without governance review.
8. Default posture. MCP disabled by default in consumer extensions; provider-agnostic routing; fail-closed session constraints via ERP.
9. Dual-surface harmonization. Prepared-context surfaces (structured admin, parallel workers, preview-safe hosts) and conversation-discovery surfaces (intent-led commercial discovery) are both valid under OD-05 Layers 1–2. Company tier defines accountability and proof requirements; product tier selects modality — per Accepted company experience doctrine.

---

Article XII — Engineering Governance

1. ZEP supremacy (engineering). All engineering methodology authority resides in ZEP — products consume, never duplicate (Article VIII).
2. Architecture tests. Architecture and boundary tests are merge gates — not negotiable for schedule (CP-02).
3. Modular monolith. Products default to modular monolith DDD structure — not microservices by default (CP-04).
4. Contract-first. Platform integration via public contracts and DTOs — no cross-module internal model imports (CP-05).
5. Additive evolution. Frozen layers evolve additively — not by silent redesign (CP-06).
6. Presentation layer. Business logic prohibited in controllers, Filament resources, Form Requests, and Blade views — enforced in product architecture policy.
7. Consumer extensions. Product-specific rules live in .zaixos/extensions/ — not ZEP core edits (CP-01, platform extension model).

---

Article XIII — Documentation Governance

1. Documentation is infrastructure. Governance docs, release records, and indexes are deliverables — not post-ship cleanup (CP-16).
2. Document states. Bootstrapped → Draft → Proposed → Accepted → Deprecated → Pointer only (historical cite-only — frozen content preserved). Only Accepted binds strategic decisions (CP-17).
3. Authorship. Executive authorship for identity, Founder Model, and strategy; platform maintainers for ZEP; product leads for product domain — each in authority repo only.
4. Amendment headers. Accepted documents increment version and record ratification date on amendment.
5. No silent paste. Changes to company authority are not silently pasted into product or platform repos — citation updates only.
6. Philosophical sources. ZAIXOS_MANIFESTO.md and ZAIXOS_COMPANY_DNA.md are pointer-only historical sources — absorbed into ZAIXOS_FOUNDER_MODEL.md (Accepted). Frozen v1.0 content preserved; root paths unchanged. Cite Founder Model — not Manifesto or DNA — for philosophical questions.

---

Article XIV — Quality Governance

1. Evidence before expansion. Quality of portfolio claims requires exit-criteria evidence — factory gates, test counts, certification reports — not narrative (Value 2).
2. Release evidence. Shipped scope requires release tags, manifests, checksums, and validation reports where release pipeline applies.
3. Factory certification. Product Factory claims require M-24 9/9 gates — current state 1/9 is not factory-operational.
4. Consumer #1 proof surface. Consumer #1 validates reuse hypotheses — factory authorization requires measured scores, not assumptions (CP-22).
5. Regression. SSOT, architecture, and ERP suites run on consumer CI — regression blocks release promotion per product policy.

---

Article XV — Security Governance

1. Fail-closed. Security and tenancy defaults fail closed — not open by convenience.
2. Secrets. Secrets never committed to git — per workspace security model reference in LEGAL_FOUNDATION.md.
3. Tenancy. Clinic-owned and tenant-scoped data follows product SaaS architecture — scoped queries mandatory.
4. Compliance module. Product implements regulatory constraints (e.g. regional healthcare advertising packs) — does not replace corporate legal counsel on entity compliance.
5. AI security. Disabled MCP by default; agent actions bounded by decision class; no exfiltration of secrets into prompts — per ERP and adapter policy.
6. Registry security. Registry holds no runtime secrets — indexes only.

---

Article XVI — Product Lifecycle

State	Meaning	Authorization
Deferred	Placeholder only — no repo, no hiring, no public commitment	Portfolio entry only
Charter Approved	Executive Approved charter — repo may exist	Class A + portfolio
Active	Commercially or operationally deployed product	Evidence recorded
Mature	Stable maintenance mode	Portfolio review
Deprecated	Wind-down — pointer to successor	Class A

Rules:

1. PRD-001: Charter Approved / Active engineering — pre-revenue commercial state documented honestly.
2. No lifecycle promotion to Active commercial without customer or deployment evidence where claimed.
3. Product retirement requires Class A — domain data and SSOT pointers updated in registry when operational.
4. Product #2 lifecycle begins only after M-24 and M-25 authorization — not before.

---

Article XVII — Platform Lifecycle

State	Meaning
Specified	Documented in architecture — not necessarily extracted
Pinned	Consumer lock to semver (ZEP)
Frozen	Baseline tag — integration boundary
Extracted	Shared package or repo — attachable by multiple consumers
Deprecated	Successor documented — additive migration only

Rules:

1. ZEP @ 1.0.0 GA is Pinned and Frozen for engineering governance.
2. UBP modules frozen @ v4.2-public-experience-platform chain inside Consumer #1 until extraction.
3. Future platforms (design-system, ai-platform) require Class B repo ratification + registry registration.
4. Platform deprecation requires semver major or executive Class A — not silent removal of contracts.

---

Article XVIII — Architectural Integrity

1. Architecture closed. Four-repository hierarchy and SSOT policy are frozen — reopening requires Class A with implementation evidence (Blueprint Part 14 BINDING).
2. No frozen platform redesign. Zero-byte-change expectation on frozen platform paths unless authorized phase explicitly modifies — verified by architecture tests in Consumer #1.
3. Module boundaries. Products maintain bounded contexts — cross-module access via contracts, events, shared kernel abstractions only.
4. Skip-layer prohibition. AI platforms and products consume platform via contracts — do not bypass to infrastructure layers.
5. Integrity over speed. Architectural integrity violations are remediated before milestone promotion — not documented as permanent exceptions without Class A.

---

Article XIX — Company Assets

1. Reusable assets belong to the company/platform layer — not to a single product repository permanently. Includes: ZEP methodology, ERP, adapters, shared platform modules, design system (when extracted), AI platform assets (when extracted), registry specifications, and Accepted company documentation.
2. Product assets. Domain-specific code, vertical business rules, and product release records belong to product authority repos.
3. Extraction duty. When reusable assets are identified in a product, the company must plan extraction before authorizing duplication in another product (Article IX).
4. No permanent product capture. Engineering release tooling, local dev orchestration, and platform methodology shall not remain product-exclusive beyond M-14 authorization window without Class A exception.
5. Registry as asset index. When operational, registry records asset ownership and consumer edges — not asset bodies.

---

Article XX — Intellectual Property

1. Intent. IP in company, platform, and product repositories is intended to be held by ZAIXOS corporate entity when formed — per IP_STRATEGY.md.
2. Pre-incorporation. Until incorporation, IP assignment follows founder/contractor agreements outside git — this Constitution does not create legal assignment.
3. Open source. No open-source release of core platforms without Class A and legal review — framework only in IP_STRATEGY bootstrap.
4. Consumer lock. ZEP consumed under Composer license terms — company Constitution does not alter package license.
5. AI outputs. AI-generated code and docs remain subject to human review, license compliance, and IP policy — not autonomous release.

---

Article XXI — Amendment Process

1. Who may amend. This Constitution amends only by Class A decision — CEO + executive council.
2. Proposal requirements. Written proposal including: article affected, rationale, impact on products/platforms/registry, migration steps, and version bump (minor clarification vs major structural).
3. Legal review. Amendments affecting legal articles, IP, or commercial commitments require legal counsel review before Accepted.
4. Identity documents. Vision, mission, values, and principles amend through their own ratification process — must remain consistent with this Constitution or Constitution must be amended first.
5. Founder Model. Philosophical apex amends through Class A ratification — must remain consistent with this Constitution on governance; Constitution amendment required if governance conflict arises.
6. Platform/product sync. After Constitution amendment, affected platform charters and product architecture constitutions update citations within 90 days or next release cycle — whichever is sooner.
7. No silent amendment. Version history in this document records every Accepted change.

---

Article XXII — Ratification Process

1. First Accepted baseline. This document v1.0 became binding when CEO recorded: Status: Accepted and Ratified: {date} in header.
2. Identity pack ratification. Vision, Mission, Values, Principles may ratify in parallel or sequence — Constitution may ratify first or after identity pack; all must be Accepted before M-06+ milestones claim company authorship complete per blueprint.
3. Subordinate documents. Governance, strategy, brand, and legal documents ratify per ownership table in CHARTER.md — each records own ratification date.
4. Conflict at ratification. If ratification review finds conflict between identity documents and this Constitution, Constitution prevails on governance; identity documents must be revised before Accepted.
5. Publication. Accepted status is recorded in document header and version history — not chat or oral approval alone.
6. Constitutional amendment ratification. v1.1 and subsequent amendments require Class A executive decision record citing affected articles — CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md for v1.1.

---

Article XXIII — Conflict Resolution

1. Corporate vs product. On strategic questions under Plane A, company Accepted documents prevail over product docs.
2. Corporate vs platform. Company strategy prevails over ZEP on why and portfolio; ZEP prevails on engineering methodology where not contradicted by Accepted company engineering policy.
3. SSOT vs convenience. SSOT prevails over speed — duplicate authority is not a valid conflict resolution.
4. Release vs future. Frozen release records prevail on shipped scope under Plane B; company strategy prevails on future direction under Plane A.
5. Plane selection. Before resolving any conflict, identify authority plane per Article XXVII — corporate/strategic questions use Plane A; engineering session questions use Plane B.
6. Escalation path. Contributor → maintainer → Architecture Council / executive council per DECISION_FRAMEWORK.md.
7. Constitutional conflict. Disputes about this Constitution's meaning escalate to CEO with written opinion from Knowledge Architect and Repository Architect.
8. Portfolio charter conflict. Official Product ratification supersedes bootstrapped portfolio placeholders until portfolio doc synced (OD-06).
9. Knowledge layer disputes. Cross-layer knowledge ownership disputes escalate to Architecture Council recommendation; CEO Class A if Article XXVIII assignment changes.

---

Article XXIV — Future Expansion Rules

1. Product #2. Forbidden before M-24 factory certification — then M-25 proof only. No exception without Class A Constitution amendment.
2. New products. Require: Approved portfolio entry, domain strategy alignment, Architecture Council review, registry registration (when A0 operational), ZEP pin, SSOT citation model — in that dependency order per EXECUTION_CONTRACT.
3. New platforms. Require Class B + executive ratification — design-system, ai-platform, infrastructure per blueprint.
4. Geography expansion. New commercial regions require Accepted DOMAIN_STRATEGY and GO_TO_MARKET amendment — not Constitution amendment. GCC/Saudi not selected until explicitly Approved with evidence (OD-04).
5. Marketplace / developer platform. Future layers per CORPORATE_ARCHITECTURE — Class A when proposed.
6. Factory claims. Public or internal claims of "Product Factory" operational status require M-24 evidence attached.
7. Simulation ≠ commitment. Blueprint Product #10/#20 and Future Vision simulations are planning models — not authorization to create repos.

---

Article XXV — Identity Document Registry

Document	Role	Status
COMPANY_VISION.md	Horizon — where we are going	Accepted
COMPANY_MISSION.md	Purpose — what we do daily	Accepted
COMPANY_VALUES.md	Behavioral constraints	Accepted
COMPANY_PRINCIPLES.md	Decision defaults CP-01–CP-28	Accepted
ZAIXOS_FOUNDER_MODEL.md	Philosophical apex (WHY) — belief, permanence, 20-year identity signature	Accepted
ZAIXOS_MANIFESTO.md	Philosophical source — absorbed into Founder Model	Pointer only — frozen v1.0
ZAIXOS_COMPANY_DNA.md	DNA source — absorbed into Founder Model	Pointer only — frozen v1.0
COMPANY_EXPERIENCE_DOCTRINE.md	Cross-product experience principles · Living Showcase proof doctrine	Accepted
KNOWLEDGE_TAXONOMY_CHARTER.md	Knowledge class ownership — operationalizes Article XXVIII	Accepted

Split-apex rule: Founder Model is supreme on philosophical questions when Accepted. This Constitution is supreme on governance questions. Manifesto and DNA are never parallel philosophical apex after Founder Model Accepted.

This Constitution is Accepted and binds interpretation of all identity and governance documents. Ratification: IDENTITY_RATIFICATION.md · Amendment: CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md.

---

Article XXVI — Continuity

1. Permanent corporate memory. zaixos-company survives product launches, sunsets, and platform version changes — per CHARTER.
2. Documentation-only company repo. No application deploys from this repository.
3. Succession. Executive succession and continuity details amend via Accepted GOVERNANCE_MODEL.md and legal instruments — not improvised at transition.
4. Deprecation. This Constitution is never deleted — only superseded by newer Accepted version with pointer.

---

Article XXVII — Dual Authority Planes

1. Permanent dual planes. ZAIXOS operates two authority planes that coexist permanently and must not be merged — authorized by CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md CD-02.

Plane A — Corporate Authority Plane

Applies to: Strategy · portfolio · brand architecture · company-level AI posture · identity · philosophical questions · amendment · ratification · executive decisions · experience doctrine · knowledge taxonomy policy.

Precedence (highest first):

COMPANY_CONSTITUTION (governance)
        ↓
ZAIXOS_FOUNDER_MODEL (philosophical — when Accepted)
        ↓
Identity documents (Vision · Mission · Values · Principles)
        ↓
Accepted company strategy · brand · governance · legal docs
        ↓
Executive resolutions (OD-01–OD-10 · CD-001+)
        ↓
Platform authority (scoped platform constitutions)
        ↓
Product authority (admitted PRD only)

Conflict rule (Plane A): Corporate strategy and future work prevail over frozen release baselines. Shipped frozen scope prevails on what was frozen — per Article XXIII §4.

Plane B — Runtime / Session Authority Plane

Applies to: Engineering sessions · AI-assisted implementation · materialized adapter workspaces · consumer repos under active development · session bootstrap via START_HERE.md.

Precedence (highest first):

docs/releases/ frozen baselines
        ↓
Architecture constitution (PROJECT_CONSTITUTION · MODULE_BOUNDARIES)
        ↓
ERP / EOS (docs/development/ · ZEP contracts)
        ↓
Company authority (zaixos-company/ — cite-only in session)
        ↓
Product authority (admitted PRD only)
        ↓
knowledge/ operational (product-scoped)

Normative specification: AUTHORITY_INDEX_SPECIFICATION.md §Precedence.

Plane selection rule (mandatory)

Question type	Plane	Resolver
Should we build X? · Admit product? · Rebrand? · Amend constitution?	Plane A — Corporate	CEO · executive council · ratification
Does this change violate frozen module? · Which baseline governs this PR? · Session allowlist?	Plane B — Runtime / Session	Release tag · architecture tests · Authority Index
Corporate strategy says build X · frozen release forbids editing module Y	Both — apply conflict rule	Future work → Plane A; shipped frozen scope → Plane B

Coexistence rules

1. Plane A does not override Plane B on shipped engineering scope without Class A release reopening.
2. Plane B does not override Plane A on portfolio, identity, or strategic authorization.
3. Runtime Index stores ranks and paths only — not document bodies.
4. START_HERE.md operationalizes Plane B entry — it does not restate Plane A bodies.
5. Dual-plane doctrine is intentional architecture — not duplication to be eliminated.

---

Article XXVIII — Knowledge Taxonomy

1. Extension of SSOT. Every knowledge class in the ZAIXOS workspace has exactly one authority owner — extending SSOT-01 (Article VII) without amending SINGLE_SOURCE_OF_TRUTH.md. Authorized by CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md CD-04.

Layer assignment

Layer	Repository / plane	Owns	Never owns
Company	zaixos-company	Corporate policy · strategic knowledge framework · experience doctrine · AI strategy · governance decision knowledge · ratification records · executive resolutions · Founder Model	Domain business records · prompt source · intelligence store schema · session state
Registry	zaixos-registry	Index metadata · repository classification · dependency graph pointers · SSOT certification records · workspace topology index	Strategy bodies · product domain knowledge · platform implementation · document bodies
Platforms	zaixos-engineering-platform · zaixos-design-system · zaixos-ai-platform · zaixos-intelligence-platform · future PL-xxx	Platform methodology · contracts · ADRs · platform constitutions · PL-003 prompt/agent/eval registry contracts · PL-004 intelligence taxonomy · PL-002 design tokens · ZEP ERP/EOS specs	Company strategy · product domain truth · customer PII · corporate identity
Products	One repo per admitted PRD	Domain operational knowledge · runbooks · product knowledge/ · compliance playbooks · product ADRs · vertical business semantics	Company strategy copies · platform contract definitions · registry index bodies
Runtime	Session plane · materialized adapters · START_HERE bootstrap	Ephemeral session state · authority index snapshot (≤4 KB pointers) · context pack selection · allowlist enforcement · runtime memory (non-authoritative)	Authoritative strategy · domain truth · permanent knowledge bodies · constitutional text

Knowledge class map

Knowledge class	Single owner	Canonical location pattern
Corporate strategy	Company	zaixos-company/docs/strategy/
Corporate governance	Company	zaixos-company/docs/governance/
Philosophical belief	Company	ZAIXOS_FOUNDER_MODEL.md (when Accepted)
Company experience doctrine	Company	docs/company/COMPANY_EXPERIENCE_DOCTRINE.md
Knowledge taxonomy policy	Company	docs/company/KNOWLEDGE_TAXONOMY_CHARTER.md
Workspace index	Registry	zaixos-registry/docs/indexes/
SSOT rules	Registry	zaixos-registry/docs/architecture/SINGLE_SOURCE_OF_TRUTH.md
Engineering methodology	Platform (ZEP)	zaixos-engineering-platform/core/ · docs/development/
AI asset contracts	Platform (PL-003)	zaixos-ai-platform/contracts/ · packages
Intelligence contracts	Platform (PL-004)	zaixos-intelligence-platform · Zaixos\Zip\Contracts\
Design system	Platform (PL-002)	zaixos-design-system/
Domain business knowledge	Product	{product-repo}/knowledge/ · product docs
Session pointers	Runtime	authority-index.snapshot.json · adapter context index
Session task memory	Runtime	Ephemeral — not SSOT · never authoritative
Historical evidence	Company (Historical tier)	Ratification reports · audits · discovery — non-authority

Binding rules

1. Registry indexes — never owns bodies.
2. Products cite platform and company knowledge — never copy authoritative bodies.
3. Runtime loads pointers and packs — never becomes knowledge authority of record.
4. PL-004 intelligence store owns derived intelligence schema — not authoritative business records.
5. Cross-layer disputes escalate per Article XXIII §9.
6. Operational detail lives in Accepted KNOWLEDGE_TAXONOMY_CHARTER.md — subordinate to this Article.

---

Cross References

Document	Relationship
CHARTER.md	Repository charter — subordinate on governance
CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md	Class A constitutional resolutions CD-01–CD-04 — authorizes v1.1
ZAIXOS_FOUNDER_MODEL.md	Philosophical apex — Accepted
COMPANY_EXPERIENCE_DOCTRINE.md	Company experience authority — Accepted
KNOWLEDGE_TAXONOMY_CHARTER.md	Knowledge taxonomy operational charter — Accepted
WORKSPACE_BASELINE.md	Ratified four-repo baseline
EXECUTION_CONTRACT.md	Milestone execution order
START_HERE.md	Plane B operational entry
AUTHORITY_INDEX_SPECIFICATION.md	Plane B precedence specification
../governance/DECISION_FRAMEWORK.md	Decision class detail
../governance/GOVERNANCE_MODEL.md	Governance forums
../strategy/PRODUCT_PORTFOLIO.md	Portfolio gating
../legal/LEGAL_FOUNDATION.md	Legal entity — parallel track

---

Version History

Version	Date	Change
0.1	2026-06-30	Bootstrap — structure only
1.0	2026-06-30	M-05.5 — authoritative constitution authored
1.0.1	2026-06-30	M-05.6 — Accepted · IDENTITY_RATIFICATION.md
1.1	2026-07-03	Constitutional amendment — split-apex · dual authority planes · knowledge taxonomy · company experience doctrine · CD-001_CLASS_A_CONSTITUTIONAL_RESOLUTION.md
1.1.1	2026-07-03	Constitutional Completion Package — Founder Model · Experience Doctrine · Knowledge Taxonomy Charter Accepted · Manifesto/DNA pointer-only

---

Supreme company governance authority when Accepted. Philosophical supremacy: Founder Model when Accepted. Not a legal incorporation document. Counsel required for entity binding.