Secure and Privacy-Aware Networked Architectures for Monitoring Dual-Use Items and Technologies: A Scoping Review

Abstract

Monitoring dual-use items and technologies across distributed infrastructures requires sustained evidentiary continuity. Physical and digital entities, identities, measured states, provenance records, lifecycle events, and verification decisions must remain linked after an item, transfer, or technology is first classified. In this scoping review, we examine how existing mechanisms preserve evidentiary continuity across heterogeneous technical systems and institutional monitoring environments. The analysis draws on 90 substantive sources, combining peer-reviewed research with technical standards and the regulatory and operational documentation relevant to dual-use monitoring. The source-level findings distinguish mechanisms that establish an entity’s identity and attest its measured state from those that preserve provenance and enable subsequent events to be traced. Transparency and disclosure controls affect the conditions under which this evidence can be examined by institutional verifiers, while the assurance provided by each mechanism remains limited to its specific scope. Comparative analysis identifies potential loss-of-assurance scenarios where evidence crosses functional and institutional boundaries, including substitution, stale appraisal inputs, unrecorded events, equivocation, and excessive disclosure. We therefore propose an original seven-layer lifecycle-control reference architecture organized by distinct assurance questions, evidence objects, and trust boundaries. A source-to-function crosswalk and an interface failure-mode matrix trace this synthesis to the reviewed corpus while distinguishing documented mechanism properties from cross-source inferences and architectural design decisions.

1. Introduction

Dual-use monitoring confronts an evidence-continuity problem that outlives the instant at which an item, technology, or transfer is first classified. A physical component, software artifact, data stream, or cyber–physical subsystem can change custody, configuration, location, ownership, software state, or authorization before subsequent verification. These changes affect the interpretation of previously recorded evidence, since subsequent verification must establish whether that evidence still corresponds to the monitored entity and to the state or transfer under assessment. Networked monitoring infrastructure must preserve defensible relationships among the monitored entity, its digital representation, lifecycle events, and verification evidence. These relationships must remain intelligible across institutional and jurisdictional boundaries that rarely coincide with the object’s history. Confidence in that object must therefore survive both its own transformations and the turnover among the organizations charged with interpreting the evidence it leaves behind.

Existing approaches address different aspects of lifecycle assurance, depending on the nature of the monitored entity and the evidence required at each stage. At the device boundary, physical unclonable functions (PUFs) establish a cryptographic relation to a physical instance, providing a basis for persistent identification without describing the subsequent history of that instance [1]. Tracking that history requires a different kind of evidence. Electronic Product Code Information Services (EPCIS) assumes an identified object and asks how its history can be represented as events [2]. Product-identification standards make that naming portable across organizations [3], but portability of the identifier does not itself establish which changes have occurred. The physical binding supported by PUFs [1] and the event representation defined by EPCIS [2] consequently address different aspects of evidentiary continuity, even when both concern the same monitored entity. The evidentiary requirements change further according to the nature of the monitored entity and its operational context. Software and digital-content mechanisms shift the evidentiary focus from the physical instance to composition and provenance, while remote identification (Remote ID) narrows it to operational identification during flight [4]. A further distinction arises when the objective extends beyond identification or event traceability to institutional verification. International Atomic Energy Agency (IAEA) safeguards illustrate this different endpoint: verification emerges from the relationship among declarations, measurement, and inspection rather than from any single identifier or record [5]. The architectural consequence is that identity, provenance, state, and verification cannot be treated as interchangeable forms of trust, because each answers a different question about the monitored entity.

The newer standards make this fragmentation explicit by separating evidentiary roles instead of assuming that one component can perform them all. Remote ATtestation procedureS (RATS) distinguish the attester, verifier, and relying party so that evidence production, appraisal, and reliance are no longer collapsed into one trust decision [6]. Entity Attestation Token (EAT) then gives attestation claims a transferable structure [7], while Supply-Chain Integrity, Transparency, and Trust (SCITT) places registration and receipt semantics around signed statements. Selective-disclosure mechanisms add yet another concern by limiting what a verifier needs to learn from a credential [8]. The distinction between evidence appraisal in RATS [6] and claim representation in EAT [7] exposes dependencies that a monolithic design can obscure: freshness, credential status, reference values, policy provenance, issuer authority, revocation, and the distinction between statement registration and factual accuracy. A valid receipt or attestation result therefore carries only the assurance supplied by the evidence and governance context beneath it.

Implementation evidence translates these conceptual dependencies into deployment constraints. Hardware watermarking demonstrates feasible provenance functions, with costs distributed across area, memory, power, throughput, and latency [9]. A similar consideration arises with transform-oriented hardware architectures, which make the same trade-off visible at implementation level, where provenance-related processing must coexist with the resource budget of the host design [10]. Beyond these technical considerations, the institutional setting introduces a different constraint: evidence has operational value only when licensing, verification, investigation, or enforcement processes can interpret it and act on it [11]. In this context, European Union controls define export and transfer scope [12]. In the United States, the Export Administration Regulations establish the corresponding classification and licensing framework for controlled items and technologies [13]. The resource constraints documented for hardware watermarking [9] and transform-oriented implementations [10] must therefore be considered alongside institutional usability when assessing whether a monitoring mechanism can support traceable decisions.

Cross-domain evidence further shows that the threat model changes the meaning of assurance itself. For instance, research on PUFs demonstrates that device binding remains conditional on enrollment, helper data, environmental variation, and attack assumptions [14]. From a different perspective, privacy-enhancing cryptography narrows what must be disclosed during verification [15], yet that reduction in exposure does not by itself address the integrity of the platform producing the evidence. This limitation is illustrated by platform-level attacks such as Foreshadow, which show how compromise can reach beneath apparently valid hardware-rooted assurance flows [16]. The conditions governing PUF-based identification [14] and the disclosure limits addressed by privacy-enhancing cryptography [15] thus expose a recurring tension between the evidence required for verification and the confidentiality, correlation, or trust risks arising from its disclosure.

Integrity, completeness, and truth form a second fault line because secure logging can make later modification detectable without establishing that the original input was complete or correct [17]. The operational consequences of this distinction are illustrated by field investigations of unmanned aerial vehicle (UAV) supply chains [18]. Reconstructing diversion depends on the quality and continuity of the underlying evidence, including records that may be missing. Another dimension of the problem concerns consistency across records. Transparency mechanisms address a different weakness in the evidence chain by making inconsistency or equivocation observable across recorded views [19]. At the level of disclosure, privacy-preserving attestation shifts the accountability question to disclosure, asking how a claim can be established without exposing more evidence than the decision requires [20]. The integrity guarantees of secure logging [17] and the consistency checks of transparency mechanisms [19] answer different evidentiary questions. The disclosure constraints of privacy-preserving attestation [20] further determine what a verifier may inspect. Accountability consequently depends on whether a decision can be reconstructed from evidence whose origin, authority, lifetime, and limitations remain intelligible.

Process and data-model standards help connect heterogeneous evidence, while revealing the limits of abstraction. Within this context, the World Wide Web Consortium (W3C) provenance (PROV) framework supplies a common vocabulary for relationships among entities, activities, and agents [21]. This approach also extends to software supply chains, where in-toto carries comparable provenance logic into verifiable sequences of authorized steps [22]. Supply-Chain Levels for Software Artifacts (SLSAs) and related composition formats extend this vocabulary toward build and component histories, while manufacturing and end-use frameworks describe production, custody, and end-use transitions for physical systems. Despite these commonalities, the unresolved difficulty appears at the transitions between these representations: a physical entity must remain bound to a digital identity, evidence must retain meaning when it enters a registry, and a registry state must still be interpretable when policy turns it into a decision. The mechanisms create distinct verification obligations at these transitions, where undetected item substitution, event omission, semantic mismatch, disclosure-related linkability, or incomplete institutional review may affect a downstream decision. These are boundary-specific analytical scenarios derived from the source-defined mechanisms.

This review adopts a scoping-review design because the evidence spans heterogeneous technical mechanisms and institutional instruments that require systematic mapping before cross-domain comparison. Within this scope, artificial intelligence (AI) model artifacts are considered only where a specific monitoring or dual-use-control obligation applies; the use of AI alone does not establish controlled status. Mechanisms are examined by assurance function, evidence object, trust relationship, deployment constraint, and failure mode. The resulting patterns are then integrated through qualitative architectural synthesis. The Results present mechanism properties (Table 1), claim-level evidence calibration (Table 2), interface checks (Table 3), cross-domain relevance (Table 4), application evidence objects (Table 5), field-case mapping (Table 6), custody-decision outcomes (Table 7), and staged verification predicates (Table 8). The technical contribution comprises a source-to-function mapping for seven logical assurance functions, six interface-specific verification questions (Table 3), and a comparison with four- and five-layer groupings (Section 3.4). Section 3.5 maps evidence available from a documented field investigation and tests selected verification predicates on specified custody records, showing which additional inputs change a policy decision. Four research questions guide the analysis: how identity is bound to a monitored entity (RQ1), how provenance and lifecycle events are preserved (RQ2), how security and privacy are reconciled with verification (RQ3), and which constraints and failure modes recur across domains (RQ4).

AI-specific evidence is treated as a technical lifecycle problem: a model can be distributed as weights or serialized code, transformed through fine-tuning, and used for subsequent inference. Its identifier, training-data references, execution environment, signed publication record, and any transfer decision represent different evidence objects. Studies of model-hub security, ML provenance, attested properties, and model supply-chain integrity document these mechanisms across the AI lifecycle [23,24,25,26].

2. Materials and Methods

2.1. Review Design, Scope, and Corpus

This study followed a scoping-review design informed by the Joanna Briggs Institute (JBI) methodology to map heterogeneous technical and institutional evidence toward a qualitative architectural synthesis. JBI guidance informed eligibility, charting, source assessment, and synthesis [27]. Reporting was structured with reference to the Preferred Reporting Items for Systematic Reviews and Meta-Analyses extension for Scoping Reviews (PRISMA-ScR) [28]; a completed item-by-item reporting checklist is supplied as Supplementary Materials. Eligibility decisions and data-charting procedures are documented in Section 2.1 and Section 2.2; no prospective protocol registration is reported for this review.

Four research questions guided the analysis: how identity is bound to a monitored entity (RQ1); how provenance and lifecycle events are preserved (RQ2); how security and privacy are reconciled with verification (RQ3); and which constraints and failure modes recur across domains (RQ4). Eligible sources described an identifiable mechanism, evidence object, interface, attack class, deployment constraint, or verification workflow connected to lifecycle monitoring. English-language sources available through October 2026 were considered, including papers identified through the August database searches and an October AI-focused proceedings search, with no lower publication-year bound. Provisional specifications were included only for maturity or research-gap analysis. Purely classificatory legal analysis, generic cybersecurity or ledger proposals without an entity-to-evidence verification path, and descriptive material without inspectable evidence architecture were excluded.

The technical corpus comprised 90 substantive sources: 28 peer-reviewed studies; 22 technical standards or specifications; 10 legal or regulatory instruments; and 30 institutional, operational, or vendor technical sources. Two methodology and reporting works were treated separately, bringing the bibliography to 92 entries. Supplementary Table S1 records corpus selection and composition; Table S2 reports quantitative implementation evidence and deployment constraints; Table S3 provides the source-level classification; and Table S4 specifies the data-charting fields.

2.2. Search, Coding, Source Assessment, and Synthesis

Evidence came from peer-reviewed studies, standards, legal instruments, and institutional or platform documentation. The August 2026 search combined broad domain mapping (70 candidates), mechanism-focused discovery (30), and a supplementary stage (20) with backward and forward citation tracing. The August searches yielded 120 candidate records and 86 eligible sources; a targeted October 2026 proceedings search identified four eligible AI supply-chain papers [23,24,25,26], giving a combined total of 124 assessed records and 90 substantive inclusions. Supplementary Tables S5 and S6 report thematic search families and the retained PubMed and Institute of Electrical and Electronics Engineers (IEEE) Xplore query syntax. Association for Computing Machinery (ACM), USENIX, Springer Nature, Elsevier, and MDPI publications were examined through manual proceedings and publication discovery; counts were not attributed to reproducible database queries for these routes. The PubMed and IEEE Xplore searches were conducted during 1–31 August 2026, including research sessions on 5, 12, 19, and 26 August. The AI-focused proceedings search targeted model-hub code poisoning, attested training and inference properties, cryptographic model lineage, and publisher signatures; publisher proceedings and full papers were checked against the established eligibility and evidence-object fields (Supplementary Tables S3–S5 and S7).

Each substantive source was charted against a common field set covering entity and binding, evidence and freshness, credential lifecycle, provenance and events, trust boundaries, privacy and authorization, audit workflow, interoperability, retention, and implementation constraints. Source-type assessment constrained admissible claims: peer-reviewed studies supported empirical properties and attacks; standards supported normative interfaces and semantics; legal texts supported obligations and jurisdiction; institutional sources supported documented procedures; and vendor documentation supported platform-specific evidence and collateral.

Evidence strength was assessed for each explicitly scoped proposition by its directness of support, authoritative or empirical status, independence of underlying evidential lines, and match to the relevant context. Strong applies to explicitly defined role, interface, format, or data-model semantics within an authoritative document’s stated scope; to legal obligations within their remit; or to consistent empirical propositions corroborated by independent primary evidential lines under comparable conditions. Moderate applies to a directly relevant empirical demonstration or documented operational case whose inference is bounded by the reported platform, setting, or threat model. Limited applies to indirect, provisional, or extrapolated claims for which direct corroboration or end-to-end validation is lacking. A standard can therefore provide strong support for the meaning of its own specified interface while providing no direct evidence of an implementation’s field performance; provisional specifications are interpreted according to their publication status. Sources resting on the same primary document, experiment, incident record, or dataset count as one evidential line for the relevant claim. Supplementary Table S8 states the decision rules, with representative claim-level applications and their inference boundaries.

Source selection, charting, and analytical coding underwent cross-author, source-based checks by E.M., D.-F.C., and M.G. During source assessment, all three contributed to initial assessments and examined colleagues’ judgments. A co-author checked a recorded decision against the original source and agreed criteria. For eligibility, this covered architectural relevance, evidentiary specificity, authority, version precedence, and the inclusion or exclusion rationale (Supplementary Table S7). Disagreements were resolved by re-reading the source. The reconciled inventory contains 90 substantive records (Table S3).

For charting, co-authors checked recorded source attributes against the full text using the common fields in Supplementary Table S4. They also checked assurance functions, claim grades, proposed layers, and interface failure modes against the cited material, resolving differences through discussion. Reference-identifier reconciliation confirmed 90 distinct substantive sources in Table S3, separate from methodological references [27,28], and verified that citations in Table S8 and the subsequent architecture mappings refer to included sources. The inventory, criteria and mappings document the reconciled judgments; separate first-pass screening decisions for every record were not archived (Section 4.2).

The architecture was derived in three analytically distinct steps. First, sources were coded by the evidence object, assurance function, authority or trust assumption, temporal scope, and reported limitation. Second, recurring functions and the transitions between them were compared across mechanism families and monitoring domains. Third, the authors organized the recurring assurance questions into seven logical layers and specified interface controls to address identified dependencies. The first step records source-supported properties, the second yields comparative inferences, and the third constitutes the proposed design. The mapping in Supplementary Tables S9 and S10 makes these transitions traceable. Figure 1 summarizes the source-selection flow and final corpus.

Figure 1. PRISMA-ScR source selection flows from 124 assessed records (120 August candidates plus four October AI-mechanism papers) to 90 substantive sources; two methodology and reporting works are listed separately in the bibliography.

3. Results

3.1. Cross-Layer Requirements, Identity, and Attestation

Regarding RQ1, the comparison identifies three separately verifiable claims in a decision concerning a changing item. The first concerns whether an observation refers to the enrolled entity. The second concerns whether a signed measurement describes an accepted state of that entity at appraisal time. The third concerns whether the contemplated action is permitted for the recipient and purpose. Item identification and physical binding provide evidence for the first claim [1,3,29]. RATS and EAT specify roles and evidence representation for state appraisal, with the applicable reference values, freshness, and endorsement context [6,7]; Trusted Platform Module (TPM) mechanisms supply platform measurements under their own trust assumptions [30]. The relying party applies a separate decision policy [6,31]. These are source-supported distinctions. Their comparative implication is a requirement to carry the entity, measurement, policy, and authority references into each downstream decision rather than equating a valid identifier or signature with an authorized transfer (Table 1 and Table 3; Supplementary Table S9).

The predicates can be separated by varying the evidence. Replacement or relabeling can break the association between a module and its enrollment record [1,14]. A valid identity credential may coexist with stale state evidence requiring independent appraisal [6,7]. Custody events can be omitted before registration; a receipt attests only to the submitted statement [2,32]. A valid receipt can also coexist with a recipient conflict requiring a relying-party decision [6,31]. These are boundary tests derived from distinct mechanisms, without any estimate of attack prevalence. The field investigation [18] documents an end-use discrepancy but does not establish which digital-control failure, if any, occurred.

The reviewed mechanisms therefore support different acceptance predicates. PUF-based binding and identifiers address entity association under enrollment assumptions [1,14,29]; Remote ID supplies operational identification without a software-state measurement [4]. Trusted Platform Module (TPM) measurements and Verifiable Remote Attestation for Simple Embedded Devices (VRASED) address platform state [30,33], while Control-Flow Attestation (C-FLAT) addresses bounded execution integrity [34]. RATS and EAT specify roles and claim representations [6,7]. In the controlled-module example, K1–K3 pass in V0, V1, and V2; only the later custody and recipient checks distinguish the variants (Table 7 and Table 8; Supplementary Tables S11 and S12). This is a logical comparison of stipulated inputs; Table 2 records the applicable evidence boundaries.

Credential validity must also be evaluated at the time of the decision. Root and endorsement credentials, attestation keys, item credentials, workload credentials, and operator credentials establish different authorities or relationships [6,30,35,36]. Their expiry, rotation, revocation, and delegation status affect a relying party only through the status and trust context available for appraisal. The proposed decision record therefore preserves the credential identifier and status snapshot, appraisal profile, reference-value version, policy identifier, and time context used for the decision. Such an archive makes a later review capable of distinguishing a signature that was valid at signing time from a transfer authorized under the policy and authority in force at verification time. Its completeness and operational performance have not been tested as an integrated system.

3.2. Provenance, Registry Integrity, and Privacy-Aware Exchange

Regarding RQ2, the comparison identifies two checks for custody transitions. First, does an expected event identify the correct item, operation, sender, and recipient? EPCIS, PROV, and chain-of-custody models provide event and relationship semantics [2,21,37]. Second, does a registration receipt cover the signed statement for that event? SCITT specifies statement receipts [32], while Certificate Transparency specifies log inclusion and consistency properties [19]. Artefact markings, watermarks, and content-provenance assertions provide other evidence [38,39], without guaranteeing complete custody history. Verification must therefore distinguish the observed item, the asserted transition, and the registered statement. Requiring matching item and event references across them is the authors’ proposed control.

The examples distinguish these evidence objects. In V1, transfer T9 is absent, although a valid receipt covers firmware event F4; K4 and K5 fail because F4 cannot satisfy the transfer requirement. In V2, a valid receipt covers T9, but its recipient B conflicts with the independent manifest naming C; K6 fails. Both yield HOLD under policy P3 (Table 7 and Table 8; Supplementary Tables S11 and S12). EPCIS and SCITT define event and registration semantics [2,32]; completeness checks, corroboration, and HOLD are proposed controls. The Conflict Armament Research (CAR) investigation supplies physical and commercial tracing evidence, without demonstrating deployment of these digital mechanisms [18].

Regarding RQ3, this review distinguishes attribute disclosure, requesting-party authority, and information retained for audit. Selective disclosure limits presented credential data [8], attribute-based access control specifies policy-based authorization [31], and institutional controls govern exceptional investigation and sensitive records [40]. In the synthetic custody example, K6 compares the transfer recipient, an independent manifest, and the authorization rule. A future privacy-aware system could restrict access to the manifest while retaining the event identifier, comparison outcome, policy version, and audit reference. This handling pattern is proposed by the authors: the replay implements neither selective disclosure nor re-identification testing.

Retention affects later auditability. Primary evidence may expose commercial documents, locations, or telemetry, but an audit must retain the event, receipt, manifest comparison, credential status, and policy version underlying the disposition. SCITT receipts can verify statement registration even when payload access is restricted [32]; they cannot recover unsubmitted events or establish recipient authority. Differentiated retention, auditable exceptional access, and metadata-linkability checks remain proposed design requirements [8,31,40], without operational validation.

3.3. Failure Modes and Deployment Constraints

Regarding RQ4, each hand-off asks whether evidence accepted by one function establishes the claim required by the next. Table 1 and Table 3 and Supplementary Table S10 distinguish source-supported properties, downstream checks, and possible decision consequences; they do not estimate attack frequency. At L1–L2, item identifiers and physical mechanisms support association [1,3,14,29], but substitution or relabeling requires renewed observation and binding. At L2–L3, identity alone cannot establish current software state. RATS specify evidence appraisal against reference values, endorsements, and an appraisal policy [6]; the proposed hand-off check requires identity binding, freshness, and state appraisal [6,7,30].

At L3–L4, measured state must be associated with the relevant event represented by EPCIS or PROV [2,6,21]. At L4–L5, SCITT registration receipts and Certificate Transparency proofs establish properties of submitted statements [19,32], requiring an event-specific match and independent evidence for any omitted event. At L5–L6, valid registration must be compared with policy, recipient, and authority [6,31,32]. At L6–L7, audit needs the retained policy, evidence, credential-status context, and disposition [5,18,37,41]. Table 3 defines these hand-off questions, and Table S10 identifies source properties and proposed controls. Privacy and credential-status requirements arise from separate disclosure and authority conditions [6,8,31,36].

Section 3.5 applies the event-registration and recipient checks to V1/V2 and maps a distinct field investigation to the seven functions [18]. The applications localize evidentiary gaps under specified conditions; they yield no incident-rate or field detection-performance estimates (Table 6, Table 7 and Table 8; Supplementary Tables S11 and S12).

Temporal context differs across evidence types. RATS freshness relates attestation to a challenge-response context [6]; signed logs protect recorded sequence and replay resistance [42]. Device, event, receipt, and verification times can diverge in intermittently connected systems. Monotonic counters, boot epochs, checkpoints, and bounded queues help preserve order and expose gaps after reconnection. Without independent timing evidence, delayed reporting and deliberate omission may remain indistinguishable. These constraints limit the inference supported by any single timestamp.

Quantitative results cover incomparable deployment regimes. Hardware watermarking reports area, memory, cycles, power, and timing costs [9]; runtime attestation adds workload-dependent execution and evidence overhead [33]. Transparency services shift costs toward storage, proofs, collateral, and reconciliation [19]. Platform, workload, and threat-model differences prevent a meaningful common performance ranking. Supplementary Table S2 distinguishes source-reported measurements, authors’ calculations, and proposed deployment scenarios.

Table 1. Source-supported mechanism properties, boundary risks, and proposed verification checks.

Function and References	Source-Supported Evidence	Potential Boundary Mismatch	Proposed Verification Check
Entity/observation [1,3,29]	Item mark, observed properties, and identifier	Observed item differs from its enrolled record	Compare physical observation, identifier, and change history
Identity/trust [14,30,35]	Bound credential, PUF, or protected identity root	Credential remains valid after a relevant entity or owner change	Verify target binding, status, and re-enrollment/rotation
Attestation [6,7,30,33]	Signed state evidence; freshness, references, and endorsements	Valid identity used with stale or unsupported measured state	Check nonce, binding, appraisal inputs, and accepted profile
Provenance/events [2,21,22,37]	Event semantics, signed history, or artifact provenance	Required change or transfer has no correlated event	Match event, entity, producer, and expected transition
Registry/transparency [19,32]	Signed-statement receipt; inclusion/consistency proof	Receipt covers another statement; unsubmitted event absent	Verify exact event/statement and reconcile expected records
Policy/verification [6,8,31]	Appraisal result, access rule, purpose, and recipient	Valid technical evidence used outside authorized context	Check policy version, authorization, recipient, and status
Governance/audit [5,18,37,41]	Custody documents, decisions and investigation records	Decision cannot be reconstructed or discrepancy escalated	Retain decision bundle; reconcile independent evidence

Source: Authors’ synthesis of the cited mechanisms. References in each row identify the evidence basis; the boundary-risk and verification-check columns specify the authors’ comparative analysis. Table 3 and Supplementary Table S10 document the inter-layer reasoning. Implementation context and quantitative constraints appear in Table S2. Abbreviations: PUF, physical unclonable function; SBOM, Software Bill of Materials; TCB, Trusted Computing Base.

Table 1. Source-supported mechanism properties, boundary risks, and proposed verification checks.

Function and References	Source-Supported Evidence	Potential Boundary Mismatch	Proposed Verification Check
Entity/observation [1,3,29]	Item mark, observed properties, and identifier	Observed item differs from its enrolled record	Compare physical observation, identifier, and change history
Identity/trust [14,30,35]	Bound credential, PUF, or protected identity root	Credential remains valid after a relevant entity or owner change	Verify target binding, status, and re-enrollment/rotation
Attestation [6,7,30,33]	Signed state evidence; freshness, references, and endorsements	Valid identity used with stale or unsupported measured state	Check nonce, binding, appraisal inputs, and accepted profile
Provenance/events [2,21,22,37]	Event semantics, signed history, or artifact provenance	Required change or transfer has no correlated event	Match event, entity, producer, and expected transition
Registry/transparency [19,32]	Signed-statement receipt; inclusion/consistency proof	Receipt covers another statement; unsubmitted event absent	Verify exact event/statement and reconcile expected records
Policy/verification [6,8,31]	Appraisal result, access rule, purpose, and recipient	Valid technical evidence used outside authorized context	Check policy version, authorization, recipient, and status
Governance/audit [5,18,37,41]	Custody documents, decisions and investigation records	Decision cannot be reconstructed or discrepancy escalated	Retain decision bundle; reconcile independent evidence

Source: Authors’ synthesis of the cited mechanisms. References in each row identify the evidence basis; the boundary-risk and verification-check columns specify the authors’ comparative analysis. Table 3 and Supplementary Table S10 document the inter-layer reasoning. Implementation context and quantitative constraints appear in Table S2. Abbreviations: PUF, physical unclonable function; SBOM, Software Bill of Materials; TCB, Trusted Computing Base.

Table 2. Claim-level evidence calibration for ten representative propositions from Section 3.1, Section 3.2, Section 3.3 and Section 3.4.

RQ	Focal Proposition/Evidence	Grade	Claim Boundary
RQ1	RATS define attester, verifier, and relying-party roles [6]	Strong	Specified role semantics; no operational effectiveness inferred
RQ1	EAT defines a structured claim carrier [7]	Strong	Published format within specified profiles
RQ2	EPCIS defines event representation [2]	Strong	Event vocabulary, not completeness of recorded histories
RQ2	SCITT defines signed-statement receipt semantics [32]	Strong	Receipt relates to submitted statements only
RQ1/RQ4	VRASED attestation properties [33]	Moderate	Specific implementation and threat assumptions
RQ4	C-FLAT implementation effects [34]	Moderate	Reported case-study workloads and platform conditions
RQ2/RQ4	Field reconstruction of component supply chains [18,41]	Moderate	Documented cases, not a population rate
RQ3	End-to-end purpose-bound disclosure workflow [8,31,40]	Limited	Author-proposed combination of distinct controls
RQ4	Cross-layer omission and stale-evidence scenarios [1,2,6,32]	Limited	Comparative failure hypotheses
RQ1–RQ4	Complete seven-layer composition and mitigation effectiveness	Limited	Conceptual reference design; no integrated validation

Table 2. Claim-level evidence calibration for ten representative propositions from Section 3.1, Section 3.2, Section 3.3 and Section 3.4.

RQ	Focal Proposition/Evidence	Grade	Claim Boundary
RQ1	RATS define attester, verifier, and relying-party roles [6]	Strong	Specified role semantics; no operational effectiveness inferred
RQ1	EAT defines a structured claim carrier [7]	Strong	Published format within specified profiles
RQ2	EPCIS defines event representation [2]	Strong	Event vocabulary, not completeness of recorded histories
RQ2	SCITT defines signed-statement receipt semantics [32]	Strong	Receipt relates to submitted statements only
RQ1/RQ4	VRASED attestation properties [33]	Moderate	Specific implementation and threat assumptions
RQ4	C-FLAT implementation effects [34]	Moderate	Reported case-study workloads and platform conditions
RQ2/RQ4	Field reconstruction of component supply chains [18,41]	Moderate	Documented cases, not a population rate
RQ3	End-to-end purpose-bound disclosure workflow [8,31,40]	Limited	Author-proposed combination of distinct controls
RQ4	Cross-layer omission and stale-evidence scenarios [1,2,6,32]	Limited	Comparative failure hypotheses
RQ1–RQ4	Complete seven-layer composition and mitigation effectiveness	Limited	Conceptual reference design; no integrated validation

Of the ten representative propositions, four are graded strong for authoritative definitions of roles, formats, events, and receipts; three are moderate for bounded empirical or case evidence; and three are limited for proposed cross-mechanism inferences. The ratings apply to the specific propositions and inference boundaries recorded in Table 2.

3.4. Seven-Layer Lifecycle-Control Architecture

The synthesis yields a seven-layer lifecycle-control reference architecture: (L1) monitored entity and observation; (L2) identity and trust anchors; (L3) attestation and evidence normalization; (L4) provenance and lifecycle events; (L5) registry and transparency; (L6) policy, verification, and risk decision; and (L7) governance, audit, and institutional feedback. We defined a separate logical layer where the corpus revealed a distinguishable assurance question, characteristic evidence object, responsible authority or trust assumption, and failure condition at the next hand-off. The layer count is an explicit analytical design choice, supported by the functions and boundaries listed in Supplementary Table S9. The seven-layer arrangement itself is an author-defined integration proposal classified as Limited for end-to-end effectiveness, although its component interfaces draw on Strong normative and Moderate platform-specific evidence (Table 2).

L1 establishes what entity or state was observed, whereas L2 determines how identity and trust are bound to it [1,3,29]. L3 appraises measured-state evidence with freshness, endorsements, and reference values [6,7,30]; L4 describes the event and provenance history relating multiple observations over time [2,21,22]. L5 supplies registration, receipt, and consistency evidence for submitted statements [19,32], while L6 applies authorization and appraisal policy to a particular use of evidence [6,8,31]. L7 connects the resulting decisions to institutional review, audit reconstruction, reconciliation, and corrective action [5,37,43]. Their separation is logical: one implementation may combine functions, provided their evidence semantics, authority, and decision context remain distinguishable.

We compared the seven separately accountable functions with nested five- and four-layer alternatives. The five-layer grouping is (L1 + L2), L3, (L4 + L5), L6, and L7: it merges observation with identity binding, and custody-event representation with registration. Those mergers risk hiding a substituted entity or a valid receipt for an unrelated event. The four-layer grouping, (L1 + L2), L3, (L4 + L5 + L6), and L7, additionally combines registration with authorization, potentially hiding a conflict between a registered recipient and independent custody evidence. V1 illustrates the absent T9 transfer despite a valid F4 receipt (K4/K5); V2 illustrates a registered T9 whose recipient fails K6 (Table 7 and Table 8; Supplementary Tables S11 and S12). These diagnostic distinctions persist in a four- or five-component implementation if the individual evidence objects, predicates, and decision records remain explicit. The seven-layer partition therefore provides an auditable logical decomposition, without implying a uniquely optimal number of deployed components (Supplementary Tables S9 and S10). Figure 2 shows the functions and feedback paths.

Figure 2. Proposed seven-layer lifecycle-control reference architecture. Each layer represents a distinct assurance question and evidence responsibility rather than a mandatory physical deployment component. The source-to-layer correspondence and separation rationale are listed in Supplementary Table S9. This figure is an original synthesis by the authors.

At L2–L3, normalization must retain evidence semantics. RATS distinguish attestation producers, verifiers, and relying parties [6], while EAT structures the exchanged claims [7]. TPM 2.0 measurements depend on evidence profiles, key binding, reference values, and Trusted Computing Base assumptions. A generic trusted/untrusted label can discard these conditions even when formats interoperate. The proposed normalization function therefore preserves origin, freshness, scope, status, and appraisal context so that downstream decisions remain reviewable.

At L4–L5, independent evidence channels can expose discrepancies. Artifact-bound markings may be stripped or copied [38], and custody events can be omitted before capture [2]. SCITT receipts establish registration of a submitted statement [32], while consistency proofs detect divergent registered views [19]. Neither proves that an entire physical history was recorded. Comparing artefact evidence, events, and receipts supports escalation when their claims conflict. This cross-channel comparison is the proposed control for dependence on a single representation.

At L6–L7, audit asks whether a decision can be reconstructed. RATS separate technical appraisal from a relying party’s action [6]; federation adds cross-domain trust anchors, policies, and revocation state [36]. Reconstruction requires the evaluated evidence, reference values, credential status, policy and time context, with transparency receipts preserving only part of that record [32]. Audit findings can then inform revocation, screening rules, configuration, and subsequent monitoring decisions.

Table 3. Verification checks derived from source-defined assurance properties and illustrative policy outcomes.

Boundary/Source Basis	Authors’ Hand-Off Check	Potential Mismatch/Replay Case	Proposed Action/Replay Outcome
L1–L2 [1,3,14,29]	Observed item matches enrolled identity and credential	Mismatch after substitution, relabeling, or replacement	Recheck/HOLD; unobserved change may persist
L2–L3 [6,7,30,33]	Evidence bound to target, fresh, and appraised with current references	Stale quote, invalid binding, or unsupported platform state	Reject appraisal; strength depends on platform assumptions
L3–L4 [2,6,21,22]	Appraised state linked to a dated update or transfer	Valid quote lacks accountable event context	Request event evidence; missing history remains possible
L4–L5 [2,19,32]	Receipt proves inclusion of the required signed event	Missing T9 with valid F4 receipt (V1)	HOLD at K4/K5; registration proves submitted input only
L5–L6 [6,31,32]	Verified receipt plus policy, status, and recipient checks	Valid T9 conflicts with independent manifest (V2)	HOLD at K6; receipt does not authorize recipient
L6–L7 [5,18,37,41]	Decision, policy version, and external records reconstructable	End-use discrepancy or missing rationale (CAR case)	Escalate/audit; legal classification requires separate evidence
Cross-cutting [6,8,31,36]	Recheck credential status, access purpose, and disclosure	Stale authority, linkability, or excess disclosure	Re-evaluate and log; privacy risk depends on usage

Table 3. Verification checks derived from source-defined assurance properties and illustrative policy outcomes.

Boundary/Source Basis	Authors’ Hand-Off Check	Potential Mismatch/Replay Case	Proposed Action/Replay Outcome
L1–L2 [1,3,14,29]	Observed item matches enrolled identity and credential	Mismatch after substitution, relabeling, or replacement	Recheck/HOLD; unobserved change may persist
L2–L3 [6,7,30,33]	Evidence bound to target, fresh, and appraised with current references	Stale quote, invalid binding, or unsupported platform state	Reject appraisal; strength depends on platform assumptions
L3–L4 [2,6,21,22]	Appraised state linked to a dated update or transfer	Valid quote lacks accountable event context	Request event evidence; missing history remains possible
L4–L5 [2,19,32]	Receipt proves inclusion of the required signed event	Missing T9 with valid F4 receipt (V1)	HOLD at K4/K5; registration proves submitted input only
L5–L6 [6,31,32]	Verified receipt plus policy, status, and recipient checks	Valid T9 conflicts with independent manifest (V2)	HOLD at K6; receipt does not authorize recipient
L6–L7 [5,18,37,41]	Decision, policy version, and external records reconstructable	End-use discrepancy or missing rationale (CAR case)	Escalate/audit; legal classification requires separate evidence
Cross-cutting [6,8,31,36]	Recheck credential status, access purpose, and disclosure	Stale authority, linkability, or excess disclosure	Re-evaluate and log; privacy risk depends on usage

The evidence boundaries remain explicit: primary sources establish mechanism properties, cross-source comparison identifies dependencies, and the seven-layer arrangement and interface checks are the authors’ synthesis. The corpus supports conceptual coverage and traceability, without end-to-end performance validation of an integrated system.

Cross-domain mapping shows that the seven assurance functions transfer more readily than the evidence used to instantiate them. Table 4 sets out the corresponding domain-by-layer relevance assessments.

Table 4. Cross-domain relevance of the seven assurance functions. Primary, supporting, and contextual ratings reflect the authors’ comparative assessment. Abbreviation: C2PA, Coalition for Content Provenance and Authenticity.

Application Domain	Primary	Supporting	Contextual	Representative Evidence
Physical components and conventional material [3,44,45]	L1, L2, L3, L4	L5, L6	L7	Serial/item identifiers; custody events; field inspection
Nuclear and chemical monitoring [5,46,47]	L3, L4, L5, L6, L7	L1, L2	—	Declarations; measurement; seals; surveillance; reconciliation
Software supply chains [21,22,37,48,49,50,51,52]	L2, L3, L4, L6, L7	L5	L1	SBOM; build attestation; provenance records; incident logs
Digital content and data streams [9,38,39,53,54,55,56,57]	L3, L4, L5, L7	L2, L6	L1	Watermarks; signatures; hashes; C2PA assertions
Drones and space systems [4,33,34,58,59,60,61,62,63]	L1, L2	L3, L4, L5, L6, L7	—	Remote ID; telemetry; orbital observations; catalogs
Cyber-surveillance technologies [64,65,66,67]	L6, L7	L2, L3, L4, L5	L1	Technical capabilities; end-user evidence; risk assessment
AI-model weights, checkpoints, and datasets [23,24,25,26,68]	L1, L3, L4, L5	L2, L6	L7	Model digests and signatures; ML-BOM and dataset identifiers; TEE evidence, signed pipeline manifests, and hub scanning

Table 4. Cross-domain relevance of the seven assurance functions. Primary, supporting, and contextual ratings reflect the authors’ comparative assessment. Abbreviation: C2PA, Coalition for Content Provenance and Authenticity.

Application Domain	Primary	Supporting	Contextual	Representative Evidence
Physical components and conventional material [3,44,45]	L1, L2, L3, L4	L5, L6	L7	Serial/item identifiers; custody events; field inspection
Nuclear and chemical monitoring [5,46,47]	L3, L4, L5, L6, L7	L1, L2	—	Declarations; measurement; seals; surveillance; reconciliation
Software supply chains [21,22,37,48,49,50,51,52]	L2, L3, L4, L6, L7	L5	L1	SBOM; build attestation; provenance records; incident logs
Digital content and data streams [9,38,39,53,54,55,56,57]	L3, L4, L5, L7	L2, L6	L1	Watermarks; signatures; hashes; C2PA assertions
Drones and space systems [4,33,34,58,59,60,61,62,63]	L1, L2	L3, L4, L5, L6, L7	—	Remote ID; telemetry; orbital observations; catalogs
Cyber-surveillance technologies [64,65,66,67]	L6, L7	L2, L3, L4, L5	L1	Technical capabilities; end-user evidence; risk assessment
AI-model weights, checkpoints, and datasets [23,24,25,26,68]	L1, L3, L4, L5	L2, L6	L7	Model digests and signatures; ML-BOM and dataset identifiers; TEE evidence, signed pipeline manifests, and hub scanning

Across domains, verification authority and evidence thresholds differ. Strategic-trade control emphasizes classification and accountable transfer [58]; nuclear and chemical monitoring emphasize declarations and reconciliation [69]. Manufacturing and conventional-arms tracing emphasize custody [47], while software provenance addresses builds, components, and updates [22,37]. For AI-model artifacts, model-hub screening, cryptographically linked checkpoint lineage, and attested training or inference properties provide directly inspectable mechanisms [23,24,25]; model signing and dataset-property claims address additional supply-chain questions [26]. NIST guidance [70,71] supplies complementary secure-development and misuse-risk context. Unmanned and space systems require timely distributed observation [72], and life-sciences governance emphasizes institutional control [62]. Table 4 grades the qualitative relevance of assurance functions across domains, without measuring failure incidence.

Published AI supply-chain evidence supplies concrete mechanism properties. Zhao et al. analyzed malicious code in model-hub artifacts using MalHug; the reported industrial deployment screened more than 705,000 models and 176,000 datasets and identified 91 malicious models and nine malicious dataset-loading scripts [23]. This establishes an observed model-distribution threat and a bounded scanner implementation; it does not establish complete protection against every model attack. Atlas collects model-checkpoint measurements, signed provenance manifests, trusted execution environment (TEE) evidence, and transparency records across ML pipelines. Its prototype reports training overhead below 8% and verification-latency reductions of up to 50% with caching in the evaluated conditions [24]. Laminator demonstrates hardware-assisted attestations for model-, dataset-, training-, and inference-related properties, including the binding between an input, an evaluated model, and an output [25]. An ICML position paper separately examines Sigstore-based model signing and dataset-property claims as supply-chain controls, without presenting an end-to-end deployment benchmark [26].

The comparison yields distinct interface requirements for an AI-model release. At L1–L2, the model checkpoint hash and declared publisher must refer to the same artifact; at L2–L3, TEE claims or model-property attestations require appraisal against their attested code, platform state, and time context [24,25]. At L3–L4, the verified checkpoint must be linked to a specific fine-tuning operation and identified training-data references, while L4–L5 requires an exact manifest or signed statement for the model version submitted to a transparency service [24,26,68]. At L5–L6, a verified model signature or provenance receipt cannot establish that a serialized package is free of malicious execution paths, that training datasets were complete or permissible, or that a recipient is authorized; independent scanning and applicable distribution rules remain separate inputs [23,26]. These are authors’ cross-source verification requirements, not properties experimentally demonstrated by the complete seven-layer composition.

3.5. Application of the Seven-Layer Architecture to Field Evidence, Decision Traces, and AI-Model Provenance

The proposed architecture was examined through three applications with different evidence bases, using the validation questions in Table 5. First, retrospective evidence mapping uses CAR documentation of European Global Navigation Satellite System (GNSS) anti-interference modules recovered from weaponized UAVs in Myanmar [18]. The exercise assesses which assurance claims the published field evidence supports. Second, a deterministic decision trace uses fully specified illustrative inputs for an industrial control module to test the consequences of complete, missing, and inconsistent custody evidence. A third, source-based AI comparison evaluates published model-hub, lineage, and hardware-attestation mechanisms against the same seven assurance functions. Together, these applications provide a seven-layer evidence coverage analysis, reproducible synthetic decisions, and an AI-specific cross-study verification analysis.

The CAR investigation provides field observations and documented transactions [18]; assigning those records to the seven assurance layers and identifying missing technical evidence are the authors’ retrospective assessments (Table 6). The M-017/P3 custody variants, K1–K7 checks, and AUTHORIZE/HOLD outputs are specified and calculated within this review (Table 7 and Table 8; Supplementary Tables S11 and S12). The AI studies independently report model-hub threats, checkpoint provenance, and property attestations [23,24,25,26]; applying those properties to model-release hand-offs is the authors’ comparative result (Supplementary Tables S9 and S10).

Table 5. Evidence objects and independent validation questions used in the custody-based Applications A and B.

Level	Evidence Object	Validation Question	Boundary-Specific Failure
L1	Physical observation and item identifier	Do recovered/observed markings correspond to the entity under review?	Entity mismatch or untraceable observation
L2	Identifier-to-credential and custodian record	Does the bound identity correspond to that item and authority?	Detached identity or invalid authority
L3	Signed measurement, freshness, and reference state	Does the attestation describe the approved configuration at decision time?	Stale, unbound, or unsupported measured state
L4	Signed transformation and custody events	Is the transfer from the previous to the proposed custodian recorded?	Missing or contradictory custody transition
L5	Event-specific registry receipt and integrity proof	Does a verified receipt cover the required event rather than another statement?	Receipt misapplied to unregistered event
L6	Versioned end-use policy, recipient evidence, and decision record	Are identity, current state, and custody evidence consistent with the intended recipient?	Authorization based on an incomplete or contradictory record
L7	Retained evidence bundle, policy version and exception record	Can the decision and any discrepancy be reconstructed and escalated?	Undetected mismatch or irreproducible decision

Table 5. Evidence objects and independent validation questions used in the custody-based Applications A and B.

Level	Evidence Object	Validation Question	Boundary-Specific Failure
L1	Physical observation and item identifier	Do recovered/observed markings correspond to the entity under review?	Entity mismatch or untraceable observation
L2	Identifier-to-credential and custodian record	Does the bound identity correspond to that item and authority?	Detached identity or invalid authority
L3	Signed measurement, freshness, and reference state	Does the attestation describe the approved configuration at decision time?	Stale, unbound, or unsupported measured state
L4	Signed transformation and custody events	Is the transfer from the previous to the proposed custodian recorded?	Missing or contradictory custody transition
L5	Event-specific registry receipt and integrity proof	Does a verified receipt cover the required event rather than another statement?	Receipt misapplied to unregistered event
L6	Versioned end-use policy, recipient evidence, and decision record	Are identity, current state, and custody evidence consistent with the intended recipient?	Authorization based on an incomplete or contradictory record
L7	Retained evidence bundle, policy version and exception record	Can the decision and any discrepancy be reconstructed and escalated?	Undetected mismatch or irreproducible decision

Application A: Retrospective assessment of reported GNSS module diversion. CAR documented European-origin GNSS modules with anti-interference capabilities in recovered military UAVs and traced commercial transactions to recipients near the China–Myanmar border [18]. Reported civil-use commitments and subsequent military deployment establish an end-use discrepancy relevant to monitoring. Table 6 maps this evidence onto the seven architectural functions. Each finding distinguishes the recorded observation from an assessment requiring further technical records. An unreported control is assigned the status “unknown”. Regulatory classification and potential legal violations require a separate assessment.

Table 6. CAR-reported evidence and authors’ retrospective seven-layer assessment of the Myanmar GNSS-component case [18].

Level	Evidence Reported or Unavailable	Finding Under the Architecture	Status
L1	Recovered anti-interference GNSS modules integrated in weaponized UAVs.	Physical items and military-use context documented.	Observed
L2	CAR traced a European-origin commercial route and downstream recipients.	Trade-actor association supported; cryptographic unit-to-custodian binding not evidenced.	Partial
L3	No remote-attestation report or measured-boot output is provided in the cited field account.	Firmware state, attestation freshness, and reference-value appraisal cannot be evaluated.	Unknown
L4	Civil-use commitments and transactions are reported alongside subsequent military use.	Declared and observed use diverge; completeness of individual transfer-event records is unknown.	Discrepancy
L5	The cited field account supplies no verifiable event-registration receipt or log-consistency proof.	Registration integrity and completeness cannot be assessed from the published evidence.	Unknown
L6	The documented end-use discrepancy supports a retrospective compliance or misuse review.	Triggers investigation; regulatory classification and legality require separate evidence.	Escalate
L7	CAR’s field tracing links recovered artifacts to commercial transactions.	External documentation permits retrospective reconstruction and further institutional inquiry.	Observed

Table 6. CAR-reported evidence and authors’ retrospective seven-layer assessment of the Myanmar GNSS-component case [18].

Level	Evidence Reported or Unavailable	Finding Under the Architecture	Status
L1	Recovered anti-interference GNSS modules integrated in weaponized UAVs.	Physical items and military-use context documented.	Observed
L2	CAR traced a European-origin commercial route and downstream recipients.	Trade-actor association supported; cryptographic unit-to-custodian binding not evidenced.	Partial
L3	No remote-attestation report or measured-boot output is provided in the cited field account.	Firmware state, attestation freshness, and reference-value appraisal cannot be evaluated.	Unknown
L4	Civil-use commitments and transactions are reported alongside subsequent military use.	Declared and observed use diverge; completeness of individual transfer-event records is unknown.	Discrepancy
L5	The cited field account supplies no verifiable event-registration receipt or log-consistency proof.	Registration integrity and completeness cannot be assessed from the published evidence.	Unknown
L6	The documented end-use discrepancy supports a retrospective compliance or misuse review.	Triggers investigation; regulatory classification and legality require separate evidence.	Escalate
L7	CAR’s field tracing links recovered artifacts to commercial transactions.	External documentation permits retrospective reconstruction and further institutional inquiry.	Observed

Application B: Deterministic replay of a controlled-module custody decision. An illustrative unit M-017 has a valid bound credential, a fresh signed firmware appraisal for approved digest H2, and a requested hand-off from custodian A to B. Policy P3 requires a signed transfer event T9, an event-specific registration receipt, and agreement between the recorded recipient and an independent shipping manifest. Valid signatures, current credential and reference status, and authorized end use are stipulated inputs. The policy returns AUTHORIZE only when all six release checks pass; otherwise, it returns HOLD with an auditable exception. Supplementary Tables S11 and S12 provide the input variants and verification predicates.

Table 7. Author-defined decision outcomes for three synthetic custody variants (policy P3).

Variant	Input Divergence	First Decisive Check	Outcome	Diagnostic Consequence
V0	Signed T9 transfer A to B; T9-specific receipt; manifest B.	L1–L6 satisfied; L7 preserves complete decision bundle.	AUTHORIZE	Evidence and policy consistent.
V1	Transfer T9 absent; valid receipt covers firmware event F4 only; manifest B.	L4 lacks transfer; L5 has no T9-specific receipt; L6 blocks release.	HOLD	A valid unrelated receipt cannot certify the missing transfer.
V2	Signed T9 to B and matching T9 receipt; independently recorded manifest names C.	L1–L5 satisfied; L6 recipient/manifest comparison fails; L7 preserves discrepancy.	HOLD	Registration integrity does not resolve conflicting recipient evidence.

Table 7. Author-defined decision outcomes for three synthetic custody variants (policy P3).

Variant	Input Divergence	First Decisive Check	Outcome	Diagnostic Consequence
V0	Signed T9 transfer A to B; T9-specific receipt; manifest B.	L1–L6 satisfied; L7 preserves complete decision bundle.	AUTHORIZE	Evidence and policy consistent.
V1	Transfer T9 absent; valid receipt covers firmware event F4 only; manifest B.	L4 lacks transfer; L5 has no T9-specific receipt; L6 blocks release.	HOLD	A valid unrelated receipt cannot certify the missing transfer.
V2	Signed T9 to B and matching T9 receipt; independently recorded manifest names C.	L1–L5 satisfied; L6 recipient/manifest comparison fails; L7 preserves discrepancy.	HOLD	Registration integrity does not resolve conflicting recipient evidence.

Under policy P3, K1–K3 pass in all variants. K4–K5 identify the missing event in V1, while K6 identifies the recipient conflict in V2. Table 8 shows these staged predicates; Supplementary Table S12 lists their inputs. The complete policy returns AUTHORIZE for V0 and HOLD for V1 and V2, with K7 retaining decision records. These distinctions apply only to the specified synthetic inputs.

Table 8. Authors’ staged comparison of verification predicates for the synthetic V0–V2 cases (policy P3; Supplementary Table S12).

Evaluated Predicates	Decision Information Available	V0 Complete	V1 Missing T9	V2 Manifest Conflict
K1–K3	Item, bound credential, fresh approved state	PASS; transfer untested	PASS; transfer untested	PASS; transfer untested
K1–K5	Above, plus signed T9 and matching receipt	PASS; recipient untested	FAIL K4/K5; T9 absent	PASS; recipient untested
K1–K6 (policy P3)	Above, plus end use and independent recipient agreement	AUTHORIZE	HOLD; missing transfer	HOLD; recipient conflict

PASS for a subset is not release authorization: P3 requires K1–K6. The staged comparison is deterministic, with no deployed-system performance estimate.

Table 8. Authors’ staged comparison of verification predicates for the synthetic V0–V2 cases (policy P3; Supplementary Table S12).

Evaluated Predicates	Decision Information Available	V0 Complete	V1 Missing T9	V2 Manifest Conflict
K1–K3	Item, bound credential, fresh approved state	PASS; transfer untested	PASS; transfer untested	PASS; transfer untested
K1–K5	Above, plus signed T9 and matching receipt	PASS; recipient untested	FAIL K4/K5; T9 absent	PASS; recipient untested
K1–K6 (policy P3)	Above, plus end use and independent recipient agreement	AUTHORIZE	HOLD; missing transfer	HOLD; recipient conflict

PASS for a subset is not release authorization: P3 requires K1–K6. The staged comparison is deterministic, with no deployed-system performance estimate.

The first two applications illustrate selected evidence requirements for architectural verification. The CAR mapping identifies the functions supported by field observations and the technical assurance records unavailable in the cited public report. The replay yields two distinct evidentiary discrepancies: an absent transfer event and a conflicting recipient. The HOLD decisions locate the affected policy checks; determining whether the records reflect omission, error, or deliberate interference would require investigation of the underlying events. These paths illustrate selected identity, custody, registration, and policy checks relevant to RQ1, RQ2, and RQ4 (Table 5, Table 6 and Table 7; Supplementary Tables S9–S12). The disclosure and retention requirements for RQ3 are analyzed in Section 3.2; neither application implements or validates those privacy controls. The staged comparison in Table 8 identifies the extra evidence responsible for separating the outcomes under K1–K3, K1–K5, and K1–K6.

Application C: Cross-study assessment of model provenance and attestations. The published mechanisms were mapped to an AI model distributed after fine-tuning: the checkpoint digest identifies the released artifact (L1–L2); a recorded training or inference environment supports bounded state or property attestations (L3); checkpoint creation, dataset references, and fine-tuning steps supply lifecycle relationships (L4); signed manifests and transparency entries support registration checks (L5); and recipient-specific release policy and retention remain separate questions (L6–L7). Atlas demonstrates selected L3–L5 operations on ML pipelines [24], and Laminator supports independently verifiable model and inference property claims under its TEE assumptions [25]. CycloneDX model and dataset representations provide additional schema-level provenance fields [68]. This mapping compares documented mechanisms; it does not describe a jointly deployed system.

The failure distinction is concrete. A valid publisher signature for a model checkpoint can coexist with a harmful model-loading script of the type investigated in MalHug [23,26]. Conversely, a genuine TEE attestation may cover one training execution, while a downstream checkpoint lacks a verifiable link to that execution or to the intended dataset manifest [24,25]. The proposed hand-off checks therefore compare (i) the exact checkpoint and publisher identity; (ii) attested training/inference context; (iii) provenance links to the relevant transformation and dataset identifiers; (iv) the registered statement or receipt; and (v) a recipient- and purpose-specific release decision. Failed associations would require re-verification or an auditable HOLD under a policy analogous to P3; that outcome is an architectural inference, not a measured result of the published AI implementations (Supplementary Tables S9 and S10).

4. Discussion

4.1. Architectural Trade-Offs and Research Gaps

Centralized and federated architectures place different demands on governance. In this respect, SCITT receipts permit verification of registration without centralizing the underlying payload [32]. Nevertheless, the two architectural approaches entail different trade-offs: centralization simplifies coordination but concentrates records and authority; federation preserves institutional autonomy while requiring explicit trust directories, semantic alignment, revocation propagation, and detection of inconsistent views. The relevant comparison is whether an independent auditor can reconstruct a decision from attributable evidence, policy, status, and time context across organizations.

These considerations are reflected in the applications, which illustrate the value and limits of that reconstruction. CAR documents recovery, supply-chain tracing, and an end-use discrepancy [18], without establishing remote attestation or verifiable registration (Table 6). By comparison, in the stipulated P3 replay, V1 isolates missing custody evidence despite an unrelated valid receipt; V2 isolates recipient inconsistency despite registration of T9. Table 8 identifies when each additional check distinguishes the variants (Table 7 and Table 8; Supplementary Tables S11 and S12). This is diagnostic separation under defined inputs, with no measured operational effectiveness.

Alongside these verification requirements, privacy must be considered along the evidence path. Selective disclosure reduces revealed credential attributes, while stable identifiers and metadata may still enable linkage [8]. At the institutional level, governance determines when disclosure is justified by purpose and authority [40], particularly for sensitive cyber-surveillance evidence [65]. The proposed controls therefore distinguish routine verification, authorized escalation, and retention sufficient for later audit. Figure 3 depicts this workflow; its privacy effectiveness remains untested.

Figure 3. Privacy-aware evidence disclosure, escalation, and retention model. The model combines graduated disclosure, authority-bound escalation, differential retention, residual privacy risks, and cross-stage guardrails for auditable decision-making. This figure is an original visualization created by the authors from the reviewed corpus.

Cross-layer assurance depends on evidence that survives changes in representation and authority. In this context, physical binding may identify an item at enrollment, yet repair, relabeling, or ownership changes require renewed association [1]; custody models describe later transfers [37]. Similarly, RATS specify attestation appraisal [6], and EAT represents exchanged claims [7], but component claims can become stale or incomplete when combined. At the implementation level, VRASED supports a bounded implementation under explicit assumptions [33], which cannot be generalized automatically. Meanwhile, SPDX can align software metadata syntax [73] without resolving event meaning, missing records, or policy authority. These examples support the proposed requirement to preserve entity, event, attestation, and decision-time references across interfaces.

The implementation perspective also reveals different optimization targets. Watermarking measures platform-specific costs [9], PUF studies emphasize enrollment and reliability [14], and attestation studies measure execution and report overhead under particular threat models [33]. Given these differences, cross-domain evaluation should instead report shared verification outcomes: evidence completeness, binding reliability, latency, disclosure, revocation propagation, missing-event detection, audit reconstruction, policy reproducibility, linkability, and resilience to partition or power loss. These criteria remain proposed comparison measures, not a common benchmark computed from the reviewed studies.

4.2. Scope and Limitations

Confidence in the findings varies across the architecture because the supporting evidence has matured unevenly. For example, identity and attestation are anchored in established normative role models [6]. By contrast, privacy-preserving verification remains less settled because part of its evidentiary basis still depends on evolving specifications and limited operational validation [74]. Beyond these differences, evidence is thinner for independent multi-vendor attestation, realistic linkability evaluation, pre-ingestion completeness, composite cyber–physical assets, and classified or proprietary monitoring environments. Within this broader context, published AI studies document model-hub scanning, pipeline provenance, and trusted-execution property attestations [23,24,25]. Section 3.5 compares their evidence contracts with the seven-layer model; it does not deploy the complete architecture or measure cross-system detection effectiveness. Published work remains limited in independent multi-operator verification, training-data completeness, model-output policy linkage, and institution-specific transfer decisions. NIST guidance [70,71] informs governance and misuse risk, separately from the technical evidence of the three implementations. The authors therefore treat the seven-layer model as a synthesis whose strongest support lies in the recurring assurance functions and dependencies identified across the corpus, with end-to-end validation across all layers, domains, and deployment conditions remaining an open empirical task.

Regarding the review procedure, co-author checks verified selection rationales, source charting, and analytical codes against original texts; differences were resolved through rereading and agreement. Supplementary Tables S3, S4 and S7–S10 retain the inventory, criteria, and mappings. At the same time, integrated deployment evaluation remains future work; Section 3.5 provides retrospective evidence mapping, a controlled policy replay, and a source-based AI-lifecycle comparison.

However, the available review documentation records reconciled inclusion decisions and cross-author verification, but it does not provide two separately archived initial screening decisions for every candidate record. Consequently, agreement between independent first-pass screeners cannot be calculated from the reported materials, and fully duplicate-independent initial screening of the original 120 candidates cannot be verified retrospectively. This limits the auditability of screening agreement; source-based checks of selection, charting, and coding remain documented in Section 2.2 and Supplementary Tables S3, S4 and S7–S10.

Beyond these methodological limitations, privacy and embedded constraints remain under-tested in combination. Protected computation and selective disclosure reduce exposure [15], but linkability, collusion, revocation, retention, and cross-vendor interoperability require operational evaluation. Similarly, embedded overhead is platform-specific [33]; Table S2 provides bounds rather than a common benchmark. Verification questions may transfer across domains, although the necessary evidence and decision authority remain domain-specific.

5. Conclusions

The principal contribution of this review is a source-traceable way to assess whether evidence established at one lifecycle stage is sufficient for the decision made at the next. The proposed seven-layer architecture associates each function with a defined evidence object, verification question, and decision responsibility. Its advantage is diagnostic specificity: an authenticated entity, a fresh attestation, an intact provenance record, and a valid transparency receipt can each be correct within their own scope while leaving a claim about the relevant event, recipient, or authorization unresolved. By making these dependencies explicit at six hand-offs (Table 3; Supplementary Tables S9 and S10), the architecture offers an auditable basis for assessing the continuity of evidence across technical systems and institutional authorities. The separation remains useful when implementations combine logical functions, provided the evidence objects and verification predicates remain independently identifiable (Section 3.4).

The practical advantage becomes visible in the two custody-based applications. The CAR investigation provides field evidence of a component supply chain and an end-use discrepancy, while the mapping identifies records needed for additional technical verification (Table 6) [18]. In the deterministic replay, valid identity and state-attestation evidence are identical across the three variants, yet the release outcome depends on different downstream checks. V0 is authorized under policy P3; V1 returns HOLD because the required transfer T9 and its event-specific registration receipt are absent; V2 returns HOLD because the recipient recorded for a valid transfer conflicts with the independent manifest (Table 7 and Table 8; Supplementary Tables S11 and S12). The separate checks identify the reason for each failed decision and specify which evidence must be examined next. This produces a more informative audit trail than a single aggregate assessment of the evidence package.

The AI-model comparison extends this diagnostic approach to malicious model-loading content, cryptographically linked model lineage, attested training or inference properties, and publisher signatures [23,24,25,26]. These mechanisms establish different claims, and their comparison identifies the links a verifier would need between a particular checkpoint, its transformation history, its registered record, and a recipient-specific release decision. The proposed disclosure, escalation, and retention workflow (Figure 3) likewise makes the evidence needed for authorized verification and later institutional review explicit. Across physical components, digital artifacts, and AI models, the contribution is therefore a reusable set of evidence contracts and testable interface checks, grounded in the documented scope of the constituent mechanisms. Their value is to make missing or conflicting assurance claims identifiable, and decisions reconstructable. Integrated deployments are still needed to measure operational detection, performance, interoperability, and privacy outcomes under realistic threat and governance conditions.