3.1. Mission Admission Contract and Trust Boundary
A natural-language mission instruction in a UAV scenario is a joint request over system capability, safety boundaries, and mission consequences. We first define the Mission Admission Contract to clarify the boundary among the operator request, trusted environment, protected constraints, and system admission responsibility.
Let the operator’s natural-language mission instruction be
. The instruction may contain mission objectives, target areas, observation windows, execution order, payload requirements, communication-return requirements, soft preferences, and abort conditions. EAMSR constructs a base Mission Admission Contract
from
x:
In this definition,
is the base contract derived from the original instruction;
denotes the trusted UAV context, including the UAV capability model, initial state, mission environment, map, target locations, weather, communication coverage, time windows, and payload status.
denotes protected operational invariants, including return reserves, no-fly zones, geofences, altitude limits, payload limits, operating rules, and emergency-abort conditions.
denotes the mission-request obligations proposed by the natural-language instruction.
denotes the governance policy, including source verification, authority levels, and mutability rules.
denotes the evidence base, including text anchors, trusted context facts, protected constraints, and system default rules.
denotes the UAV task-level backend model. Candidate contracts
(Equation (
15)) are generated from
by the LLM and form the candidate set
where
, as duplicate candidates are discarded (
Section 3.2).
When admission succeeds, the system selects a contract
and extracts its admitted mission obligations
, where
denotes the hard goals and hard constraints,
the soft preferences, and
the pending clauses. A task-level plan witness
must satisfy the hard obligations:
Soft preferences influence candidate selection (Equation (
32)) but are not backend proof obligations; pending clauses cannot enter
and therefore do not affect witness closure.
is retained in the selected contract and audit trail for completeness but does not constitute a downstream obligation; any pending clause with consequence relevance must trigger CLARIFY before admission can proceed. The EAMSR admission objective is defined as
subject to
The trust boundary of EAMSR is limited to the pre-execution admission layer between task submission and task planning. This layer handles task goals, spatial regions, time windows, payloads, communication, energy, return reserves, restricted airspace, and abort conditions. Low-level path planning, continuous obstacle avoidance, flight control, and runtime safety monitoring are delegated to downstream execution modules.
3.2. Contract Instantiation for Natural-Language Mission Requests
The first admission risk of natural-language UAV tasks arises from semantic grounding. A single instruction may contain goals, regions, time constraints, payload requirements, and communication requirements. These contents fall into three categories: evidence-supported, clarification-required, and LLM-introduced completions. Contract instantiation converts the natural-language request into clause-level, evidence-carrying, and auditable candidate mission obligations.
EAMSR extracts requirement anchors from the instruction
x:
Each anchor
is a text span with independent mission meaning. The extraction procedure operates in four steps: (i) span detection segments the instruction at linguistic boundaries (clauses, conjunctions, conditionals) to identify candidate spans; (ii) ontology slot assignment maps each span to a clause type in the UAV ontology (temporal, spatial, communication, payload, etc.); (iii) modality identification labels each span as hard, soft, optional, or conditional based on linguistic cues (imperative, “if possible”, “as needed”); (iv) validation checks whether each span has a clear referent in
and a deterministic ontology relation. All four steps use deterministic linguistic rules and ontology lookups; no LLM is involved in anchor extraction. Anchor extraction is implemented deterministically and is treated as trusted preprocessing in the present evaluation; extraction correctness is therefore an explicit assumption. Spans that fail validation (e.g., vague referents, unresolved negation scope, or cross-clause dependencies without explicit conjunction) are marked as
pending and excluded from clause generation. This procedure prevents the LLM from interpreting its own completions as user-confirmed requirements.
Under the UAV mission ontology
and trusted context
, the LLM generates one candidate contract clause for each validated anchor:
The set of all candidate clauses for a single generation pass is denoted
, where
n is the number of validated anchors.
To produce multiple candidate contracts, EAMSR performs up to
repeated LLM invocations under the same decoding settings. In the evaluated configuration, temperature is 0; candidate variation therefore arises only from residual model-serving nondeterminism or alternative structured assignments returned for ambiguous anchors. Each invocation generates a complete clause set
from the same anchor set
; the clause sets are then assembled into candidate mission obligations
and candidate MACs
(Equations (
14) and (
15)). The resulting candidate set is
, where
. Each generation attempt consumes one unit of the candidate budget
; duplicate candidates (identical clause sets) are detected by hash comparison, discarded, and recorded in the audit trail. Consequently, the final candidate set satisfies
(the lower bound is reached only if all generation attempts produce unparseable responses, which triggers
), and the total number of LLM invocations remains bounded by
(Property 4). In the evaluated configuration,
was selected based on a pilot study on a separate 20-task development subset: increasing
beyond 5 yielded diminishing returns in coverage (fewer than 2% additional governance-admissible candidates), while
occasionally left no governance-admissible candidate for tasks where a single LLM pass produced an incompatible clause assignment. A candidate clause is defined as
The fields are as follows:
is the clause identifier;
is a text anchor or trusted-context pointer;
is the UAV clause family;
is the formal task semantics;
is hard, soft, optional, default, or pending;
is the source category;
is the evidence pointer;
is the authority level;
is the allowed modification mode; and
is the trust status.
The
field classifies the origin of each clause into five categories (
Table 3), which determines its default authority level and mutability. User-explicit clauses carry the highest authority among user-originated sources, but remain subordinate to applicable regulatory constraints and are treated as immutable hard intent unless the user authorizes modification. When the user subsequently authorizes a modification to a previously immutable user-explicit clause, this authorization creates a new authoritative anchor (an updated request version) rather than retroactively mutating the original clause; the original clause is preserved in the audit trail, and the refined contract carries the new anchor with the user’s explicit authorization. Clauses derived from trusted context (e.g., weather data, airspace maps, vehicle specifications) inherit the authority of their source. Clauses introduced by the LLM during candidate generation or repair are labeled as hypothetical and must be verified before entering hard obligations.
A clause
may be labeled
only if it can be derived from an explicit anchor
and a deterministic ontology rule
:
If no such derivation exists, the clause is labeled
with trust
, preventing unsupported LLM completions from hardening into protected obligations.
The evaluated UAV ontology
contains 8 clause families (
Table 4), 42 normalized predicate templates, 15 relation types (including temporal precedence, spatial containment, resource dependency, and authority delegation), and 6 entity types (vehicle, waypoint, region, sensor, payload, communication node). The deterministic ontology rules
used for
derivation comprise 28 rules, each expressed as a Horn-clause implication over the predicate vocabulary. The full ontology specification and rule set are available in the reproducibility package.
The governance layer computes ternary semantic support for each candidate clause:
In this classification, Y indicates evidence support, N indicates evidence exclusion or invalid source, and U indicates insufficient evidence. The three-valued support classification is defined relative to the single resolved highest-priority applicable evidence source after authority and freshness conflict resolution, ensuring mutual exclusivity.
means that the resolved highest-priority applicable fresh evidence source supports
.
means that the resolved highest-priority applicable evidence source contradicts
, or no admissible evidence source remains after authority/freshness validation (invalid source).
means that no resolved admissible source supports or contradicts
(insufficient evidence), so the clause cannot enter a hard obligation but may remain as a pending item. Evidence freshness is verified by comparing evidence timestamps against context-defined validity windows: weather data, communication coverage, and airspace restrictions are checked against their respective update intervals, while battery state and payload availability are treated as real-time context fields. When two trusted-context facts conflict (e.g., two weather sources report different wind speeds), the governance policy specifies a priority order: regulatory sources override commercial data services, and more recent readings override older ones at the same authority level. A clause can enter a hard mission obligation only if
New statements generated by the LLM during candidate generation or repair are labeled as untrusted semantic increments. For an LLM suggestion
p, its claim set is decomposed as
In this decomposition,
contains reused claims traceable to user anchors or trusted context;
contains derived claims entailed by rules, backend models, or protected constraints; and
contains hypothetical claims introduced only by the LLM without external evidence. Hard clauses in admitted mission obligations must satisfy
where
extracts the set of atomic claims from a clause set, as defined in Equation (
12). This constraint confines unverified assumptions to pending items, clarification requests, or the audit trail.
The
field in the clause structure records the verification status of each clause, taking values from {trusted, derived, hypothetical, pending} (
Table 5).
After clause labeling, EAMSR assembles candidate clauses into candidate mission obligations:
where
is the set of hard goals and hard constraints,
is the set of soft preferences, and
is the set of pending clauses. The corresponding candidate MAC is
EAMSR also maintains the clause-evidence trace relation
and the anchor coverage relation
Missing coverage of explicit anchors forms pending contract content. When pending content affects mission consequences, the system enters the clarification process.
3.3. Contract Admission Under Proof-Obligation Gating
The second class of UAV admission risk comes from task specifications that are formally complete but governance-invalid. A task clause may have readable semantics but lack evidence, exceed source authority, modify non-negotiable constraints, or contain LLM-added assumptions. The proof-obligation gate converts these risks into a unified contract-admission predicate.
EAMSR defines candidate admission in three stages. The governance gate checks evidence, authority, mutability, and untrusted-semantic-isolation obligations:
Candidates that pass governance form the governance-admissible set:
If
, the system computes consequence signatures and screens pairwise compatibility at the set level using the
predicate (defined in Equation (
37)). If the set is consistent, a candidate
is selected; the final admission requires a backend witness:
This order avoids circularity: consequence screening is evaluated only on governance-admissible candidates. The backend witness
(Equation (
25)) is then checked separately; an ADMIT decision requires both
and a concrete witness
(Equation (
48)).
The evidence obligation
requires all hard mission obligations to be supported by admissible evidence or a deterministic trusted derivation:
The authority obligation
requires source, authority level, and modal strength to be consistent:
The governance policy
defines a hierarchy of authority levels (
Table 6). When two sources at different authority levels conflict, the higher-authority source prevails. Sources at the same authority level are resolved by recency (more recent prevails) or, if timestamps are equal, by the governance-specified tie-breaking rule. An operator can override a system default at the operational level, and an emergency rule can override a normal geofence policy, but no source can override a regulatory constraint.
Emergency is not a standing authority level in
Table 6; it is a context-dependent override condition activated by a declared contingency (e.g., imminent hazard, medical urgency) that carries the authority of the declaring source (typically operator-level) and is recorded with its triggering condition in the audit trail. An emergency override does not create a new clause authority level; it authorizes a temporary relaxation of specific non-regulatory constraints (geofence buffers, time windows, communication requirements) for the duration of the declared contingency, after which the standard hierarchy resumes. Regulatory constraints remain non-overridable even under emergency conditions.
The mutability obligation
requires every clause edit to belong to the transformation relation allowed by the governance policy:
The transformation relation
defines the allowed modifications for each clause based on its mutability classification (
Table 7). The mutability field interacts with the source field: clauses with source
and mutability
can only be kept; clauses with source
and mutability
can be weakened, dropped, or replaced. The refinement relaxation priority is specified by the governance policy
; the evaluated configuration relaxes constraints in the order temporal first, then spatial, then communication, then payload, so that operationally critical spatial and payload constraints are preserved as long as possible. Different mission types may benefit from different priority orderings (e.g., emergency delivery may prioritize temporal relaxation, while inspection may prioritize spatial preservation); the framework supports such configuration through
.
The untrusted-semantic-isolation obligation
requires hard mission obligations to contain no unverified hypothetical claims:
where
denotes the set of atomic claims extracted from the hard clause set
, and
is the set of LLM-introduced hypothetical claims without external evidence.
The backend executability obligation
requires the existence of a task-level plan witness:
where the
predicate is defined in Equation (
39).
To illustrate the authority and mutability model, consider a powerline-inspection mission in controlled airspace. The regulatory constraint “no flight above 120 m in Class C airspace” is immutable at the regulatory level: no operator or system default can modify it. The operator’s requirement to “inspect towers A through D” is protected at the operator level: the set of inspection targets can be clarified (e.g., if tower C is in a temporary restricted area) but the core inspection objective must be preserved. For the return reserve, we distinguish the non-overridable regulatory lower bound from the operational system default , which satisfies . The system default is overridable at the operational level: an operator may increase it to 20% for conservative missions but cannot decrease it below . An LLM-suggested clause “use thermal camera for night inspection” is revocable: if no thermal camera is available in the payload, this clause is dropped without affecting the inspection objective. When the LLM proposes reducing the return reserve to 5% to extend inspection time, this proposal is rejected because the policy specifies a protected minimum (an immutable constraint at the regulatory level), enforced by , and because the LLM-suggestion source lacks the authority to modify any return-reserve parameter, enforced by .
3.4. Authority-Bounded Contract Refinement and Mission-Consequence Clarification
The third class of UAV admission risk arises from automatic repair of infeasible tasks. Executability conflicts may result from overly tight time windows, restricted target regions, insufficient communication coverage, payload mismatch, or insufficient return reserve. A refinement mechanism must restore executability while preserving protected invariants, user hard intent, and evidence boundaries.
When direct admission fails, the backend diagnosis interface returns a conflict core:
where
contains the task clauses, protected invariants, and backend constraints responsible for unsatisfiability. The governance layer converts
into a structured diagnostic feedback package:
Under the constraint of
, the LLM proposes a repair suggestion:
In this proposal,
is the mission-obligation difference;
is one of weaken, drop, default, split, mark-pending, or clarify; and
declares the expected change in mission consequences. Mission consequences are defined by the EAMSR consequence-signature function.
We define the authority-admissible refinement relation as
This relation holds if and only if the following criteria hold jointly:
In this constraint,
indicates preservation of protected operational invariants, and
indicates preservation of user hard intent. The term
indicates that unverified assumptions do not enter hard mission obligations.
Among candidates satisfying
, EAMSR selects the minimum-cost governance-admissible refinement candidate:
In this objective,
is semantic displacement,
is the number of edits,
is soft-preference loss, and
is the estimated mission-energy cost produced by
. Note that
is a lightweight diagnostic estimate of the energy required to execute the candidate’s mission profile, not the cost of the final witness
, which is generated only after
is selected. This separation avoids a circular dependency in which candidate selection would require a witness that is only produced after selection. Because these terms have different native scales, each is normalized to
before weighting:
where
is the refinement budget and
is a reference diagnostic cost (the battery-energy capacity in the evaluated configuration). The displacement and preference distances
require no additional normalization. The coefficients satisfy
and
, so that each normalized term contributes a bounded share of the total cost. The evaluated configuration uses the uniform profile
; non-uniform profiles can be configured when a governance policy prioritizes, for example, minimal semantic displacement over plan cost.
Natural-language ambiguity in UAV tasks is screened through a mission-consequence signature. For a candidate contract
C, define
The components of
are as follows:
denotes executability;
denotes the set of hard goals;
denotes the set of optional tasks;
denotes the required order closure;
denotes the minimum return-energy margin;
denotes the minimum time-window margin;
denotes airspace and geofence compliance;
denotes communication and data-return feasibility;
denotes payload and sensor satisfaction; and
denotes weather and observation-condition satisfaction.
Each component of
is normalized to
so that heterogeneous Boolean, categorical, and numerical quantities can be combined, and the component distances are defined per component family as summarized in
Table 8. The mission-consequence distance between two contracts is the weighted average of the component distances:
The normalization keeps
, so that the compatibility threshold
has a uniform interpretation across mission types. The evaluated configuration uses uniform weights
for
.
The backend provides two interfaces. is a lightweight task-level diagnostic evaluated for all governance-admissible candidates; it produces satisfaction ratios for feasibility, airspace compliance, communication coverage, payload, and weather without constructing a full action sequence. These ratios feed the consequence signature and enable mission-consequence screening (MCS) before candidate selection. The final backend witness is generated only for the selected candidate ; it constructs a complete action sequence and verifies SafeRTH, GeoSafe, and AuxOK on the full plan.
A single global weighted-average threshold can mask large changes in individual critical dimensions: with 10 uniform-weight components, a complete reversal in one dimension (
) contributes only 0.1 to
, which may remain below
. To prevent this, the compatibility relation augments the global threshold with a per-dimension hard veto on critical components. Given threshold
and per-dimension thresholds
, mission-consequence compatibility is defined as
where
is the set of critical dimensions whose individual changes must not exceed per-dimension thresholds
, and the remaining components (optional preferences, order, communication, payload, weather, window) are evaluated only through the weighted average. In the evaluated configuration,
for all
, so that any critical-dimension change exceeding 30% of its normalized range triggers incompatibility regardless of the aggregate distance. The threshold
was selected using the same 20-task development subset used for
and
: values below 0.2 caused spurious CLARIFY decisions for contracts that differed only in non-critical refinements, while values above 0.4 allowed goal-set reversals that the aggregate distance alone would have caught. The framework admits dimension-specific thresholds or governance-defined compatibility criteria through the weights
and per-dimension configuration; calibrating such criteria with operational stakeholders is a direction for future work.
Because each component distance is normalized to
and
is a weighted average, the relation
is reflexive and symmetric. It is generally not transitive—candidates
A,
B, and
C may satisfy the veto and aggregate conditions pairwise for
and
while failing for
—so
is a tolerance relation, not a strict equivalence. To decide whether a candidate set is consequence-consistent, we require pairwise compatibility under Equation (
36):
When admissible candidates or refinement candidates do not satisfy pairwise consistency, the system returns
. When all admissible candidates are pairwise compatible, the system selects
according to semantic displacement, soft-preference satisfaction, and estimated mission-energy cost.
Four examples illustrate consequence compatibility and its violation under the evaluated configuration (, , uniform weights). (i) Two contracts share all components except the return-energy margin, whose raw values of 0.15 and 0.18 give normalized margins and ; the resulting distance is and no critical-dimension distance exceeds , so the contracts are consequence-compatible. (ii) Two contracts differ only in the time-window margin () and payload satisfaction (), giving ; they are likewise compatible, and the refinement that better satisfies soft preferences is selected without clarification. Conversely, clarification is triggered when candidates are not pairwise compatible. (iii) Two candidate contracts with disjoint hard-goal sets () trigger the critical-dimension veto, so the pair is incompatible regardless of the aggregate distance. (iv) A candidate whose feasibility, airspace, and communication components are degraded () likewise triggers the veto through feas and airspace (both in ); the communication degradation () does not enter the veto, since comm is not in , and contributes only to the aggregate . In both cases, the system returns instead of silently selecting one consequence outcome.
3.5. Backend Plan Witness, Audit Trail, and Method Properties
The final admission risk is a specification that is semantically reasonable but task-inexecutable. The backend witness layer binds the admitted contract to UAV task constraints, so that each ADMIT output carries task-level executability evidence.
Let the plan witness be a finite action sequence:
where
is a task-level action such as takeoff, navigation, inspection, imaging, hovering, data return, delivery, return-to-home, or abort, and
and
are the start and end times of the action.
The backend witness condition is
where
is the set of hard goals and hard constraints extracted from the selected contract
. Soft preferences
influence candidate ranking (Equation (
32)) but are not part of the witness condition, and pending clauses
are excluded from
by the evidence obligation
. This paper uses return-to-home safety and airspace safety as core UAV safety constraints, while communication, payload, time-window, and weather constraints are incorporated into
.
Return-to-home safety is defined as
where
is a safety buffer on the return-to-home energy estimate,
is the effective available energy at time
t (the SOC-corrected remaining energy defined in Equation (
42)),
is the minimum energy required to safely return from the current position, and
is the safety reserve. The return-to-home energy estimate
accounts for horizontal distance to the home position, vertical altitude difference, landing energy, and a 30 s pre-landing hover:
where
Wh/m,
Wh/m,
Wh, and
Wh. The safety reserve is
Wh. When the battery state of charge (SOC) falls below 30%, the effective available energy is reduced by a piecewise correction factor
that accounts for increased internal resistance at low charge levels:
so that at
the correction factor is
. The normalized energy margin at each time point is
, and the SafeRTH condition in Equation (
40) is equivalent to requiring
at all sampled times.
Airspace safety is defined as
In this equation,
is the set of no-fly zones, and
is the permitted operational airspace.
Other task-level constraints are represented by the unified predicate
The backend witness evaluates the candidate contract against a task-level discrete UAV simulation model. The simulator maintains a state vector at sampled time points along the witness plan, tracking position (local Cartesian coordinates in metres), remaining battery energy, communication coverage ratio, payload status, and elapsed mission time. The witness plan is a finite sequence of task-level actions, where each action type has an associated energy cost model and switch overhead (
Table 9).
Witness-plan generation uses a greedy forward search with bounded backtracking over the task-level action vocabulary, advancing the state vector at a fixed 1 s timestep and checking all safety and auxiliary predicates at each step. The search terminates when a complete feasible plan is found, all branches within the depth limit are exhausted, or the per-contract wall-clock budget of 5 s is reached. The action priority ordering is takeoff → fly (to first target) → inspect/capture/deliver (mission actions in goal order) → transmit (if required) → return → landing, with abort inserted at any point if SafeRTH is violated. Backtracking reorders optional mission actions and adjusts waypoint sequencing within the depth limit
. The same L1 backend model is used for benchmark label construction and admission decisions; this shared dependency is acknowledged as a limitation in
Section 4.6.
The present backend uses a simplified task-level energy proxy: the energy model accounts for horizontal distance, vertical altitude, landing, and hover, but does not model continuous wind- or payload-dependent aerodynamic power consumption. Wind speed is checked as a binary threshold in , and payload affects sensor availability rather than energy draw. This simplification is intentional for the task-level admission layer, where the goal is to verify executability at the mission-specification level rather than to produce a flight-controller-grade trajectory energy estimate.
Communication coverage is evaluated using a distance-based attenuation model rather than a binary in/out check. The coverage ratio decreases linearly from 1.0 inside the inner radius () to 0.0 at the outer radius (), and the plan passes when the minimum coverage ratio along the flight path is at least 0.5. The auxiliary constraints verify that: (i) a data-return action exists when communication is required; (ii) all sensors specified in payload clauses are available; (iii) all actions fall within their designated time windows; and (iv) no action exceeds the maximum wind speed from weather constraints.
The abstract witness condition was defined in Equation (
39). The UAV task model
is decomposed into implementation-level predicates:
where
captures scenario-specific constraints not covered by the three standard predicates. Substituting Equation (
45) into Equation (
39) yields the implementation-level witness used in the evaluation:
A failed witness attempt does not by itself establish infeasibility: the search is bounded by and a wall-clock budget, so termination without a witness does not prove that no witness exists. Contract-level infeasibility is reported only when the backend returns a conclusive infeasibility status (Equation (47)); otherwise, failure to construct a witness remains inconclusive. The witness verification collects all violations without early exit, producing a structured conflict-core diagnosis that identifies the specific clauses, protected invariants, and backend constraints responsible for unsatisfiability. Verification completes in under 5 s per contract on a single core.
Because witness search is bounded, the backend therefore reports a three-valued status:
WitnessFound means that a concrete witness
satisfying Equation (
46) has been constructed; it can support an ADMIT decision.
ConclusiveInfeasible means that unsatisfiability is conclusively established under the declared backend model: the diagnosis identifies a deterministic conflict with an immutable or protected constraint that no authority-bounded refinement can remove (e.g., a hard energy deficit against battery capacity, or an airspace breach of a non-overridable no-fly zone), or the search has exhaustively covered the finite task-level action space declared for the scenario without finding a witness. Only
ConclusiveInfeasible can support a REJECT decision.
Inconclusive covers the remaining outcomes—wall-clock timeout, exhaustion of the depth or backtracking budget, or termination without a witness and without a conclusive infeasibility certificate.
Inconclusive is not treated as proof of infeasibility: the blocking condition is considered unresolved and the request is returned as CLARIFY, since a refined contract, additional operator input, or a larger search budget might still yield a witness.
The final decision rule is
REJECT asserts that no admissible resolution exists within the currently declared trusted context, governance policy, protected constraints, admissible refinement space, and conclusively evaluated backend conditions; it does not assert that the mission can never become executable under any future evidence, authorization, or refinement. Failure to obtain a witness solely because of search-depth or wall-clock limits is treated as unresolved (Inconclusive) and leads to CLARIFY rather than REJECT, preserving the conservative direction of the admission boundary.
EAMSR outputs the audit trail
This trail connects natural-language anchors, candidate clauses, evidence sources, anchor coverage, authority states, mutability states, untrusted semantic increments, proof-obligation results, conflict cores, refinement edits, mission-consequence signatures, backend plan witnesses, and the final admission decision.
The following properties are specification-level properties of the abstract admission model. They hold provided that clause extraction, evidence status, authority assignments, governance policy, and backend predicates are implemented consistently with the formal definitions; they do not constitute machine-verified guarantees of the complete operational system.
Property 1: Protected-invariant preservation. If
and
marks
c as immutable, then every ADMIT output preserves
c:
This holds because the mutability proof obligation
and
jointly exclude any candidate that modifies, weakens, or removes protected invariants from the admissible refinement set.
Property 2: Represented user hard intent cannot be silently modified. Given correct anchor extraction, if a user hard intent
conflicts with protected constraints or the backend model, the system returns CLARIFY or REJECT:
The preservation constraint and the mission-consequence clarification rule jointly guarantee this property. The qualifier “represented” is necessary because anchor extraction is treated as trusted preprocessing (
Section 3.2); if the extractor omits a user hard intent, the governance layer has no opportunity to protect it.
Property 3: Unverified assumptions do not propagate. If an atomic claim
belongs to
and cannot be verified by
,
, or
, then
does not enter any admitted hard mission obligation:
This is a direct consequence of the untrusted-isolation proof obligation
. Unverified semantic increments remain in pending items, clarification requests, or the audit trail.
Property 4: Bounded closure. Algorithm 1 performs at most
candidate-generation iterations (counter
b) followed by at most
refinement iterations (counter
r), with duplicate candidates prevented from resubmission. The total number of LLM invocations is therefore bounded by
This property establishes EAMSR as a bounded admission-closure process.
Assumptions and guarantee boundary. Properties 1–4 are conditional on the five explicit assumptions in
Table 10. Under A1–A5, an ADMIT decision enforces the specified admission predicate
by construction; the properties do not constitute machine-verified guarantees of the complete operational system, and A5 makes explicit that a missing witness is never interpreted as proof of infeasibility unless the backend conclusively establishes it (Equation (47)).
| Algorithm 1 EAMSR mission admission via evidence-carrying MAC. |
Require: Instruction x, context , invariants , policy , evidence , backend , candidate budget , refinement budget Ensure: , , ,
- 1:
Extract anchors from x. - 2:
Initialize , , , Unset, , . - 3:
while do - 4:
Generate response and parse clause set via Equation ( 7). - 5:
if the response is parseable then - 6:
Assemble candidate . - 7:
if is not a duplicate of any existing candidate then - 8:
Add to . - 9:
end if - 10:
else - 11:
Record ParseFailure in . - 12:
end if - 13:
. - 14:
end while - 15:
if then - 16:
; assemble and - 17:
return . - 18:
end if - 19:
while Unset and do - 20:
Apply to obtain . - 21:
if then - 22:
. - 23:
if is governance-remediable and then - 24:
; . - 25:
else - 26:
if is an immutable/protected-requirement conflict, else . - 27:
end if - 28:
else - 29:
Compute ; screen . - 30:
if then - 31:
Select via Equation ( 32); run the bounded witness search for (Equation (47)). - 32:
if = WitnessFound with witness then - 33:
; . - 34:
else - 35:
. - 36:
if is backend-remediable and then - 37:
; . - 38:
else if = Conclusiveinfeasible then - 39:
. - 40:
else - 41:
(Inconclusive or operator input required). - 42:
end if - 43:
end if - 44:
else - 45:
. - 46:
if is consequence-remediable and then - 47:
; . - 48:
else - 49:
. - 50:
end if - 51:
end if - 52:
end if - 53:
end while - 54:
if = Unset then - 55:
. - 56:
end if - 57:
Assemble and - 58:
return .
|