# APPLICATIO Candidate Specification

Version: `1.0.1-APPLICATIO-ASYMMETRIC-PROVIDER-CARDINALITY`
Status: `CONTROL-PLANE INSTANCE SPECIFICATION / NON-RUNTIME / CANDIDATE`
Authority: `USER / HUMAN CONTROL PLANE`
Root law: `AGLA_APPLICATIO_CLASS_LAW.md`
Machine schema: `APPLICATIO_TRACE_SCHEMA.json`

## I. Record identity

An `APPLICATIO_CANDIDATE_RECORD` is the control-plane record for one
bounded applied-contraction candidate.

It is not the applied OPERA, not an execution request, not a LIBER, not a
graph instance, and not a SYSTEM_INDEX entry.

The record MUST expose:

- `applicatio_id`;
- `version`;
- `status`;
- `domain`;
- `purpose`;
- `limits`;
- `authority`;
- `parent_refs`;
- `source_refs`;
- `real_data`;
- `foundational_libri`;
- `opera_bindings`;
- `five_role_resolution`;
- `capability_bindings`;
- `operator_assignments`;
- `term_assignments`;
- `graph_binding`;
- `validation`;
- `failure_trace`;
- `correction_trace`;
- `stabilization_decision`.

## II. State distinctions

The following states are not interchangeable:

- absent — the required field is not present and the record is invalid;
- empty — the field is present but contains no evidence;
- `not_required` — the capability was tested and is unnecessary;
- `not_applicable` — the surface does not apply and a reason is recorded;
- `unresolved` — resolution was attempted but has no valid provider;
- `provisional` — a provider resolved with noncanonical status;
- `blocked` — a named condition prevents progress.

No consumer may coerce one state into another.

## III. Parent and abstraction trace

Each `parent_ref` declares:

- registered artifact identifier;
- version and status observed;
- abstraction relation;
- inherited invariants;
- permitted specialization;
- unresolved conflicts.

Allowed abstraction relations are:

- `general_parent`;
- `method_parent`;
- `source_parent`;
- `structural_parent`;
- `applied_predecessor`.

If a derived rule conflicts with an unresolved general parent, the parent
prevails and stabilization is blocked.

## IV. Research substrate

`source_refs` MUST contain at least one traceable source.

`real_data` declares whether real or domain evidence is:

- provided;
- not applicable;
- unresolved;
- blocked.

`foundational_libri` MUST contain at least one LIBER reference for any
candidate entering pilot or stabilization review.

Each LIBER reference declares:

- artifact identifier or path;
- version and status;
- relation to the candidate;
- recoverable provenance;
- whether failures and rejected mappings are retained.

## V. OPERA bindings

`opera_bindings` separates:

- core OPERAE;
- focal OPERAE;
- composite OPERAE;
- applied OPERAE.

At least one core OPERA is required.

Focal, composite, and applied lists MAY be empty. Empty does not imply
missing when the field is present and its absence is lawful.

An OPERA reference MUST NOT be treated as executable unless its own
runtime authority and five-role resolution are valid.

## VI. Five-role resolution

`five_role_resolution` contains exactly:

- `TENET`;
- `ROTAS`;
- `AREPO`;
- `OPERA`;
- `SATOR`.

Each role is a bucket that declares:

- `providers`, a non-empty list of provider bindings;
- `composition_mode`;
- `effective_provider_refs`;
- `resolution_status`.

No sixth role is permitted.

Each provider binding declares:

- `provider_ref`;
- `binding_mode`;
- `provider_status`;
- `provider_version`;
- `source_trace`.

A provider MAY be:

- dedicated to the candidate;
- inherited from a parent;
- reused unchanged;
- overlaid without mutating the base;
- composed through an explicitly registered resolution.

Provider compatibility MUST come from SYSTEM_INDEX, not a matching
filename, suffix, directory, or informal resemblance.

The number of providers in the five buckets MAY differ. The record MUST
NOT duplicate or synthesize artifacts to obtain equal counts.

Role-specific rules:

- `TENET.providers` MAY contain multiple cumulative doctrines. A TENET
  MAY govern multiple OPERAE and MAY exist without a paired OPERA.
- `ROTAS.providers` MAY contain multiple compatible traversals.
  `effective_provider_refs` records the selected ROTA for the concrete
  execution, or every participant in an explicitly admitted composition.
- `AREPO.providers` MAY contain multiple gates; their effective order MUST
  be recoverable from `providers`.
- `OPERA.providers` MAY disclose composite or subordinate OPERAE, but
  `effective_provider_refs` MUST contain exactly one lifecycle owner for
  the concrete execution.
- `SATOR.providers` MAY contain overlays, but
  `effective_provider_refs` MUST identify exactly one effective return
  owner.

Non-normative conformance case: OPERA H / MULTIPLICATIO consumes multiple
TENET artifacts and currently resolves its structural surface through
ROTAS D. The case illustrates provider asymmetry; it does not create a
general-to-specific runtime dependency or imply ROTAS H.

## VII. Capability bindings

Each capability record declares:

- `capability_ref`;
- whether it is required;
- resolved provider identifiers;
- provider status and version at resolution time;
- source trace;
- `resolution_status`;
- reason when unresolved, blocked, not required, or not applicable.

Recognized capabilities are:

- `CORE_RESEARCH_CAPABILITY`;
- `SUBJECT_ANCHORING_CAPABILITY`;
- `ANALOGICAL_CALIBRATION_CAPABILITY`;
- `CONTEXTUAL_GRAPH_CAPABILITY`;
- `LLULLIAN_MEDIATION_CAPABILITY`.

The record names capabilities, not archived implementation paths.

## VIII. Operator and term assignments

Every operator assignment declares:

- assignment identifier;
- operator reference;
- source and parent evidence;
- scope;
- tests;
- result;
- limits.

Every term assignment MUST reference an existing operator assignment and
declare:

- proposed term;
- source and domain evidence;
- E/Q tests;
- counterexamples;
- result;
- limits.

A term may not be stabilized before its referenced operator passes
operator validation.

## IX. Graph binding

`graph_binding` is always present as a state-bearing record.

It may be:

- `not_applicable`, with reason;
- `resolved`;
- `provisional`;
- `unresolved`;
- `blocked`.

When resolved or provisional it MUST contain:

- graph provider and provider status;
- graph instance reference;
- edge-set reference;
- carrier assignments reference;
- traversal owner;
- visitation signature;
- executable walk;
- AREPO admission;
- state model;
- source trace;
- nesting trace where applicable.

The record does not infer topology from visualization.

## X. Validation

Validation contains separate results for:

- `operator`;
- `term`;
- `reality`.

Each result declares:

- status;
- evidence references;
- failure identifiers;
- reviewer or validating authority;
- notes and limits.

An overall pass is forbidden when any required layer is failed, blocked,
or unresolved.

## XI. Failure and correction trace

Failures are append-preserved.

Each failure declares:

- `failure_id`;
- failure type;
- affected layer;
- evidence;
- impact;
- status.

Each correction declares:

- `correction_id`;
- `prior_failure_ref`;
- ASCENSUS path;
- changed assignment or dependency;
- evidence;
- validation result.

Correction does not delete or overwrite the prior failure.

## XII. Stabilization decision

The record ends with one decision:

- `REJECTED`;
- `RESEARCH_CONTINUES`;
- `BLOCKED`;
- `PILOT_SUPPORTED`;
- `HUMAN_PROMOTION_REVIEW_REQUESTED`.

No candidate record may declare itself canonical, deployment-binding, or
runtime-authorized.

## XIII. Conformance

Conformance to this specification demonstrates structural coherence only.

It does not:

- promote the APPLICATIO root class;
- promote LIBER, GRAPHUS, Llulliana, or another provider;
- create or authorize an OPERA;
- register a domain application;
- grant runtime execution.