Integrity Field Portability
by Nick Clark | Published March 27, 2026
Integrity coherence fields are portable across application domains, including medical decision support, financial advisement, and defense planning, provided the cross-domain transfer is performed under a bounded mapping declared in policy and is itself audited as a discrete artifact. Portability does not mean a single field instance is reused without transformation; it means the same structural field, instantiated in a new domain, is connected to its prior instantiation by a signed mapping whose validity is independently checkable.
Mechanism
The integrity coherence field, as defined in Chapter 3 of the cognition patent, is a structural artifact whose canonical sub-fields, declared bounds, and admissibility predicates are domain-neutral in form but domain-specific in content. The form is the same across medical, financial, and defense embodiments: each carries identifiers for declared bounds, a violation history, a remediation engagement counter, and a current admissibility indicator. The content, including which bounds are declared and which predicates apply, varies by domain because the operative policies differ.
A bounded mapping is a declared, signed artifact that connects a source-domain field instance to a target-domain field instance. The mapping enumerates, for each canonical sub-field in the source, the corresponding sub-field in the target and the transformation rule that connects them. Transformation rules are themselves declarative: identity, scalar rescaling, predicate substitution, or composition of these. Rules outside the declared rule set are not admissible. The mapping carries the governance signatures of both the source-domain authority and the target-domain authority, attesting that each side accepts the connection.
When a field is ported, the mapping is applied deterministically and the resulting target-domain field is checked for admissibility under the target-domain policy before any consumer uses it. The application of the mapping is itself a lineage event recorded in both domains. The original field is not discarded; it remains available in the source-domain lineage, so a target-domain consumer that needs to verify the provenance of the ported field can traverse back through the mapping to the source instance.
Audit is required at every ported boundary. The mapping artifact, the source field at the time of port, the target field after application, and the admissibility outcome are all recorded with timestamps and signatures. An auditor reviewing the target-domain agent's behavior can reconstruct the full chain of cross-domain transfers without consulting the source-domain operator.
Operating Parameters
The operative parameters for field portability are: the rule set of admissible transformations, declared in the cross-domain policy registry; the dual signature requirement, declaring that both source and target governance authorities must endorse a mapping before it is usable; the mapping lifetime, declaring how long a signed mapping remains valid before requiring renewal; the audit retention, declaring how long the mapping artifact and the pre- and post-port field states must remain available; and the failure handling parameters, declaring what occurs when an applied mapping produces a target field that fails the target-domain admissibility check.
The mapping lifetime parameter prevents stale mappings from being used after the underlying domain policies have evolved. A mapping signed against one version of the target-domain policy is automatically invalidated when that policy version expires, requiring a fresh signature. This prevents a once-valid cross-domain transfer from drifting into invalidity unnoticed.
Failure handling is structural rather than discretionary. When a ported field fails target-domain admissibility, the target-domain agent does not consume the field; the failure is recorded as a non-execution with the mapping artifact attached as evidence. The source-domain authority is notified through the bound notification path declared in the mapping. The agent in the target domain remains in its prior admissible state, having neither gained nor lost integrity from the failed import.
Alternative Embodiments
In a paired embodiment, two domains have a single bilateral mapping registry maintained jointly. In a hub embodiment, a central governance hub maintains mappings between many domains, with each pairwise mapping individually signed by both endpoint authorities; the hub itself does not produce mappings, only registers them. In a chain embodiment, a field is ported across multiple domains in sequence, with each transfer carrying its own mapping; the target-domain consumer can elect to verify only the immediate prior mapping or to traverse the entire chain.
Embodiments may differ in the granularity of mapped sub-fields. A coarse mapping connects entire fields with a single transformation rule. A fine mapping connects individual sub-fields with distinct rules, allowing partial portability in which some sub-fields cross a domain boundary while others are reset to target-domain defaults. Both are within scope provided the rule set is declared and the mapping is dual-signed.
A further embodiment supports asymmetric mappings, in which the rule for porting from domain A to domain B differs from the rule for porting from domain B to domain A. This is useful where regulatory regimes impose different evidentiary requirements in each direction. The asymmetric pair is registered as two independent mappings, each with its own dual signature and lifetime.
Composition with Other Primitives
Field portability composes with collapse detection, discovery integrity, and confidence governance. A ported field that fails target-domain admissibility records a non-execution event that contributes to the violation count consumed by collapse detection. A discovery result whose anchor was authored in a different domain carries the porting mapping as part of its anchor lineage; the consumer's anchor check then includes verification of the mapping signatures and lifetime. Confidence governance reduces emitted confidence when downstream of a recently ported field, with the reduction parameterized by the mapping's transformation type.
Composition is contractual. Each downstream primitive declares how it observes ported fields and how it weights ported lineage in its own evaluations. The portability mechanism does not call into these primitives; it produces signed artifacts, and the primitives consult the artifacts on their own schedule.
Implementation Considerations
A reference implementation stores mappings in a content-addressed registry keyed by the cryptographic hash of the mapping artifact. Both endpoint authorities sign the hash, and the resulting signature pair is stored alongside the artifact. A consumer of a ported field retrieves the mapping by hash, verifies both signatures against the authorities' published keys, checks the mapping lifetime against the consumer's clock, and then re-applies the declared rules to the source field to confirm that the received target field matches the deterministic output of the rule application. Any divergence between the recomputed and the received target field indicates tampering or implementation drift and is treated as a failed import.
Domain-specific content for the integrity field is supplied through a domain registry that pairs each canonical sub-field with a domain interpretation. In a medical embodiment, the bounds on a forecast-coherence sub-field encode declared thresholds derived from clinical guideline documents and signed by the relevant clinical governance authority. In a financial embodiment, the same sub-field's bounds derive from advisor licensure rules and are signed by the financial regulator. In a defense embodiment, the bounds derive from operational doctrine and are signed by the cognizant command authority. The structural mechanism is identical across these embodiments; only the registry contents differ.
Performance for high-frequency cross-domain traffic is addressed through cached signature verification and precomputed transformation tables. A signing authority publishes a current key set with a known refresh cadence; consumers cache verifications for the cadence interval and refresh on expiry. Transformation rule evaluation is deterministic and side-effect-free, so rule outputs for stable input ranges can be precomputed and looked up at port time, reducing per-port latency to a hash lookup plus an admissibility check.
Auditor workflows are first-class consumers of the portability mechanism. An auditor presents a target-domain field instance, retrieves the mapping artifact by hash from the consumer's lineage, retrieves the source-domain field instance through the mapping's source pointer, and reconstructs the deterministic application step by step. Because every step is signed, deterministic, and lifetime-bounded, the auditor's reconstruction is independent of either domain operator's runtime cooperation, satisfying the structural requirement that audit not depend on the audited party.
Prior-Art Distinction
Existing approaches to cross-domain state transfer rely on schema translation, federated trust frameworks, or domain-specific adapter layers. Schema translation maps data fields between formats but carries no governance signatures and no admissibility check on the target side. Federated trust frameworks establish trust between organizations but do not declare the specific transformation rules under which a state element may be ported. Adapter layers convert representations but treat the conversion as an internal implementation detail rather than as a signed, audited artifact.
The disclosed mechanism is distinguished by four structural properties: cross-domain transfer is gated by a declared rule set rather than by ad hoc adapters; mappings carry dual signatures from source and target governance authorities; mappings have declared lifetimes and renewal requirements; and every transfer produces an audit artifact independently checkable in either domain. These properties make cross-domain portability a governed, audited activity rather than a representational convenience.
Failure Modes and Defenses
A primary failure mode is the use of an expired mapping. The lifetime parameter and the consumer-side lifetime check defend against this directly: an expired mapping fails verification and produces a recorded non-execution rather than a silent stale import. A second failure mode is a unilateral attempt to port without a target-domain signature, attempting to rely on the source-domain signature alone. Dual-signature verification rejects such attempts; the consumer's check requires the target-domain signature to match an authority recognized in the consumer's policy reference, and a single signature cannot satisfy that requirement.
A third failure mode is rule substitution, in which a mapping artifact is altered to specify a transformation outside the declared rule set. The hash-based registry defends against this: any alteration of the artifact changes its hash, invalidating both signatures. A fourth failure mode is replay, in which a once-valid mapping is reused after the source field has materially changed. Replay is detected by comparing the source field reference in the mapping against the current source field state; any divergence triggers re-signing or non-execution.
A fifth failure mode is governance authority compromise, in which an attacker obtains a signing key. This is mitigated structurally rather than cryptographically: a compromised authority's signed mappings remain visible in the audit ledger, and the dual-signature requirement means a compromise on one side does not unilaterally produce admissible imports on the other. Recovery from compromise involves authority key rotation and lifetime expiry of all mappings signed under the compromised key, both of which are first-class operations in the registry.
Disclosure Scope
The disclosure encompasses any system in which integrity coherence fields are transferred across declared application domains under signed, lifetime-bounded mappings, in which both source and target governance authorities endorse each mapping, and in which every transfer produces an audit artifact retained independently in both domains. The disclosure is not limited to medical, financial, or defense domains; these are illustrative.
Variants that alter only the storage location of audit artifacts or the serialization of mapping documents remain within scope. Variants that omit dual signing, that allow runtime selection of transformation rules outside the declared set, or that treat ported fields as admissible without target-domain checking fall outside the disclosed mechanism.