Runtime-Signed Adaptation Artifacts
by Nick Clark | Published April 25, 2026
Spatial adaptation requires that the artifacts loaded into a running system, including skills, behavior policies, machine-learning model weights, parameter sets, and rule packs, be cryptographically signed at the moment of issuance and that the binding signature commit not only to artifact content but to the capability scope under which the artifact may execute. Activation requires both signature validity and admissibility evaluation against deployment context. Sandbox pre-activation certification gates live operation. Versioned artifact lineage is preserved end-to-end, and cascade deactivation removes derived activations whenever a signing authority revokes upstream credentials.
Mechanism
The mechanism begins with credentialed adaptation authorities issuing artifacts under signing keys that are themselves bound, by the five-property chain trust substrate, to a declared role and a bounded capability envelope. An artifact, in this disclosure, is any unit of executable or interpreted material that modifies the runtime behavior of a node, including but not limited to behavior policies, skill bundles, neural-network weights, decision-tree ensembles, configuration overlays, prompt templates, sensor-fusion calibrations, planning heuristics, and constraint catalogs. At issuance, the authority computes a content hash over the artifact bytes, attaches a capability descriptor that enumerates the operational scopes the artifact is permitted to influence, and produces a detached signature over the tuple of content hash, capability descriptor, version identifier, predecessor identifier, and validity window.
When a node receives a candidate artifact for loading, the activation pipeline performs four sequential checks before any code path is permitted to take effect. First, signature verification confirms cryptographic integrity against the issuing authority's published key material. Second, capability admissibility evaluates whether the declared capability descriptor is consistent with the node's deployment context, including jurisdiction, mission profile, hardware class, and currently composed authority set. Third, sandbox certification executes the artifact within an isolated execution environment supplied with a representative sample of recent observation traces; the sandbox produces a certification observation that is itself signed and recorded. Fourth, lineage attachment registers the artifact's version identifier and predecessor pointer into the local artifact lineage record, enabling downstream auditors to reconstruct the chain of derivations.
Only after all four steps complete with affirmative outcomes does the artifact enter live operation. A failure at any step yields a refusal observation rather than silent rejection, so that the refusal itself is observable, attributable, and admissible as a primitive in downstream composition. Cascade deactivation completes the mechanism: when a signing authority revokes a key, an issuance, or a capability scope, the revocation propagates through the lineage record and forces deactivation of every artifact whose validity depends on the revoked element, including transitively derived artifacts whose predecessors are no longer trusted.
The mechanism, as disclosed in U.S. provisional application 64/049,409, is structurally distinct from a code-signing pipeline because the four sequential checks are not separable engineering stages but a single admissibility evaluation whose intermediate outputs are themselves signed observations. A node that bypasses or reorders these checks produces an unsigned activation, which downstream consumers refuse on contact; the integrity of the mechanism therefore does not rely on each node's discipline but on the chain's structural insistence that every activation carry the certification observation produced by the pipeline.
Operating Parameters
The signature scheme is parameterized by algorithm family (elliptic-curve, lattice-based, or hybrid post-quantum), key length, signing context separation tags, and validity window. Typical deployments use Ed25519 or ECDSA over secp256r1 for current operations and a parallel post-quantum signature (for example, ML-DSA) for forward-secure validation. Validity windows are class-dependent: high-cadence behavior policies may carry windows of minutes, while certified model weights may carry windows of weeks, with revocation lists providing the early-termination path.
Capability descriptors are expressed as structured constraint sets that bind the artifact to a scope of effect. Representative constraint dimensions include sensor channels read, actuator channels written, jurisdictional zones traversed, mission classes engaged, peer node classes consulted, energy or compute budgets consumed, and externally observable side-effect categories. Admissibility evaluation reduces to a containment check between the descriptor and the deployment context's permitted scope, with explicit refusal for any dimension that is unbounded or extends beyond context.
Sandbox certification operates against a representative trace corpus assembled from recent admissible observations at the receiving node and at peer nodes within the same composition. The corpus is sized to exercise the artifact across declared input ranges; certification metrics include determinism under repeated input, bounded resource consumption, absence of forbidden side-effect signatures, and conformance with declared output schemata. The certification observation is retained as a primitive event whose later admissibility may be re-evaluated as deployment context evolves.
Lineage records are append-only and content-addressed. Each entry records artifact hash, predecessor hash, signing authority identifier, capability descriptor, certification observation reference, activation timestamp, and deactivation timestamp once present. Storage is local to each node with optional replication into a chain trust substrate so that cross-node audits can reconstruct activation history under bounded trust assumptions.
Alternative Embodiments
One embodiment confines runtime signing to behavior policies and skill bundles, leaving model weights to a separate offline supply chain; this reduces signing throughput requirements at the cost of weaker dynamic provenance for learned components. A second embodiment extends signing to per-inference adaptation deltas, so that gradient updates emitted by federated training rounds carry signatures with capability descriptors limiting which downstream deployments may consume them. A third embodiment uses threshold signing across a quorum of adaptation authorities, producing artifacts whose validity requires that no single authority be compromised; this composes naturally with multi-jurisdictional governance.
A further embodiment substitutes attestation-bound signing keys, where the signing key is held within a hardware security module whose attestation report is itself a verifiable credential. The verifier checks both the signature and the attestation, ensuring that the key has never left a trusted execution environment. An embodiment for constrained edge nodes deploys a deferred-certification model, in which sandbox execution occurs on a paired companion node before the artifact is permitted to activate on the constrained device.
Composition with Other Primitives
Runtime-signed artifacts compose with the cascade-propagation primitive: revocation by an upstream authority triggers refusal observations at each downstream node, and those refusals propagate through the same observation channels used for any other admissibility decision. The result is that a compromised or expired artifact does not merely cease to operate; it produces an auditable trail of refusals that downstream consumers admit as evidence.
Composition with the governed-marketplace primitive supports artifact-as-commodity exchange, in which adaptation packages are listed, priced, and allocated under marketplace rules while their cryptographic provenance remains intact across the transfer. Composition with health-monitoring primitives admits sandbox certification observations into per-device and fleet-level health attestations, so that activation history contributes directly to operational fitness assessments. Composition with the bilateral primitive allows cross-authority artifact exchange, where each side admits the other's artifacts under explicit settlement rules.
Distinction from Prior Art
Conventional code-signing infrastructures, including operating-system package signing and mobile-application signing, bind signatures to artifact bytes alone and treat capability scope as a runtime concern handled by sandboxing or operating-system permissions. They do not bind capability scope into the signed object itself, do not require admissibility evaluation against deployment context as a precondition for activation, and do not maintain lineage records that survive cascading revocation across derived artifacts.
Conventional model registries record version, hash, and authorship but do not enforce sandbox pre-activation certification as a structural gate, and they typically express capability scope as documentation rather than as a verifiable constraint that the runtime enforces. The present mechanism unifies signing, scope binding, admissibility, sandbox certification, and lineage into a single primitive that other primitives compose with directly.
Failure Modes and Recovery
The mechanism contemplates four primary failure modes and their recovery paths. The first is signature failure, in which the attached signature does not verify against the asserted authority's published key material; recovery requires that the artifact be re-issued by an authority whose credentials remain valid. The second is admissibility failure, in which the capability descriptor is not contained within the deployment context's permitted scope; recovery requires either narrowing the descriptor at re-issuance or expanding the deployment context's permitted scope through the appropriate governance procedure, both of which produce auditable observations.
The third failure mode is sandbox certification failure, in which the artifact violates a determinism, resource, side-effect, or schema constraint during pre-activation execution; recovery requires either remediation of the artifact's source, adjustment of the certification corpus to better reflect intended deployment, or explicit acknowledgement that the artifact is not suitable for the target node class. The fourth is lineage failure, in which the predecessor pointer references an artifact no longer present in the lineage record or no longer trusted; recovery requires reconstruction of the missing lineage segment or re-issuance of a fresh lineage rooted at a currently trusted predecessor. In each case the failure observation itself is signed and admitted, so that the operational record reflects not only the artifacts that activated but the artifacts that did not, and the reasons.
Disclosure Scope
This disclosure encompasses the artifact data structure, the activation pipeline, the capability descriptor schema, the sandbox certification protocol, the lineage record format, the cascade deactivation propagation rule, and the composition interfaces by which other primitives consume signed-artifact events. It is intended to cover applications spanning autonomous defense systems, civilian critical-infrastructure controllers, distributed energy resource fleets, robotics deployments, and any other domain in which runtime adaptation must remain auditable, revocable, and bounded by capability scope.