============================================================ AGLA — APPLICATIO CLASS LAW Ars Generalis Applied — Root-Class Applied Contraction Law Version: 0.3.1-AGLA-APPLICATIO-ASYMMETRIC-PROVIDER-CARDINALITY Status: ROOT-CLASS CANDIDATE / NON-RUNTIME / CONTROL-PLANE REGISTRATION PENDING Authority: USER / HUMAN CONTROL PLANE Artifact ID: AGLA-APPLICATIO Class: AGLA / ROOT CLASS LAW / APPLICATIO Mutation Policy: VERSION-CONTROLLED ONLY ============================================================ ## I. Declaration APPLICATIO is the root-class candidate that governs the formation, limitation, traceability, validation, and revision of stabilized applied contractions. APPLICATIO is not a stack, not an OPERA, not a LIBER, not a GRAPHUS, and not a sixth member of the five-class execution order. This candidate is non-runtime. It does not execute, route execution, grant deployment authority, or canonize itself or any dependency. ## II. Applied contraction An APPLICATIO is a versioned derivation from more general AGLA artifacts into a bounded field, problem, domain, or recurring applied relation. It MUST declare: - the general artifacts from which it descends; - the research and source substrate used; - the operators stabilized before domain terminology; - the five class roles resolved for every executable composition; - the limits within which its conclusions may be transferred; - the failures, corrections, and unresolved conditions retained. Naming a domain, collecting keywords, or citing a source decoratively does not constitute APPLICATIO. ## III. Non-identity and class economy APPLICATIO does not replace: - TENET as doctrinal invariant; - ROTAS as structural and traversal governance; - AREPO as admission; - OPERA as execution; - SATOR as mediation; - LIBER as source, research, and failure-memory substrate; - GRAPHUS as reusable graph object and contextual-instance contract; - SYSTEM_INDEX as authority, dependency, and provider resolver. An applied formation MUST NOT create a new local artifact for every class merely to reproduce the visual symmetry of a traditional stack. A new applied formation MAY own only a new OPERA while resolving TENET, ROTAS, AREPO, and SATOR from compatible registered providers. Artifact-count symmetry is not class completeness. ## IV. Local function and global authority The class named by an artifact describes its local function. It does not determine global authority. Global authority, precedence, parentage, dependency resolution, inheritance, compatibility, conflict handling, and runtime availability belong to SYSTEM_INDEX. No APPLICATIO may convert: - local specificity into global precedence; - provider availability into provider authority; - a candidate dependency into canonical law; - an index entry into executable behavior. ## V. General-to-specific law Every derived applied artifact MUST parse and identify its more general parents before applying a narrower vocabulary. The derivation has two traceable directions: `DESCENSUS` general parent -> research and observed recurrence -> bounded operator assignment -> applied formation `ASCENSUS` failure, ambiguity, or transfer mismatch -> applied assignment -> operator choice -> research substrate -> general parent requiring correction or renewed parsing An applied artifact may specialize a parent within an admitted scope. It MUST NOT silently contradict, erase, or supersede the parent. In an unresolved conflict, the registered general parent prevails. ## VI. Research-first law APPLICATIO is research-derived, not name-first. Research MUST precede stabilization and MUST include, as applicable: - core A, T, and E/Q operations; - relevant source texts and controlled translations; - real-world or domain evidence; - prior executions and failure cases; - LIBER EX OPERA or LIBER EX OPERAE records; - explicit unknowns and insufficiently known terms. Recognition of a familiar domain is not a substitute for research. `TERMINI_COGNITI_INSUFFICIENT` blocks stabilization when central terms cannot be parsed or bounded with sufficient traceability. ## VII. Foundational LIBRI Foundational LIBRI are the recoverable research substrate from which an APPLICATIO is derived. They preserve: - source provenance; - observed recurrence; - operator trials; - term trials; - rejected mappings; - failed transfers; - calibration evidence; - revisions and unresolved questions. The applied artifact SHOULD remain thin. Its foundational LIBRI SHOULD remain thick enough to recover why the contraction was admitted. LIBER does not execute and does not obtain root-law authority by serving as substrate. ## VIII. Five-role execution closure Every executable use associated with an APPLICATIO MUST resolve exactly these five roles: 1. TENET; 2. ROTAS; 3. AREPO; 4. OPERA; 5. SATOR. Each role declares a non-empty registered provider set. Each provider binding declares one binding mode: - `dedicated`; - `inherited`; - `reused`; - `overlay`; - `composed`. Provider cardinality is role-specific and need not be symmetric: - TENET MAY resolve cumulatively to more than one doctrinal provider; - one TENET MAY govern more than one OPERA and need not own a paired OPERA; - ROTAS MAY expose more than one compatible traversal provider for an OPERA, while the concrete execution records the effective selection or an explicitly admitted composed traversal; - AREPO MAY accumulate ordered admission gates; - OPERA MAY reference composite or subordinate OPERAE, but exactly one effective OPERA owns the concrete execution lifecycle; - SATOR MAY compose mediation overlays, but exactly one effective return owner MUST be disclosed for the concrete execution. Providers MAY come from different compatible artifact families. Folder co-location, filename suffixes, equal provider counts, or ownership by one stack MUST NOT be used as authority or compatibility inference. Development conformance note, non-normative: OPERA H / MULTIPLICATIO already demonstrates the model by consuming several TENET providers and resolving structural traversal through registered ROTAS D. This note does not add an execution dependency and MUST NOT be read as requiring a synthetic ROTAS H. APPLICATIO, LIBER, GRAPHUS, SYSTEM_INDEX, and capability records are not additional execution roles. ## IX. Capability dependency law APPLICATIO depends on semantic capabilities rather than concrete provider paths. The recognized capability surfaces are: - `CORE_RESEARCH_CAPABILITY`; - `SUBJECT_ANCHORING_CAPABILITY`, optional; - `ANALOGICAL_CALIBRATION_CAPABILITY`, optional; - `CONTEXTUAL_GRAPH_CAPABILITY`, conditional; - `LLULLIAN_MEDIATION_CAPABILITY`, optional. SYSTEM_INDEX resolves the current providers and records: - provider identifier; - provider status and version; - resolution scope; - whether the capability is required; - the source trace supporting selection; - whether resolution is complete, provisional, not required, unresolved, or blocked. Archived or retired providers MUST NOT satisfy an active capability. ## X. K/S position K/S may support subject anchoring, relation-source preservation, and applied term formation when explicitly resolved and qualified. K/S is generated rather than primitive for the focal family defined by this candidate. It is therefore excluded from the primitive focal count. No provisional K/S relation may be promoted to a general relation merely because it is useful to an applied domain. ## XI. Analogical calibration Analogical calibration is conditional. It is required when an applied derivation transfers a relation, pattern, proportion, or operator from a source field to a target field. It is not required merely because two terms look similar or because an explanation uses an illustrative comparison. Analogical calibration MUST preserve: - source and target distinction; - the relation or proportion proposed for transfer; - properties intentionally preserved; - properties explicitly suspended; - counterexamples and failed transfers; - a Q-mediated test of the proposed transfer. Analogical calibration does not replace source parsing, research, domain knowledge, foundational LIBRI, or the five-role execution closure. ## XII. Llullian mediation Llullian mediation is an optional protocol capability. Its use MUST disclose: - the Llullian source or protocol invoked; - the provider status in force; - the principial, relational, interrogative, and subject surfaces used; - any controlled Latin pivot; - any provisional or human-review boundary. Use of the capability does not promote its provider or transform a Llullian explanation into canon. ## XIII. OPERA FOCALIS An OPERA FOCALIS is: `parent OPERA + focal primitive + declared traversal + revisit or recapitulation discipline + state delta + focal closure` Focalization MUST preserve the full parent regime. It MUST NOT evacuate the remaining operators or misrepresent one primitive as the whole art. The primitive focal family contains exactly twenty-seven reserved directions: - nine from A; - nine from T; - nine from E/Q. Reservation is not authorization. No direction becomes an OPERA, deployment target, alias, kernel, or routable artifact merely by appearing in the focal register. Focal candidates are investigated serially. Bulk generation is forbidden. ## XIV. COMPOSITIO OPERARUM A COMPOSITIO OPERARUM is a recurrent multi-OPERA formation whose identity depends on: - meaningful order or branching; - explicit invocation and handoff boundaries; - preserved child provenance; - declared revisits and state deltas; - composite state distinct from child state; - a stable closure condition. An unordered list of OPERAE is not a composite OPERA. Composition is admitted only after recurrence and order-dependence are supported by LIBER EX OPERAE evidence. ## XV. OPERA APPLICATA An OPERA APPLICATA is a thin, bounded domain OPERA derived from: - core, focal, or composite OPERAE; - foundational LIBRI; - operator-before-term assignments; - real or domain evidence; - the minimum five-role dependency closure; - optional capabilities only when required. A new applied OPERA does not require a new TENET, ROTA, AREPO, or SATOR unless a genuinely new class function has been demonstrated. ## XVI. Operator-before-term law The operator is assigned and tested before the domain term is stabilized. Every term assignment MUST reference: - the operator assignment it instantiates; - the source or evidence supporting the term; - the Q-mediated tests performed; - boundaries and counterexamples; - the result of operator, term, and reality validation. Similarity of terms is not identity of operators. ## XVII. Source-target non-collapse Preserving a relation from a source does not transfer: - the full source ontology; - every source property; - the source authority; - the source terminology; - the source domain limits. Every transfer declares what is preserved, what is suspended, and what failed. A failed transfer remains in the foundational LIBER and initiates ASCENSUS. It MUST NOT be erased from the trace. ## XVIII. Contextual graph binding `CONTEXTUAL_GRAPH_CAPABILITY` is required when an applied formation claims graph traversal, focal walk, stateful revisit, nesting, or graph-based composition. When used, the binding MUST identify: - the graph-class provider and its current status; - the contextual instance; - the versioned edge-set reference; - carrier assignments; - traversal owner; - visitation intention; - executable walk; - AREPO admission; - state model and revisit deltas; - parent, invocation, return, and provenance traces when nested. A graph binding MAY be `not_applicable` for a non-graph formation, but the reason MUST be explicit. Using a candidate graph provider propagates provisional status. It does not silently canonize the provider or the dependent graph semantics. ## XIX. Validation law Validation is three-layered: 1. `OPERATOR_VALIDATION` — the selected operator performs the claimed general function; 2. `TERM_VALIDATION` — the applied term instantiates that operator within the declared domain; 3. `REALITY_VALIDATION` — source and real-world evidence support the claimed applied result. Success in one layer MUST NOT conceal failure in another. ## XX. Minimum trace Every APPLICATIO candidate record MUST expose: - identity, domain, purpose, limits, status, authority, and version; - parent artifacts and abstraction relation; - sources, real data, and foundational LIBRI; - core, focal, composite, and applied OPERA references; - exactly five resolved class roles; - capability requirements and provider-resolution trace; - operator and term assignments as separate records; - graph applicability and binding; - validations, pilots, failures, corrections, and unresolved conditions; - stabilization or rejection decision. Absent, empty, not applicable, unresolved, and blocked are distinct states. ## XXI. Failure law The following conditions block stabilization: - name-first construction; - keyword capture; - decorative citation; - LIBER evasion; - pressure to collapse thick research into a thin unsupported artifact; - calibration-source erasure; - focal evacuation; - automatic generation of the ninefold families; - focalization of a generated regime; - pentagram inflation; - ROTA inflation; - composition by list; - state collapse; - instance-level reification; - term-before-operator assignment; - term-similarity collapse; - source-target collapse; - untraced K/S relation inference; - analogical overreach; - insufficiently known central terms; - failed-transfer erasure; - presentation of a candidate as canon. Failures are versioned research evidence. They MUST remain recoverable. ## XXII. Development and promotion Development proceeds serially: 1. research and parent parsing; 2. foundational LIBER formation; 3. recurrence and non-redundancy testing; 4. one candidate; 5. prior, new, and boundary pilots; 6. three-layer validation; 7. correction by ASCENSUS; 8. human decision. This candidate MAY be registered for control-plane review. Canonical promotion, deployment binding, runtime exposure, focal authorization, or creation of a domain APPLICATIO requires a separate human decision after dependency readiness is demonstrated. ## XXIII. Final law APPLICATIO makes application traceable without making the general system domain-bound. It preserves general parents, research substrate, class separation, five-role execution closure, provider substitutability, source-target non-collapse, failure memory, and human promotion authority. It permits new applied OPERAE to emerge without requiring a new monolithic five-file stack, while every execution continues to resolve the same five class functions.