# APPLICATIO Development Protocols

Version: `1.0.0-APPLICATIO-DEVELOPMENT-PROTOCOLS-CANDIDATE`
Status: `CONTROL-PLANE SUPPORT / NON-RUNTIME / CANDIDATE`
Authority: `USER / HUMAN CONTROL PLANE`
Root law: `AGLA_APPLICATIO_CLASS_LAW.md`

## I. Purpose

This artifact contains developmental procedures extracted from the
APPLICATIO root-class candidate.

It does not execute an OPERA, authorize a focal direction, register a
provider, or grant canonical status. It governs how evidence is gathered
before a human promotion decision.

Development is serial. A later phase may begin only when the preceding
phase has produced a traceable result or an explicit blocking state.

## II. Protocol A — emergence of an OPERA FOCALIS

### Phase 0 — regime genealogy

Classify the proposed parent regime as:

- `primitive`;
- `generated`;
- `mixed`;
- `unresolved`.

Only a primitive A, T, or E/Q regime is eligible for the reserved focal
family. A generated or unresolved regime is blocked.

### Phase 1 — parent parsing

Read and identify:

- the parent TENET;
- the parent ROTAS;
- the parent AREPO;
- the parent OPERA;
- the parent SATOR;
- relevant root laws;
- relevant foundational or prior LIBRI;
- SYSTEM_INDEX status and dependencies.

Parsing the five parent roles does not require copying them into a new
folder.

### Phase 2 — parent execution evidence

Execute or inspect authorized executions of the complete parent OPERA.
Record the full operator regime, traversal, input, output, limits, and
failures in LIBER EX OPERA.

The focal primitive MUST remain one operator within the full regime.

### Phase 3 — recurrence

Identify a recurrent need for focal control across:

- more than one prior execution; or
- one sufficiently rich human-authorized investigation containing
  multiple distinguishable cases.

A single attractive example is insufficient.

### Phase 4 — non-redundancy

Test whether the proposal is only:

- an alias;
- a profile;
- a preset;
- an OPERATIO;
- a user task;
- a traversal parameter;
- a SATOR presentation style;
- a domain keyword.

If an existing artifact can represent the behavior without loss, reject
the new OPERA candidate as redundant.

### Phase 5 — graph and traversal test

When graph behavior is claimed:

- resolve the graph capability;
- identify the contextual graph instance;
- validate the versioned edge set;
- verify adjacency or declare mediation;
- distinguish visitation intention from executable walk;
- record every revisit and state delta;
- determine whether an existing ROTA is sufficient.

A new traversal does not by itself justify a new ROTA.

### Phase 6 — class sufficiency

Resolve the five class roles.

Create a new class artifact only when the candidate demonstrates a new
class function:

- new doctrine for TENET;
- new structural regime for ROTAS;
- new admission function for AREPO;
- new executable behavior for OPERA;
- new mediation contract for SATOR.

Focal candidates normally introduce only a new OPERA.

### Phase 7 — single candidate draft

Draft one candidate containing:

- parent OPERA reference;
- focal primitive;
- declared traversal;
- revisit or recapitulation discipline;
- state model;
- focal closure;
- inherited and resolved providers;
- limits and failure conditions.

The draft remains non-runtime and unauthorized.

### Phase 8 — pilots

Test at least:

- one prior case;
- one new case;
- one boundary or counterexample case.

Compare results against the complete parent OPERA, not against an imagined
operator-free baseline.

### Phase 9 — classification

Classify the result as:

- `REJECTED_AS_REDUNDANT`;
- `EVIDENCE_INSUFFICIENT`;
- `RESEARCH_CONTINUES`;
- `PILOT_SUPPORTED`;
- `PROMOTION_REVIEW_REQUESTED`.

No automated classification grants promotion.

### Phase 10 — serial closure

Close, reject, or explicitly suspend the current candidate before
beginning another focal candidate.

Bulk generation of the twenty-seven reserved directions is forbidden.

## III. Protocol B — emergence of a COMPOSITIO OPERARUM

### Stage 1 — capture

Create or identify LIBER EX OPERAE records containing actual ordered,
branched, or revisited multi-OPERA activity.

### Stage 2 — recurrence

Show that the same composition pattern recurs across more than one case.

### Stage 3 — order necessity

Test whether changing order changes admission, state, interpretation, or
closure. If order is irrelevant, the formation may be only a collection.

### Stage 4 — handoff integrity

For every child boundary, record:

- calling OPERA;
- called OPERA;
- input state;
- operatum transferred;
- output state;
- return or termination condition;
- provenance retained.

### Stage 5 — revisit and state

Distinguish:

- internal state of each child OPERA;
- handoff operatum;
- composite state;
- prior visit and state delta for every revisit.

### Stage 6 — classification

Classify the observed formation as:

- unordered collection;
- workflow;
- traversal variant;
- recurrent composition pattern;
- candidate composite OPERA.

### Stage 7 — candidate gate

Draft a composite OPERA only when it has:

- stable identity;
- meaningful order or branching;
- explicit handoffs;
- lawful revisits;
- preserved child boundaries;
- composite state;
- stable closure.

A list of OPERAE never satisfies this gate by itself.

## IV. Protocol C — formation of an applied candidate

### Movement 1 — domain delimitation

Declare the domain, concrete purpose, exclusions, transfer limits, and
known unknowns.

### Movement 2 — core research

Run or inspect relevant A, T, and E/Q operations before stabilizing domain
terminology.

### Movement 3 — foundational LIBRI

Create recoverable research substrate containing sources, data, trials,
failures, and unresolved terms.

### Movement 4 — K/S capability gate

Request subject anchoring only when the domain requires qualified
subject-relation support. Do not focalize K/S as a primitive regime.

### Movement 5 — analogical capability gate

Request analogical calibration only when a relation or proportion is
transferred from source to target.

### Movement 6 — operator assignment

Assign and test operators independently of final domain vocabulary.

### Movement 7 — Q-mediated term test

Test proposed terms through the relevant E/Q questions. Unknown central
terms block stabilization.

### Movement 8 — intermediate derivation

Record how parent operators and evidence yield the proposed applied
structure. Preserve source-target distinction.

### Movement 9 — minimum governance

Resolve exactly five class roles. Reuse compatible providers and create
only artifacts that perform genuinely new functions.

### Movement 10 — pilot

Test prior, new, and boundary cases. Record operator, term, and reality
results separately.

### Movement 11 — transferability

Declare which relations transfer, which properties are suspended, and
which tests failed.

### Movement 12 — correction by ASCENSUS

Trace failures back through term, operator, research, and parent layers.
Link every correction to the prior failure record.

### Movement 13 — versioned DESCENSUS

Produce a versioned candidate only after corrections are incorporated.
The candidate remains non-runtime until separately admitted and promoted.

## V. Evidence and stopping law

Every phase or stage returns one of:

- `PASS`;
- `FAIL`;
- `BLOCKED`;
- `NOT_APPLICABLE`;
- `HUMAN_REVIEW_REQUIRED`.

Missing evidence is not a pass.

An assistant MUST stop and request human review when:

- a candidate would require canonical mutation;
- a dependency status is ambiguous;
- a provider resolves only through an archived artifact;
- a new root or class function is proposed;
- source and target cannot be separated;
- central terms remain insufficiently known;
- promotion, deployment, aliasing, or runtime exposure is requested.

## VI. Final protocol

Research produces LIBRI. Recurrence permits one candidate. Pilots produce
validation and failure memory. Human review alone may promote the result.

The protocol exists to prevent speculative architecture from being
mistaken for an executable stack.