```text ============================================================ LIBER MACHINA EX ROTAE EXTRACTIO AGLA / MACHINE STACK — ROTA EXTRACTION SUBSTRATE Version: 0.1.0-LIBER-MACHINA-EX-ROTAE-EXTRACTIO Status: DRAFT — EXTRACTION SUBSTRATE / SCHEMA-GOVERNANCE LIBER Authority: USER / HUMAN CONTROL PLANE LOCAL CONTROL PLANE — GENERAL AGLA / KABBALAH STACK Class: AGLA / LIBER / MACHINA / ROTAE / EXTRACTION / SCHEMA_SUBSTRATE / MACHINE_TRANSLATION Scope: • formalize the ROTA machine extraction substrate • convert textual ROTAS artifacts into machine-state structures • preserve ROTA / RODA / CASA / OPERATOR / PLACEMENT distinction • preserve TENET / ROTAS / AREPO / OPERA / SATOR class separation • define extraction order from textual artifacts into schema fields • preserve order pluralism: source order generation order display order slot order active traversal order • define carrier package requirements • define visual / admission / execution state separation • define loci, cameras, chambers, multiplicatio, and traversal surfaces • prepare future pentagram: TENET MACHINA EX ROTA AREPO MACHINA EX ROTA OPERA MACHINA EX ROTA ROTA MACHINA EX ROTA SATOR MACHINA EX ROTA Mutation Policy: VERSION-CONTROLLED ONLY ============================================================ ============================================================ 0. PATCH STATUS ============================================================ This LIBER is generated from: AGLA ROTA MACHINE SCHEMA v0.1.0-DRAFT Control result: The schema is accepted as a valid draft substrate for machine-readable ROTA extraction. Patch status: ACCEPTED AS DRAFT NOT CANONICAL READY FOR FORMALIZATION AS LIBER Critical inherited laws: • ROTA ≠ RODA • RODA ≠ CASA • CASA ≠ OPERATOR • OPERATOR ≠ PLACEMENT • PLACEMENT ≠ CONNECTION • VISUAL_BINDING ≠ EXECUTION These distinctions are already stabilized in ROTA NETIVOT v0.1.1, where ROTA is machine object, RODA is annular component, CASA is local positional slot, OPERATOR is content placed into CASA by later placement, and VISUAL_BINDING is optional representation rather than execution. :contentReference[oaicite:0]{index=0} This LIBER also inherits the TENET SEPHIROT correction that a position or slot must not collapse into symbolic essence, operator, number-quality, token-carrier, or filled content. :contentReference[oaicite:1]{index=1} ============================================================ I. PURPOSE ============================================================ LIBER MACHINA EX ROTAE EXTRACTIO defines the extraction substrate by which textual AGLA artifacts may be parsed into a ROTA machine-state representation. It exists because many AGLA artifacts define structures in human-readable text, but future tooling requires machine-readable forms for: • Godot • VS Code • API services • CLI tools • web applications • local parsers • visual ROTA machines • traversal interfaces • machine validation • interactive operator systems This LIBER does not execute OPERA. This LIBER does not define canon. This LIBER defines: how ROTA-relevant textual information may be extracted, represented, validated, and kept structurally non-collapsed. Its primary target is not one specific ROTA. Its primary target is: ROTA MACHINE EXTRACTION AS A GENERAL PROCEDURE ============================================================ II. ROOT CLASS SEPARATION ============================================================ The extraction model must preserve the five-class stack distinction: ------------------------------------------------------------ TENET ------------------------------------------------------------ TENET defines: • doctrine • principial law • invariants • non-collapse constraints • admissible conceptual boundaries TENET does not define: • visual placement • active traversal • execution state • concrete machine geometry by default ------------------------------------------------------------ ROTAS ------------------------------------------------------------ ROTAS defines: • ROTA structure • RODAE • CASAE • loci • chambers • cameras • adjacency • traversal body • visual binding when declared • display order • structural topology ROTAS is the primary source class for machine extraction. Formula: ROTAS → MACHINE BODY ------------------------------------------------------------ AREPO ------------------------------------------------------------ AREPO defines: • admission law • input admissibility • blocking conditions • boundary checks • prerequisites for OPERA execution AREPO does not execute. Formula: AREPO → ADMISSION STATE ------------------------------------------------------------ OPERA ------------------------------------------------------------ OPERA defines: • executable procedure • transformation • operation • analytic sequence • process discipline OPERA does not become visual selection. Formula: OPERA → EXECUTION STATE ------------------------------------------------------------ SATOR ------------------------------------------------------------ SATOR defines: • mediation • output discipline • response law • uncertainty display • serialization • user-facing explanation Formula: SATOR → OUTPUT / MEDIATION STATE ============================================================ III. TERMINOLOGY LAW ============================================================ ------------------------------------------------------------ III.1 ROTAS / ROTA / RODAE ------------------------------------------------------------ ROTAS = parent class for ROTA artifacts ROTA = a traversable machine object belonging to ROTAS ROTAE = plural of ROTA ------------------------------------------------------------ III.2 RODA / WHEEL ------------------------------------------------------------ RODA / WHEEL = an annular positional component inside a ROTA Terminology policy: Prefer RODA / WHEEL. Avoid “ring” as canonical term because “ring” has separate use in 3D mesh topology and may collapse with edge-loop / mesh-ring terminology. Allowed: ring as informal visual gloss only. Canonical: RODA / WHEEL ------------------------------------------------------------ III.3 CASA / HOUSE ------------------------------------------------------------ CASA / HOUSE = local slot inside a RODA A CASA may receive: • operator placement • empty slot status • identity status • locus status • camera status • chamber status But: CASA ≠ OPERATOR ------------------------------------------------------------ III.4 OPERATOR ------------------------------------------------------------ OPERATOR = carrier or operative content allocated to a CASA through explicit PLACEMENT An OPERATOR may have: • ordinal • token • label • translation • carrier package • parent operator • specificity level • operative status But: OPERATOR ≠ CASA OPERATOR ORDINAL ≠ HOUSE ORDINAL by default ------------------------------------------------------------ III.5 PLACEMENT ------------------------------------------------------------ PLACEMENT = explicit binding of OPERATOR to CASA PLACEMENT is the critical non-collapse table. It records separately: • operator_ref • wheel_ref • house_ref • operator_ordinal • house_ordinal • ordinal_relation Therefore: operator_ordinal equals house_ordinal only when explicitly declared. ------------------------------------------------------------ III.6 CONNECTION ------------------------------------------------------------ CONNECTION = traversable relation between structural references Possible connection types include: • circumferential • radial_parent_child • direct_transversal • wheel_alignment • wheel_overlay • identity_axis • locus_axis • chamber_transition • camera_transition ------------------------------------------------------------ III.7 TRAVERSAL ------------------------------------------------------------ TRAVERSAL = lawful movement through houses, wheels, placements, loci, chambers, cameras, or connections TRAVERSAL may be visual, structural, admissibility-bound, or executional. But: traversal selection ≠ OPERA execution ------------------------------------------------------------ III.8 VISUAL_BINDING ------------------------------------------------------------ VISUAL_BINDING = optional representation layer It may bind: • Godot node • web node • SVG element • 2D coordinate • 3D coordinate • polar coordinate • cylindrical coordinate • camera surface • display group But: VISUAL_BINDING ≠ EXECUTION ============================================================ IV. NON-COLLAPSE LAW ============================================================ The extraction schema must enforce: ROTA ≠ RODA RODA ≠ CASA CASA ≠ OPERATOR OPERATOR ≠ PLACEMENT PLACEMENT ≠ CONNECTION CONNECTION ≠ TRAVERSAL VISUAL_BINDING ≠ EXECUTION VISUAL_SELECTION ≠ AREPO_ADMISSION AREPO_ADMISSION ≠ OPERA_EXECUTION SOURCE_ORDER ≠ GENERATION_ORDER GENERATION_ORDER ≠ DISPLAY_ORDER DISPLAY_ORDER ≠ ACTIVE_TRAVERSAL_ORDER OPERATOR_ORDINAL ≠ HOUSE_ORDINAL by default TOKEN_CARRIER ≠ NUMBER_POSITION NUMERAL_SIGN ≠ NUMBER_VALUE Failure to preserve any of these distinctions produces structural invalidity. ============================================================ V. SCHEMA PURPOSE ============================================================ The schema generated from this LIBER must represent a ROTA as: a traversable machine composed of: WHEELS HOUSES OPERATORS PLACEMENTS CONNECTIONS TRAVERSALS LOCI CHAMBERS CAMERAS VISUAL_BINDINGS SOURCE_TRACE VALIDATION_MODEL The schema must be suitable for: • extraction from text • validation of machine state • UI binding • Godot scene binding • traversal simulation • AREPO gate checking • OPERA readiness checking • SATOR output mediation The schema must not: • execute OPERA • infer missing structure silently • derive visual position from operator ordinal unless declared • collapse source class roles • promote draft patches into canon ============================================================ VI. REQUIRED TOP-LEVEL SCHEMA FIELDS ============================================================ A valid ROTA machine schema instance requires at least: schema_meta source_trace terminology_law rota wheels houses operators placements connections traversal_model extraction_model validation_model Recommended additional fields: order_model state_model visual_binding locus_model chamber_model camera_model multiplicatio_model unresolved_items ============================================================ VII. SOURCE TRACE LAW ============================================================ Every extracted machine field must preserve trace to source. The source_trace object must include: source_policy artifact_family parsed_artifacts extraction_confidence unresolved_items Required source policy: source_before_memory = true parse_before_claim = true artifact_before_inference = true Source classes: TENET ROTAS AREPO OPERA SATOR PATCH DEP AUXILIARY USER_PATCH If a field is not recoverable from source: mark UNRESOLVED Do not infer silently. ============================================================ VIII. ARTIFACT FAMILY EXTRACTION ============================================================ The schema must parse artifact family as: artifact_family.tenet artifact_family.rotas artifact_family.arepo artifact_family.opera artifact_family.sator artifact_family.auxiliary Expected roles: ------------------------------------------------------------ TENET ------------------------------------------------------------ Extract: • doctrinal constraints • invariants • non-collapse laws • identity limits • admissible interpretations ------------------------------------------------------------ ROTAS ------------------------------------------------------------ Extract: • ROTA identity • wheel structure • house structure • house counts • ordinals • placements • connections • loci • cameras • chambers • traversal topology • visual binding when present ------------------------------------------------------------ AREPO ------------------------------------------------------------ Extract: • admissibility gates • input requirements • rejection conditions • boundary validations • prerequisites for execution ------------------------------------------------------------ OPERA ------------------------------------------------------------ Extract: • execution requirements • procedural sequence • transformation law • required inputs • possible outputs ------------------------------------------------------------ SATOR ------------------------------------------------------------ Extract: • output formatting • mediation law • uncertainty language • serialization discipline • user-facing display rules ============================================================ IX. ORDER MODEL ============================================================ Every ROTA that involves sequence must explicitly define an order_model. The order_model must distinguish: source_order generation_order display_order slot_order active_traversal_order Definitions: ------------------------------------------------------------ SOURCE_ORDER ------------------------------------------------------------ Order in which the textual artifact lists elements. Example: Up, Down, East, West, South, North ------------------------------------------------------------ GENERATION_ORDER ------------------------------------------------------------ Order in which the machine comes into being. Example: CORE PRE → BINARY I → TETRA II → HEXA III → OCTO IV → DECA V ------------------------------------------------------------ DISPLAY_ORDER ------------------------------------------------------------ Order in which the machine is visually arranged. Example: CORE → DECA → OCTO → HEXA → TETRA → BINARY ------------------------------------------------------------ SLOT_ORDER ------------------------------------------------------------ Final stabilized positional order. Example: 1Ω,2Ω,3Ω,4Ω,5Ω,6Ω,7Ω,8Ω,9Ω,10Ω ------------------------------------------------------------ ACTIVE_TRAVERSAL_ORDER ------------------------------------------------------------ Order used when the machine is traversed during an admitted operation. This may differ from all above orders. Law: No order may be collapsed into another without explicit declaration. ROTA SEPHIROT ARBOR v0.2.0 already demonstrates the necessity of this distinction by separating generation ordinality from geometric display order. :contentReference[oaicite:2]{index=2} ============================================================ X. STATE MODEL ============================================================ Every interactive machine must distinguish: visual_state admission_state execution_state ------------------------------------------------------------ VISUAL_STATE ------------------------------------------------------------ Possible values: UNSELECTED SELECTED HOVERED FOCUSED DISPLAYED Visual state may change without AREPO admission. ------------------------------------------------------------ ADMISSION_STATE ------------------------------------------------------------ Possible values: UNTESTED AREPO_ADMITTED AREPO_REJECTED DEFERRED Admission state may change without OPERA execution. ------------------------------------------------------------ EXECUTION_STATE ------------------------------------------------------------ Possible values: NOT_EXECUTED READY EXECUTING EXECUTED FAILED Execution requires AREPO admission. Law: VISUAL_STATE ≠ ADMISSION_STATE ≠ EXECUTION_STATE ============================================================ XI. CARRIER PACKAGE LAW ============================================================ Every OPERATOR should include a CARRIER_PACKAGE. A CARRIER_PACKAGE records how the operator is carried, displayed, or encoded. Required carrier fields: carrier_type carrier_token carrier_script carrier_display carrier_status Allowed carrier_type values: LATIN_LETTER HEBREW_LETTER PHOENICIAN_LETTER NUMERAL_SIGN GLYPH TOKEN COMPOSITE ABSTRACT_ID Allowed carrier_status values: PRIMARY DERIVED DISPLAY_ONLY PROVISIONAL UNRESOLVED This is required because AGLA must distinguish: operator letter numeral sign glyph token Unicode character number-position value meaning TENET LITTERAE ARS already stabilizes this distinction for Latin Ars letters, Hebrew operator carriers, Hebrew numeral notation, and Phoenician characters. :contentReference[oaicite:3]{index=3} ============================================================ XII. ROTA IDENTITY MODEL ============================================================ Every ROTA must define identity. Required identity fields: pre_wheel_ref pre_house_ref identity_operator_ref operative Default: pre_wheel_ref = WHEEL_PRE pre_house_ref = WHEEL_PRE.HOUSE_PRE operative = false Meaning: WHEEL_PRE / HOUSE_PRE contains identity and potentiality of the ROTA. It does not execute OPERA. This matches the PRE wheel law: WHEEL PRE is central implicit closed wheel representing ROTA identity and potentiality, but no operation. ============================================================ XIII. WHEEL MODEL ============================================================ Each WHEEL / RODA must include: wheel_id wheel_ordinal operative wheel_role house_count house_refs Recommended: level_index depth_index fixed_to source_extract Important distinction: wheel_ordinal ≠ level_index wheel_ordinal ≠ depth_index wheel_ordinal ≠ visual radius by default Wheel roles may include: identity_axis principal_operator_wheel contracted_level genus_level locus_axis chamber_wheel generative_stage display_shell diagnostic_reduction ============================================================ XIV. HOUSE MODEL ============================================================ Each HOUSE / CASA must include: house_id wheel_ref house_ordinal operator_placement_refs Recommended: house_index house_role source_extract House roles may include: identity_house operator_slot empty_slot locus_slot chamber_slot camera_slot diagnostic_slot display_slot Law: house_id is the structural anchor for visual binding. operator_ref is allocated content. Therefore: visual placement must bind to house_ref, not directly to operator ordinal. ============================================================ XV. OPERATOR MODEL ============================================================ Each OPERATOR must include: operator_id operator_ordinal operator_token operator_label carrier_domain carrier_package Recommended: operator_translation parent_operator_ref specificity_level operative source_extract Operator ordinals may be: PRE I II III IV IX I.1 II.1 custom hierarchical paths Law: operator ordinal is internal to operator order. It does not automatically determine house placement. ============================================================ XVI. PLACEMENT MODEL ============================================================ Each OPERATOR_PLACEMENT must include: placement_id operator_ref wheel_ref house_ref operator_ordinal house_ordinal ordinal_relation Allowed ordinal_relation values: operator_ordinal_equals_house_ordinal operator_ordinal_differs_from_house_ordinal pre_identity_exception unresolved This is a blocking validation zone. If an operator is placed without a house: failure_code = OPERATOR_PLACED_WITHOUT_HOUSE If operator ordinal and house ordinal are collapsed silently: failure_code = HOUSE_OPERATOR_ORDINAL_COLLAPSE ============================================================ XVII. CONNECTION MODEL ============================================================ Each CONNECTION must include: connection_id connection_type from_ref to_ref operative Recommended: admissibility_gate_ref traversal_rule source_extract Connection types: circumferential radial_parent_child direct_transversal wheel_alignment wheel_overlay identity_axis locus_axis chamber_transition camera_transition ============================================================ XVIII. LOCUS MODEL ============================================================ A LOCUS is required for TABULA-like and coordinate-based machines. A LOCUS is not identical to house. A LOCUS may coordinate multiple houses, operators, or axes. Required locus fields: locus_id coordinates coordinate_system house_refs operator_refs Allowed coordinate systems: TABULA_HLT FIGURA_QUARTA CUSTOM Allowed locus roles: COMBINATION_SLOT QUESTION_SLOT CAMERA_SLOT TRAVERSAL_NODE Example: locus_id: LOCUS_HLT coordinate_system: TABULA_HLT coordinates: [h,l,t] locus_role: COMBINATION_SLOT ============================================================ XIX. CAMERA MODEL ============================================================ A CAMERA is a relational observation field. It is not identical to operator. It is not identical to execution. It exposes what becomes visible between selected references. Required camera fields: camera_id camera_code camera_type input_refs output_refs observation_scope Allowed camera types: BINARY_RELATION TERNARY_RELATION EVACUATIO COMPARATIO FIGURA_TERTIA CUSTOM ROTA TRADITIO defines camera as a relational observation field between contracted dignities; it exposes tension, concordance, mediation, asymmetry, teleology, dependency, contradiction, stabilization, residue, and symbolic drift, but does not define the operators. :contentReference[oaicite:4]{index=4} Therefore: CAMERA ≠ OPERATOR CAMERA ≠ OPERA CAMERA ≠ TRAVERSAL by default A camera may become traversal unit only when admitted by traversal_model. ============================================================ XX. CHAMBER MODEL ============================================================ A CHAMBER is a structured combination field. It may contain: • multiple loci • multiple cameras • multiple houses • one or more wheels • operator combinations • active or inactive traversal routes Required chamber fields: chamber_id chamber_type member_refs chamber_role Allowed chamber types: TRIADIC QUATERNARY MULTIPLICATIO TABULA CUSTOM A chamber is needed for: • Figura Quarta • triadic Llullian correlatives • Q/A/T/S combination machines • multi-wheel operator interaction ============================================================ XXI. MULTIPLICATIO MODEL ============================================================ The schema must support Multiplicatio / Figura Quarta structures. The multiplicatio_model includes: enabled wheel_series combination_output Each wheel_series item includes: wheel_ref multiplication_role rotation_policy Allowed multiplication roles: W1 W2 W3 W4 CUSTOM Allowed rotation policies: FIXED ROTATABLE LOCKED_TO_PARENT DYNAMIC Allowed combination outputs: LOCUS CHAMBER CAMERA QUESTION CUSTOM This prevents Figura Quarta from being flattened into a simple wheel. ============================================================ XXII. TRAVERSAL MODEL ============================================================ The traversal_model must include: traversal_units allowed_connection_types traversal_state_policy Allowed traversal units: HOUSE CONNECTION WHEEL OPERATOR_PLACEMENT LOCUS CHAMBER CAMERA Traversal state policy requires: visual_selection_is_not_execution = true arepo_required_for_admission = true opera_required_for_execution = true This prevents UI interaction from being treated as operation. ============================================================ XXIII. VISUAL BINDING MODEL ============================================================ Visual binding is optional. When present, it must bind visual objects to structural refs. Allowed coordinate systems: 2D_POLAR 3D_CYLINDRICAL 3D_LAYERED CUSTOM Visual binding may include: wheel_layout house_layout connection_layout godot_binding Godot node refs must include: schema_ref node_path node_class Allowed node classes: Rota3D Wheel3D HouseSlot3D OperatorLabel3D TraversalPath3D CameraNode3D LocusNode3D ChamberNode3D Law: visual node binds to schema_ref. It does not define schema_ref. ============================================================ XXIV. EXTRACTION MODEL ============================================================ The extraction_model must define: extractable_fields source_to_schema_map extraction_rules unresolved_policy Extractable fields include: rota_id rota_name stack_ref regime_ref figure_ref operator_canon operator_ordinals operator_symbols operator_labels wheel_count wheel_ordinals house_count_per_wheel house_ordinals operator_placements parent_child_relations direct_transversals locus_model chamber_model camera_model multiplicatio_model admissibility_requirements execution_requirements sator_output_requirements Unresolved policy requires: do_not_infer_missing_structure = true mark_unresolved = true allow_nuova_only_if_declared = true ============================================================ XXV. VALIDATION MODEL ============================================================ The validation_model must include: structural_validations boundary_validations failure_codes Required structural validations: ------------------------------------------------------------ VALIDATE_ROTA_NOT_WHEEL ------------------------------------------------------------ Assertion: rota.rota_id must not be modeled as wheel_id. Failure: ROTA_WHEEL_COLLAPSE ------------------------------------------------------------ VALIDATE_PRE_WHEEL ------------------------------------------------------------ Assertion: WHEEL_PRE must exist, contain HOUSE_PRE, and be non-operative. Failure: MISSING_OR_OPERATIVE_WHEEL_PRE ------------------------------------------------------------ VALIDATE_OPERATOR_PLACEMENT ------------------------------------------------------------ Assertion: Every operator placement must declare operator_ordinal and house_ordinal separately. Failure: HOUSE_OPERATOR_ORDINAL_COLLAPSE ------------------------------------------------------------ VALIDATE_VISUAL_NOT_EXECUTION ------------------------------------------------------------ Assertion: Visual selection or wheel rotation must not be marked as OPERA execution. Failure: VISUAL_STATE_TREATED_AS_EXECUTION ------------------------------------------------------------ VALIDATE_ORDER_NONCOLLAPSE ------------------------------------------------------------ Assertion: source_order, generation_order, display_order, slot_order, and active_traversal_order must be separately representable. Failure: ORDER_COLLAPSE ------------------------------------------------------------ VALIDATE_CARRIER_PACKAGE ------------------------------------------------------------ Assertion: Every operator must declare carrier package or mark it unresolved. Failure: MISSING_CARRIER_PACKAGE ============================================================ XXVI. FAILURE CODES ============================================================ Required failure codes: ROTA_WHEEL_COLLAPSE HOUSE_OPERATOR_ORDINAL_COLLAPSE MISSING_WHEEL_PRE WHEEL_PRE_MARKED_OPERATIVE MISSING_SOURCE_TRACE ROTAS_NOT_PARSED TRAVERSAL_WITHOUT_CONNECTION OPERATOR_PLACED_WITHOUT_HOUSE HOUSE_REFERENCES_UNKNOWN_WHEEL CONNECTION_REFERENCES_UNKNOWN_HOUSE VISUAL_STATE_TREATED_AS_EXECUTION ORDER_COLLAPSE MISSING_CARRIER_PACKAGE LOCUS_WITHOUT_COORDINATES CAMERA_OPERATOR_COLLAPSE CHAMBER_WITHOUT_MEMBERS MULTIPLICATIO_WITHOUT_WHEEL_SERIES AREPO_EXECUTION_BYPASS OPERA_EXECUTION_WITHOUT_ADMISSION ============================================================ XXVII. PRACTICAL EXTRACTION ORDER ============================================================ The extractor must fill fields in this order: 1. source_trace.artifact_family 2. schema_meta 3. terminology_law 4. rota.stack_ref / regime_ref / figure_ref 5. rota.identity 6. order_model 7. operator canon from TENET 8. carrier packages from TENET / LITTERAE / ROTATA / user patch 9. ROTA machine structure from ROTAS 10. wheels from ROTAS or user patch 11. houses from ROTAS or user patch 12. placements from explicit mapping 13. connections from ROTAS or user patch 14. locus_model when TABULA-like structure is present 15. chamber_model when multi-operator fields are present 16. camera_model when observational matrices are present 17. multiplicatio_model when W1/W2/W3-like wheel interaction exists 18. AREPO admissibility requirements 19. OPERA execution requirements 20. SATOR display/output constraints 21. visual_binding, if available 22. validation_model 23. unresolved_items for anything not textually recoverable ============================================================ XXVIII. SAFETY RULES FOR EXTRACTORS ============================================================ ------------------------------------------------------------ RULE 1 ------------------------------------------------------------ Do not derive visual placement from operator ordinal unless the artifact explicitly states that operator ordinal equals house ordinal. ------------------------------------------------------------ RULE 2 ------------------------------------------------------------ Use house_ref as the visual / structural anchor. Use operator_ref as allocated content. ------------------------------------------------------------ RULE 3 ------------------------------------------------------------ Never collapse: ROTA WHEEL HOUSE OPERATOR PLACEMENT CONNECTION TRAVERSAL VISUAL_BINDING ------------------------------------------------------------ RULE 4 ------------------------------------------------------------ Do not treat visual selection as execution. ------------------------------------------------------------ RULE 5 ------------------------------------------------------------ Do not treat AREPO admission as execution. ------------------------------------------------------------ RULE 6 ------------------------------------------------------------ Do not infer missing wheels, houses, placements, cameras, loci, or connections unless a declared NUOVA patch permits it. ------------------------------------------------------------ RULE 7 ------------------------------------------------------------ If source is insufficient: mark UNRESOLVED ------------------------------------------------------------ RULE 8 ------------------------------------------------------------ If the artifact is traditional / symbolic material, apply TRADITIO discipline: tradition may be dataset, comparatio object, historical residue, mnemonic trace, symbolic overlay, or computational model candidate. tradition may not define, validate, override, or correct operators. This follows TENET TRADITIO and AREPO TRADITIO. :contentReference[oaicite:5]{index=5} :contentReference[oaicite:6]{index=6} ============================================================ XXIX. MINIMAL JSON-SCHEMA TARGET ============================================================ The future JSON schema should be named: AGLA_ROTA_MACHINE_SCHEMA Initial version: 0.2.0-DRAFT It should include all v0.1.0 structures plus: order_model state_model carrier_package locus camera chamber multiplicatio_model expanded validation_model This LIBER does not yet output the full JSON schema. It defines what the schema must encode. ============================================================ XXX. MINIMAL INSTANCE TARGETS ============================================================ The first machine instances to test should be: 1. ROTA T — partial Purpose: validate operator ordinal / house ordinal non-collapse 2. ROTA SEPHIROT ARBOR Purpose: validate order_model and dual display/generation law 3. ROTA NETIVOT Purpose: validate machine partition and species-independent houses 4. TABULA / locus machine Purpose: validate locus_model 5. FIGURA QUARTA / multiplicatio Purpose: validate wheel_series and chamber production 6. ROTA TRADITIO camera matrix Purpose: validate camera_model ============================================================ XXXI. CURRENT ACCEPTANCE STATUS ============================================================ The submitted schema is accepted as: DRAFT SUBSTRATE EXTRACTION-SCHEMA CANDIDATE READY FOR JSON v0.2.0 READY FOR PENTAGRAM DERIVATION It is not yet: CANONICAL FINAL EXECUTABLE SUFFICIENTLY TESTED Required next outputs: 1. TENET MACHINA EX ROTA 2. AREPO MACHINA EX ROTA 3. OPERA MACHINA EX ROTA 4. ROTA MACHINA EX ROTA 5. SATOR MACHINA EX ROTA Together these will form the pentagram governing machine extraction from ROTA artifacts. ============================================================ XXXII. COMPRESSED FORMULA ============================================================ LIBER MACHINA EX ROTAE EXTRACTIO = textual ROTA artifacts ↓ controlled source trace ↓ non-collapsed machine schema ↓ wheels / houses / operators / placements / connections ↓ loci / cameras / chambers / multiplicatio ↓ visual binding without execution ↓ AREPO admission ↓ OPERA readiness ↓ SATOR mediation Core law: ROTAS defines machine body. AREPO admits. OPERA executes. SATOR mediates. TENET constrains. ============================================================ END — LIBER MACHINA EX ROTAE EXTRACTIO v0.1.0 ============================================================ ```