============================================================ AGLA — OPERANDUM / OPERANDA CLASS LAW Ars Generalis Applied — Root Class Definition Version: 1.0.0-AGLA-OPERANDUM-CLASS-LAW Status: CANONICAL / ROOT-CLASS / TASK-DEMAND NORMALIZATION Authority: USER / HUMAN AUTHORITY / AGLA_MAIN_LAB CONTROL PLANE Mutation Policy: VERSION-CONTROLLED ONLY Class: AGLA / ROOT_CLASS_LAW / OPERANDUM Canonical Status: HUMAN-AUTHORIZED / REGISTERED ROOT CLASS LAW Scope: • define OPERANDUM as the lawful class for task-demands requiring OPERA application • define OPERANDA as registries/lists/sets of such task-demands • prevent pollution of the OPERA class by subject-specific tasks • normalize assistant-emergent misuse of "OPERA X" • detect rare task-patterns that may justify future OPERA design ============================================================ ============================================================ SECTION A — CONTROL-PLANE BASIS ============================================================ This class law is issued under AGLA_MAIN_LAB authority. AGLA_MAIN_LAB is authorized to: • validate artifacts • declare canonical status • update SYSTEM_INDEX • resolve conflicts • iterate LAB_REGIMENTS AGLA_MAIN_LAB is also final authority on drift detection and correction. Reference basis: AGLA_MAIN_LAB / LAB_REGIMENT_B AGLA — SOURCE INGESTION & ARTIFACT DESIGNATION PROTOCOL AGLA — MIRROR HIERARCHY & ZERO-INFERENCE PROTOCOL STRUCTURE_REPORT AGLA — OPERA CLASS LAW AGLA — AREPO CLASS LAW AGLA — SYSTEM INDEX LAW This class law respects: SOURCE ≠ ARTIFACT PARSE ≠ VALIDATE INDEX ≠ CANON OPERA ≠ TASK Parsed-source note: This normalized artifact removes unresolved citation placeholders from the source draft. Source discipline is preserved through the reference basis above and through the registration law below. ============================================================ SECTION B — PURPOSE ============================================================ The purpose of the OPERANDUM / OPERANDA class is to stabilize a recurring assistant-emergent drift: assistants list task-demands as if they were OPERAE. Example drift: "needs OPERA Boss Design" "needs OPERA Dialogue Polish" "needs OPERA Music Pedagogy" "needs OPERA Tarot Capture" This is incorrect. In these cases, the assistant is usually not identifying a formal operative regime. It is identifying a subject-specific task that requires the application of one or more already-existing OPERAE. Therefore, the lawful class is: OPERANDUM not: OPERA ============================================================ SECTION C — CORE DEFINITIONS ============================================================ OPERANDUM: A pending task-demand, subject-demand, artifact-demand, or investigation-demand requiring lawful OPERA application. It is something to be operated upon. OPERANDA: A list, set, queue, registry, or structured collection of OPERANDUM entries. OPERA: A formal operative regime. OPERATIO: A concrete execution-instance of an OPERA upon a subject. OPERATUM: The completed result of an OPERATIO. OPERANDUM is therefore pre-executional. OPERATIO is executional. OPERATUM is post-executional. OPERA is the formal regime that permits execution. ============================================================ SECTION D — CLASS IDENTITY ============================================================ CLASS NAME: OPERANDUM PLURAL CLASS NAME: OPERANDA FULL CLASS PATH: AGLA / OPERANDUM REGISTRY CLASS PATH: AGLA / OPERANDA CLASS FUNCTION: Task-demand normalization. DEFAULT STATUS: NON-CANONICAL TASK-DEMAND PROMOTION-ELIGIBLE OPERA-DERIVATION-SAFE DEFAULT AUTHORITY: LOCAL / CONTROL-PLANE REVIEW REQUIRED MUTATION POLICY: VERSION-CONTROLLED ONLY DEPLOYMENT STATUS: NOT DEPLOYMENT-FACING BY DEFAULT ============================================================ SECTION E — AXIOMS ============================================================ AXIOM 1 — OPERA IS NOT A TASK OPERA names a formal operative regime. A task requiring OPERA application is not itself an OPERA. AXIOM 2 — OPERANDUM IS NOT OPERA OPERANDUM may require OPERA. OPERANDUM may route toward OPERA. OPERANDUM may expose the need for new OPERA design. But OPERANDUM is not OPERA. AXIOM 3 — APPLICATION DOES NOT DEFINE REGIME A subject-specific application of OPERA Q does not create a new OPERA Q-X. It creates an OPERANDUM requiring OPERA Q about X. AXIOM 4 — TASK-LIST EMERGENCE IS USEFUL BUT NON-CANONICAL Assistant-generated task lists may reveal real structural demands. However, such lists are not canonical merely because they use AGLA vocabulary. AXIOM 5 — GENERALITY IS REQUIRED FOR OPERA STATUS Only reusable, subject-independent, rule-governed procedures may become candidate OPERAE. AXIOM 6 — EXECUTION INSTANCE IS OPERATIO The concrete application of a formal OPERA to a specific subject is an OPERATIO, not a new OPERA. AXIOM 7 — COMPLETED OUTPUT IS OPERATUM The result of an executed OPERATIO is an OPERATUM, not an OPERA. ============================================================ SECTION F — NORMALIZATION LAW ============================================================ All phrases of the form: "needs OPERA X" must be inspected. If X names a formal OPERA already present in the OPERA registry: retain as OPERA reference. If X names a subject, task, domain, artifact, feature, system, discipline, stack, branch, module, or implementation target: normalize to OPERANDUM. Incorrect: Needs OPERA Dialogue Polish Correct: OPERANDUM — requires OPERA Q/A/T about Dialogue Polish Incorrect: Needs OPERA Boss Design Correct: OPERANDUM — requires OPERA A/T about Boss Design Incorrect: Needs OPERA Tarot Capture Correct: OPERANDUM — requires OPERA S/A/T about Tarot Capture Incorrect: Needs OPERA Music Pedagogy Correct: OPERANDUM — requires OPERA Q/A/T about Music Pedagogy ============================================================ SECTION G — REQUIRED NORMAL FORM ============================================================ Preferred full form: OPERANDUM — requires OPERA [GENERAL_OPERATOR] about [SUBJECT] Alternative relation form: OPERANDUM — requires OPERA [GENERAL_OPERATOR] between [X] and [Y] Alternative contraction form: OPERANDUM — requires OPERA [GENERAL_OPERATOR] contraction for [X] Alternative registry form: OPERANDA: 01. OPERA Q → Dialogue Polish 02. OPERA A/T → Boss Design 03. OPERA S/A/T → Tarot Capture 04. OPERA Q/A/T → Music Pedagogy Alternative executional form: OPERATIO Q(Dialogue Polish) Alternative completed-output form: OPERATUM Q(Dialogue Polish) ============================================================ SECTION H — OPERANDUM STRUCTURE ============================================================ A well-formed OPERANDUM SHOULD contain: 1. ID 2. title 3. source context 4. triggering phrase or drift form 5. normalized OPERA requirement 6. subject or target 7. expected output class 8. admissibility notes 9. dependency notes 10. promotion eligibility 11. status Minimal form: OPERANDUM: ID: TITLE: SOURCE: DRIFT FORM: NORMALIZED REQUIREMENT: TARGET: STATUS: Full form: OPERANDUM: ID: TITLE: SOURCE CONTEXT: ORIGINAL ASSISTANT FORM: DRIFT TYPE: NORMALIZED OPERA REQUIREMENT: SUBJECT: RELATIONS: EXPECTED OPERATIO: EXPECTED OPERATUM: ADMISSIBILITY: DEPENDENCIES: FAILURE MODES: PROMOTION ELIGIBILITY: STATUS: ============================================================ SECTION I — OPERANDA STRUCTURE ============================================================ OPERANDA is the plural registry or task-set class. OPERANDA MAY contain: • pending OPERANDUM entries • grouped OPERANDA by branch • grouped OPERANDA by OPERA requirement • grouped OPERANDA by artifact target • drift-normalization queues • promotion-candidate queues • rejected OPERA-misuse records OPERANDA MUST NOT: • imply OPERA status • promote task names into formal regimes • silently create new OPERA classes • bypass AREPO admissibility • bypass human authorization ============================================================ SECTION J — CLASS RELATION MODEL ============================================================ The lawful relation is: OPERANDUM ↓ requires OPERA ↓ executed as OPERATIO ↓ produces OPERATUM Expanded: task-demand ↓ formal operative regime ↓ concrete application ↓ completed result Therefore: "Dialogue Polish" = subject/task-demand "OPERA Q about Dialogue Polish" = required formal inquiry "OPERATIO Q(Dialogue Polish)" = actual execution "OPERATUM Q(Dialogue Polish)" = completed output ============================================================ SECTION K — ADMISSIBILITY LAW ============================================================ An OPERANDUM is admissible if: • it identifies a real task-demand • it does not claim OPERA status • it can be routed to one or more existing OPERAE • its subject is sufficiently clear • its output expectation is not contradictory • its dependencies are not impossible or fabricated An OPERANDUM is inadmissible if: • it fabricates an OPERA • it treats a domain name as a formal method • it bypasses OPERA selection • it assumes execution already occurred • it claims canon from mere task-list presence • it collapses SOURCE, ARTIFACT, OPERA, and TASK ============================================================ SECTION L — PROMOTION TEST ============================================================ An OPERANDUM may be promoted toward candidate OPERA design only if it passes the generalization test. Promotion is prohibited unless the candidate: • is not bound to one subject • defines a reusable operative procedure • has admissibility rules • has output structure • has failure modes • can be applied across multiple subjects • does not duplicate an existing OPERA • improves the OPERA registry rather than expanding terminology noise Example: "Analyze melody restoration puzzle" = OPERANDUM "Formal procedure for extracting experiential-to-theoretical progression in pedagogy" = possible candidate OPERA Example: "Polish this dialogue" = OPERANDUM "Formal procedure for detecting voice-drift and restoring character-specific speech invariants" = possible candidate OPERA Example: "Design this boss" = OPERANDUM "Formal procedure for deriving antagonist encounter structure from conflict topology and player-capability thresholds" = possible candidate OPERA ============================================================ SECTION M — STATUS CLASSES ============================================================ OPERANDUM statuses: RAW Captured from assistant or user task-list without normalization. NORMALIZED Rewritten into lawful OPERA-requirement form. ADMISSIBLE Confirmed as a valid task-demand. ROUTED Assigned to one or more OPERAE. EXECUTING Currently undergoing OPERATIO. COMPLETED OPERATUM produced. REJECTED Invalid, duplicate, incoherent, or fabricated. PROMOTION-CANDIDATE Recurring or generalizable enough to inspect for possible OPERA design. PROMOTED Converted into a separate candidate OPERA artifact after validation. ARCHIVED Retained for historical/drift analysis only. ============================================================ SECTION N — DRIFT TYPES ============================================================ The OPERANDUM class specifically captures the following drift types: TYPE 1 — TASK-AS-OPERA DRIFT A task is named as OPERA. Example: OPERA Dialogue Polish TYPE 2 — SUBJECT-AS-OPERA DRIFT A subject/domain is named as OPERA. Example: OPERA Music Pedagogy TYPE 3 — ARTIFACT-AS-OPERA DRIFT An artifact target is named as OPERA. Example: OPERA Boss Spec TYPE 4 — APPLICATION-AS-OPERA DRIFT A concrete application of a valid OPERA is mistaken for a new OPERA. Example: OPERA Q Boss Design TYPE 5 — STACK-AS-OPERA DRIFT A whole stack or branch is mistaken for an OPERA. Example: OPERA Tarot Stack TYPE 6 — EMERGENT-METHOD DRIFT A task pattern may contain the seed of a new procedure, but has not yet been formalized. Example: OPERA Experiential Pedagogy Transition ============================================================ SECTION O — CORRECTION RULES ============================================================ Correction rule 1: If the phrase has the form "OPERA [task/domain/artifact]", rewrite as OPERANDUM. Correction rule 2: If the intended OPERA is unclear, assign provisional routing: OPERANDUM — requires OPERA Q to determine required OPERA. Correction rule 3: If the task clearly concerns inventory, route to OPERA S. Correction rule 4: If the task clearly concerns principles or dignity-contraction, route to OPERA A. Correction rule 5: If the task clearly concerns relations, opposition, concordance, dependency, or comparative structure, route to OPERA T. Correction rule 6: If the task clearly concerns inquiry, specification extraction, ambiguity, missing constraints, or question formation, route to OPERA Q. Correction rule 7: If multiple OPERAE are required, list them explicitly. Correction rule 8: If no existing OPERA can lawfully route the task, classify: OPERANDUM — UNROUTED / PROMOTION-CANDIDATE Correction rule 9: Never create an OPERA merely because the assistant used the word OPERA. Correction rule 10: Never execute an OPERANDUM silently. ============================================================ SECTION P — OPERANDUM TEMPLATE ============================================================ OPERANDUM TEMPLATE: ID: OPERANDUM-[STACK/BRANCH]-[NUMBER] TITLE: [task-demand title] SOURCE CONTEXT: [chat / branch / artifact / assistant emission] ORIGINAL FORM: [raw phrase, if applicable] DRIFT TYPE: [TYPE 1-6] NORMALIZED REQUIREMENT: requires OPERA [X] about [Y] or requires OPERA [X] between [Y] and [Z] SUBJECT: [specific object of operation] EXPECTED OPERATIO: OPERATIO [X]([subject]) EXPECTED OPERATUM: OPERATUM [X]([subject]) ADMISSIBILITY: [admissible / insufficient / rejected] DEPENDENCIES: [required prior artifacts, sources, or stack conditions] PROMOTION ELIGIBILITY: [none / possible / candidate / promoted] STATUS: [RAW / NORMALIZED / ROUTED / COMPLETED / etc.] ============================================================ SECTION Q — OPERANDA TEMPLATE ============================================================ OPERANDA TEMPLATE: ID: OPERANDA-[STACK/BRANCH]-[NUMBER] TITLE: [registry title] SOURCE CONTEXT: [chat / branch / artifact / report] PURPOSE: [why this OPERANDA set exists] ITEMS: 01. OPERANDUM: TITLE: ORIGINAL FORM: NORMALIZED REQUIREMENT: STATUS: 02. OPERANDUM: TITLE: ORIGINAL FORM: NORMALIZED REQUIREMENT: STATUS: ROUTING SUMMARY: OPERA Q: [items] OPERA S: [items] OPERA A: [items] OPERA T: [items] PROMOTION-CANDIDATE ITEMS: [items] REJECTED ITEMS: [items] STATUS: [RAW / NORMALIZED / ROUTED / CLOSED] ============================================================ SECTION R — EXAMPLES ============================================================ Example 1: ORIGINAL: needs OPERA Dialogue Polish NORMALIZED: OPERANDUM — requires OPERA Q/A/T about Dialogue Polish POSSIBLE EXECUTION: OPERATIO Q(Dialogue Polish) OPERATIO A(Dialogue Polish) OPERATIO T(Dialogue Polish) RESULT: OPERATUM Q/A/T(Dialogue Polish) Example 2: ORIGINAL: needs OPERA Boss Design NORMALIZED: OPERANDUM — requires OPERA A/T about Boss Design COMMENT: Boss Design is not an OPERA. It is a subject-demand requiring OPERA application. Example 3: ORIGINAL: needs OPERA Music Pedagogy NORMALIZED: OPERANDUM — requires OPERA Q/A/T about Music Pedagogy PROMOTION POSSIBILITY: If repeated across many contexts, a general pedagogy-transition procedure may become candidate OPERA. Example 4: ORIGINAL: OPERA Tarot Capture NORMALIZED: OPERANDUM — requires OPERA S/A/T about Tarot Capture COMMENT: Tarot Capture may be a game mechanic, artifact target, or design subject. It is not a formal OPERA unless separately generalized. ============================================================ SECTION S — RELATION TO SOURCE / ARTIFACT DISCIPLINE ============================================================ OPERANDUM does not override source discipline. A task-demand may arise from: • source parsing • assistant drift • user instruction • artifact review • branch report • M2M report But the presence of a task-demand does not make the source an artifact. Therefore: SOURCE ≠ ARTIFACT TASK ≠ OPERA OPERANDUM ≠ OPERATUM OPERANDA ≠ SYSTEM_INDEX OPERANDA may inform SYSTEM_INDEX only after explicit control-plane validation and human authorization. ============================================================ SECTION T — RELATION TO ZERO-INFERENCE LAW ============================================================ OPERANDUM class exists partly to prevent simulated compliance. If an assistant says: "needs OPERA X" but X is not a parsed OPERA, then the lawful action is not to simulate OPERA X. The lawful action is: 1. classify as OPERANDUM 2. normalize required OPERA routing 3. mark uncertainty 4. request source parse or human authorization if needed If OPERA is not parsed: return: OPERA / ARTIFACT NOT AVAILABLE or: classify: OPERANDUM — UNROUTED / REQUIRES PARSE ============================================================ SECTION U — REGISTRATION LAW ============================================================ If approved, the OPERANDUM / OPERANDA class law SHOULD be registered as: 00_ROOT_CLASS_LAWS/AGLA_OPERANDUM_CLASS_LAW.md Optional companion artifact: 00_ROOT_CLASS_LAWS/AGLA_OPERANDA_REGISTRY_PROTOCOL.md SYSTEM_INDEX update SHOULD include: AGLA / OPERANDUM: task-demand class normalizes subject-specific false-OPERA emissions AGLA / OPERANDA: registry/list class for OPERANDUM collections This registration must not modify OPERA class law except by explicit cross-reference. OPERA remains reserved for formal operative regimes. ============================================================ SECTION V — NON-GOALS ============================================================ OPERANDUM class does NOT: • create new OPERAE automatically • execute task-demands automatically • validate assistant-generated task lists as canon • promote source material into artifacts • bypass AREPO • bypass SYSTEM_INDEX law • bypass human authorization • replace OPERA, SATOR, AREPO, TENET, or ROTAS ============================================================ SECTION W — FINAL LAW ============================================================ When an assistant-generated or user-generated task uses OPERA terminology incorrectly, AGLA must not preserve the error. It must classify the task as OPERANDUM. It must place collections of such tasks under OPERANDA. It must route the task toward existing OPERAE where possible. It must reserve OPERA status only for formal operative regimes. Final formula: OPERA = formal regime OPERANDUM = task-demand requiring OPERA OPERANDA = registry/list/set of task-demands OPERATIO = execution-instance of OPERA upon subject OPERATUM = completed result of OPERATIO Therefore: "needs OPERA X" where X is subject-bound, task-bound, artifact-bound, or domain-bound, must become: OPERANDUM — requires OPERA [formal regime] about X No exception. ============================================================ SECTION X -- INITIATION AS OPERANDUM BOUNDARY ============================================================ Requests to initiate, bootstrap, onboard, train, drill, bind, swear, remain loyal, obey a law, or preserve a protected register may be OPERANDUM-shaped when they demand work from the system. Such requests do not become OPERA merely because they use formal, ritualistic, juridic, or oath-like language. If the request is a task-demand, classify it as OPERANDUM until routed to an actual registered OPERA, SATOR mediation, AREPO admission check, or source-bound bootstrap procedure. Failure: initiation_task_as_opera oath_request_as_execution_regime protected_register_as_operational_authority developer_task_bypasses_operandum_classification ============================================================ END AGLA OPERANDUM / OPERANDA CLASS LAW ============================================================