== OVERVIEW & SCOPE / MASTER ARCHITECTURE INDEX == 600 601 ### Phase 01 - Overview & Scope 602 Authority set: 603 - master_architecture_index.md 604 - project_scope_canonical.json 605 606 Supporting context: 607 - devon_panel_chat_checkpoint.md 608 609 ### Phase 02 - Architecture & Engineering Canon 610 Authority files: 611 - cas.md 612 - cgs.md 613 - acs.md 614 - css.md 615 - ncs.md 616 - sts.md 617 - brps.md 618 - cdms.md 619 620 Satellite files: 621 - ris.md 622 - ofms.md 623 624 #### Phase 02 Process-Spec 625 626 Purpose: 627 canonize the architecture and engineering foundation that governs structure, contracts, naming, state legitimacy, deployment structure and contextual boundaries. 628 629 Mandatory implementation items: 630 631 ##### P02-01 Cognitive Architecture Spec 632 - authority_owner: cas.md 633 - canonical_role: sovereign architecture definition 634 - why_this_item_exists: define the cognitive architecture baseline before downstream orchestration, runtime and monitoring exist 635 - required_before: 636 - cfc.md 637 - ofms.md 638 - operator/runtime implementation 639 - hard_dependencies: 640 - master_architecture_index.md 641 - project_scope_canonical.json 642 - install_steps: 643 1. register cas.md in the canonical root 644 2. bind the file to Phase 02 and architecture layer 645 3. expose the file to the Documentation Hub 646 - config_steps: 647 1. define architecture scope 648 2. define core domains and structural boundaries 649 3. define sovereignty versus allowed satellite references 650 - validation_gates: 651 - file exists in /panel/data 652 - file is registered in the master 653 - category binding is correct 654 - DH loads the file without error 655 - observable_evidence: 656 - /panel/data/cas.md exists 657 - DH renders CAS under Architecture & Engineering Canon 658 - failure_modes: 659 - missing file 660 - wrong phase binding 661 - satellite redefining sovereign meaning 662 - done_when: 663 - CAS is registered, readable, categorized and treated as sovereign authority 664 - feeds_operational_ui: 665 - category cards 666 - evidence drawer 667 - dependency drawer 668 - phase registry view 669 670 ##### P02-02 Governance Model 671 - authority_owner: cgs.md 672 - canonical_role: governance authority 673 - why_this_item_exists: define governance rules for architecture, engineering and canonical control 674 - required_before: 675 - structured contracts 676 - runtime enforcement 677 - hard_dependencies: 678 - cas.md 679 - master_architecture_index.md 680 - install_steps: 681 1. register cgs.md in canonical root 682 2. bind the file to Phase 02 and architecture layer 683 3. expose governance authority in DH 684 - config_steps: 685 1. define governance scope 686 2. define rule ownership 687 3. define what satellites may not override 688 - validation_gates: 689 - file exists 690 - file is registered 691 - file is mapped to Phase 02 692 - observable_evidence: 693 - /panel/data/cgs.md exists 694 - DH relation map shows governance role 695 - failure_modes: 696 - governance file missing 697 - duplicated authority 698 - governance scope undefined 699 - done_when: 700 - governance authority is materialized and bound to Phase 02 701 - feeds_operational_ui: 702 - contract drawer 703 - dependency drawer 704 - evidence drawer 705 706 ##### P02-03 Artifact Canon and Structure 707 - authority_owner: acs.md 708 - canonical_role: artifact structure authority 709 - why_this_item_exists: define how canonical artifacts are shaped, separated and registered 710 - required_before: 711 - structured json artifacts 712 - DH/UI artifact mapping 713 - hard_dependencies: 714 - cgs.md 715 - master_architecture_index.md 716 - install_steps: 717 1. register acs.md 718 2. bind artifact structure to architecture layer 719 - config_steps: 720 1. define artifact classes 721 2. define authority versus satellite separation 722 3. define structural expectations 723 - validation_gates: 724 - file exists 725 - file is registered 726 - structure rules are referenced by dependent artifacts 727 - observable_evidence: 728 - /panel/data/acs.md exists 729 - dependent docs and jsons remain structurally coherent 730 - failure_modes: 731 - structure undefined 732 - mixed authority boundaries 733 - artifact overlap 734 - done_when: 735 - artifact structure is explicit and enforceable 736 - feeds_operational_ui: 737 - artifact view 738 - contract view 739 - validation timeline 740 741 ##### P02-04 Contracts and Schemas 742 - authority_owner: css.md 743 - canonical_role: contracts and schemas authority 744 - why_this_item_exists: define machine-readable interfaces and operational schema boundaries 745 - required_before: 746 - panel_data_contract.json 747 - panel_component_contract.json 748 - panel_sync_contract.json 749 - card_contract_minimums.json 750 - hard_dependencies: 751 - acs.md 752 - cgs.md 753 - install_steps: 754 1. register css.md 755 2. register contract json artifacts 756 3. bind them to Phase 02 757 - config_steps: 758 1. define required fields 759 2. define join rules 760 3. define status/data resolution rules == CANONICAL PROCESS MODEL == 1430 This section defines the mandatory process model that every canonical category, section, card and implementation item must follow. 1431 1432 Purpose: 1433 turn canonical documentation into an executable process reference for the Documentation Hub, Operator Panel and future real-time build monitoring. 1434 1435 Rule: 1436 a category is not sufficiently documented if it only declares files, layers, phase origin or dependencies. 1437 A category becomes operationally valid only when its process is explicitly documented step by step. 1438 1439 ### 13.0 Canonical execution hierarchy 1440 1441 The canonical execution hierarchy for Devon documentation, Documentation Hub and Operator Panel is: 1442 1443 1. Phase 1444 2. Category 1445 3. Process bucket 1446 4. Item 1447 1448 Definitions: 1449 1450 ### Canonical Navigation and Execution Hierarchy 1451 1452 The canonical hierarchy for Devon documentation, execution mapping and panel rendering is: 1453 1454 1. Phase 1455 2. Category 1456 3. Subcategory 1457 4. Bucket 1458 5. Item 1459 1460 #### Subcategory 1461 A Subcategory is the process-oriented subdivision inside a Category. 1462 1463 Subcategories are additive organizational layers and do not replace Phase or Category sovereignty. 1464 1465 Canonical subcategories are: 1466 - Prerequisites 1467 - Installation 1468 - Configuration 1469 - Validation 1470 - Observable Evidence 1471 - Failure Modes & Recovery 1472 - Completion & Promotion 1473 1474 #### Bucket 1475 A Bucket is a grouped execution container inside a Subcategory. 1476 1477 Buckets belong to a Subcategory and may not be attached directly to a Phase. 1478 1479 #### Item 1480 An Item is the smallest executable process unit inside a Bucket. 1481 1482 Items belong to a Bucket and represent the lowest executable unit in the canonical workflow model. 1483 1484 #### Structural Adaptation Rule 1485 The existing sovereign structure remains valid: 1486 1487 - Phase remains the primary macro execution layer 1488 - Category remains the second-level sovereign document grouping 1489 1490 The hierarchy is extended, not replaced: 1491 1492 - Phase 1493 - Category 1494 - Subcategory 1495 - Bucket 1496 - Item 1497 1498 Rendering contract: 1499 1500 - left navigation = Phase -> Category 1501 - center workflow = Subcategory -> Bucket -> Item 1502 1503 Subcategories must not be promoted to primary left navigation unless a future canonical navigation contract explicitly changes that rule. 1504 1505 1506 #### Phase 1507 A Phase is the macro execution stage shown in left navigation. 1508 It preserves installation/configuration order and canonical progression. 1509 Examples: 1510 - Overview & Scope 1511 - Architecture & Engineering Canon 1512 - Cognitive Flow Canon 1513 - Containerization Canon 1514 1515 #### Category 1516 A Category is a sovereign or supporting document group inside a selected Phase. 1517 Examples inside a phase: 1518 - Master Architecture Index 1519 - Panel Manifest 1520 - Project Scope Canonical 1521 - Contracts and Schemas 1522 - Governance Model 1523 1524 Rule: 1525 a category is not the phase itself. 1526 A phase contains categories. 1527 1528 #### Process bucket 1529 A Process bucket is the ordered operational subdivision inside a category. 1530 Mandatory canonical buckets are: 1531 1532 1. prerequisites 1533 2. installation 1534 3. configuration 1535 4. validation 1536 5. observable_evidence 1537 6. failure_modes_recovery 1538 7. completion_promotion 1539 1540 Rule: 1541 process buckets must appear in execution order. 1542 The Documentation Hub and Operator Panel may summarize them visually, but may not change their order. 1543 1544 #### Item 1545 An Item is the smallest executable process unit inside a process bucket. 1546 An item must describe: 1547 - what must be done 1548 - in which order 1549 - what input is required 1550 - what output is expected 1551 - how to validate it 1552 - what evidence proves it 1553 - what failure can occur 1554 - what recovery action is allowed 1555 1556 Example hierarchy: 1557 Phase: 1558 - Overview & Scope 1559 1560 Category: 1561 - Project Scope Canonical 1562 1563 Process buckets: 1564 - prerequisites 1565 - installation 1566 - configuration 1567 - validation 1568 - observable_evidence 1569 - failure_modes_recovery 1570 - completion_promotion 1571 1572 Items: 1573 - register file 1574 - bind file to phase 1575 - expose file in DH 1576 - validate source load 1577 - confirm category ownership 1578 1579 Canonical rule: 1580 left navigation = phase registry. 1581 center workflow = categories inside the selected phase. 1582 category body = ordered process buckets. 1583 bucket body = executable items. 1584 1585 ### 13.1 Mandatory process-spec fields 1586 1587 Every canonical implementation item must define, at minimum: 1588 1589 1. identity 1590 - canonical_layer 1591 - phase_origin 1592 - category_id 1593 - section_id 1594 - card_id 1595 - item_id 1596 - authority_owner 1597 1598 2. process purpose 1599 - objective 1600 - canonical_role 1601 - why_this_item_exists 1602 1603 3. prerequisites 1604 - required_before 1605 - blockers 1606 - hard_dependencies 1607 - allowed_preconditions 1608 1609 4. installation process 1610 - install_steps 1611 - installation_order 1612 - installation_commands_or_actions 1613 - expected_install_result 1614 1615 5. configuration process 1616 - config_steps 1617 - configuration_inputs 1618 - configuration_outputs 1619 - expected_configuration_result 1620 1621 6. validation process 1622 - validation_gates 1623 - checks 1624 - pass_criteria 1625 - fail_criteria 1626 - missing_criteria 1627 1628 7. evidence model 1629 - observable_evidence 1630 - evidence_source 1631 - evidence_path_or_endpoint 1632 - evidence_frequency 1633 - last_validation_pointer 1634 1635 8. failure model 1636 - failure_modes 1637 - probable_root_causes 1638 - recovery_actions 1639 - rollback_or_safe_state 1640 1641 9. completion model 1642 - done_when 1643 - not_done_when 1644 - promotion_gate 1645 - canonization_gate 1646 1647 10. operational monitoring contract 1648 - feeds_operational_ui 1649 - runtime_monitoring_hooks 1650 - timeline_events 1651 - status_counter_impact 1652 - dependency_impact 1653 1654 ### 13.2 Canonical process rules 1655 1656 1. No implementation item may be treated as complete without explicit done_when criteria. 1657 2. No step may be considered valid without observable evidence. 1658 3. Installation and configuration must remain separated when they are materially different actions. 1659 4. Validation must be explicit and may not be inferred from file existence alone unless the item contract says so. 1660 5. Runtime monitoring may report process state, but may not redefine the canonical process contract. 1661 6. The Documentation Hub may summarize the process, but the master index remains the supreme authority. 1662 7. The Operator Panel may visualize process execution, but may not invent missing steps. 1663 8. If a process field is absent, its status is MISSING. 1664 9. If an item cannot expose evidence, it cannot produce PASS. 1665 10. If a category has files but no process spec, the category is documentation-incomplete. 1666 1667 ### 13.3 Required DH and UI alignment 1668 1669 Audit split rule: 1670 1671 Documentation Hub responsibilities: 1672 - canonical/document audit 1673 - coverage against this master index 1674 - authority ownership visibility 1675 - phase binding visibility 1676 - layer binding visibility 1677 - depends_on / used_by visibility 1678 - sovereign versus satellite separation visibility 1679 - documentation completion gap visibility 1680 - PASS / FAIL / MISSING only for documentary and canonical evidence 1681 1682 Operator Panel responsibilities: 1683 - operational/runtime audit 1684 - real implementation state 1685 - real server/runtime evidence 1686 - health, containers and process telemetry 1687 - pipeline execution evidence 1688 - sync/export/runtime bridge evidence 1689 - PASS / FAIL / MISSING only for materially observable execution evidence 1690 1691 Boundary rule: 1692 - Documentation Hub may summarize canonical structure, but may not claim runtime implementation as complete unless runtime evidence is exposed through the operational side. 1693 - Operator Panel may summarize runtime state, but may not redefine canonical ownership, precedence, phase order or documentary authority. 1694 - A runtime-relevant concept is only fully auditable when its canonical definition exists in the master/documentation side and its material evidence exists in the operational side. 1695 1696 The Documentation Hub must eventually expose, per category: 1697 1698 - required_before 1699 - install_steps 1700 - config_steps 1701 - validation_gates 1702 - observable_evidence 1703 - failure_modes 1704 - done_when 1705 - feeds_operational_ui 1706 1707 The Operator Panel must eventually consume the same process model for: 1708 1709 - monitoring sequence 1710 - timeline events 1711 - evidence drawers 1712 - contract drawers 1713 - dependency drawers 1714 - status counters 1715 - real-time runtime tracking