Permitted Substitution Is Not Successful Repair
An original object caused a repair proposal to degrade to a shadow record, while an original number could retain a substitution decision. This contrast came from actual calls to a response-delivery guard. For adapter maintainers, it creates a concrete question: what does compatibility examine before anyone infers successful repair? Ten controlled inputs locate the boundary and identify the records still needed for enactment and benefit evaluation.
Locate the guard before interpreting its result
ARIA studies runtime repair with separate controller, host-delivery and evaluation responsibilities. We examined its final pending-response function, validate_pending_substitution. It retains substitution or degrades to shadow recording without replacement. That decision is not itself a receipt of host enactment. Source: pinned controller
Other inspected source paths include capability checks, so this function must not be treated as the system's entire defense. We selected it because permission to deliver and effective recovery can disappear into one success label. The appendix describes continuation from reconstructed context; repair-record code separately checks patched-only success and verified materialization. None of that execution occurred in our ten calls. Sources: Appendix B.3, repair-record admission
The actual boundary in ten calls
Analysis ran the pinned original function body with actual upstream record types on October 20, 2026 using Windows 11 and Python 3.13.13. Abstract-syntax-tree extraction isolated dependencies while retaining the tested logic. It omitted import-time behavior and host integration. Inputs were explicitly controlled operations, not model outputs or recovered tasks. Production verified hash-bound records and added no experiment.
The complete ten-call set is below. Retained substitution corresponds to substitute; degraded shadow corresponds to shadow, which records without replacing.
| Controlled condition | Observed decision |
|---|---|
| Plain-text replacement | Retain substitution |
| Original response has a protected flag | Degrade to shadow |
| Original response is an object | Degrade to shadow |
| Original response is an array | Degrade to shadow |
| Message role differs | Degrade to shadow |
| Replacement is empty | Degrade to shadow |
| Replacement is unchanged | Degrade to shadow |
| Original is a JSON string scalar | Retain substitution |
| Original is a JSON number scalar | Retain substitution |
| Original is plain text; replacement is itself an object | Retain substitution |
Source: ten internal per-call records, all matching expected outcomes. Raw records remain unpublished and access-restricted. These are neither task-success nor attack-success rates. The code reads host protection metadata and treats original content parsed as an object or array as protected. String and number scalars do not enter that object/array branch. It does not impose the same structural prohibition on replacement content for an original plain-text response. Source: the same pinned pending-substitution function
Accepting a scalar is not yet a vulnerability finding
Objects, arrays, strings and numbers can all be represented in JSON. Parseability is therefore not the full predicate used by this protection rule. Calling it protection for all structured responses would erase the observed distinction. The precise description is object/array recognition for the original response, alongside host-supplied protection metadata.
Accepting a scalar need not be a defect. A host could use protection metadata to mark machine-readable replies as nonreplaceable. Replacing plain text with an object could also satisfy a particular host contract. We did not inspect the complete native-adapter metadata path or test downstream schema enforcement. The asymmetry locates a contract responsibility; it does not establish a reachable production vulnerability or comprehensive defense failure.
A same-day experiment offers a limited comparison. Octagon's credit function checks current object identity and round while delegating remote observation to its caller. Both examined boundaries enforce a local precondition and rely on another layer for the meaning of an effect. Their threat models, objects and acceptance endpoints differ; this is neither security equivalence nor a ranking. Source: pinned credit implementation
Keep proposal, enactment and benefit records separate
Maintainers can inspect existing records by responsibility before interpreting one admission decision as a total outcome. The following is our proposed inspection framework, not a claim that new capabilities have been implemented.
| Stage and responsible party | Input and output to inspect | Condition preventing further inference |
|---|---|---|
| Repair proposer | Original, replacement and rationale | No specified content change |
| Compatibility layer | Protection, role and content; substitute/shadow decision | Protected, incompatible, empty or unchanged content |
| Host enactment | Admitted content and host schema; actual adoption result | Not adopted, adoption failed or contract unclear |
| Evaluation | Actual result and control; recovery and harm records | Missing control, materialization or planned-pool coverage |
Only the second layer's ten inputs were executed locally. Repair-record and reporting duties were source observations; host adoption and evaluation were not run. The inspected report code distinguishes malformed output, explicit constraint violations and enacted score regression, with qualifications for incomplete pools. We measured no recovery rate, harm rate or latency. Source: evaluation reporting implementation
Evidence and sources
The ten calls are internal experimental evidence, not independent validation. Function branches and neighboring responsibilities are our source observations; separating responsibilities is our interpretation. Materials come from two distinct projects, but no independent third party reproduced these ten results. Publication, citation and code release do not close that gap.
The version scope is ARIA v1 and author-repository commit ce68c040cca0796b37fa8ae46e2a87a073f64001, plus Octagon commit 3bb9eb1bef72a454ee455ad3cc321933133cd3eb for qualitative comparison. Sources were read and experiments completed on October 20, 2026. Internal scripts and results remain in an access-restricted local research archive. Source links provide inspection entry points, but this article does not claim to contain a complete public rerun package.
The next verification must cross the host
We did not run the whole controller, native adapters, model inference, training, paired continuations or benchmark tasks. A free-form text host might face no material risk from this object/scalar distinction; a strict-schema host needs to examine its actual integration contract.
Two concrete questions remain: which host metadata protects machine-readable scalars, and where is admitted replacement content schema-checked and actually enacted? Binding proposal, compatibility decision, host enactment and final evaluation would create grounds for discussing repair benefit. Current evidence supports an accurate description of this one local boundary.