A bounded, edition-locked method for comparing AI security control requirements, examining operating evidence, and connecting control claims to incident records. A framework relationship does not, by itself, establish implementation, effectiveness, normative equivalence, or assurance.

Abstract

Organizations use crosswalks to relate AI governance requirements to security controls, risk categories and incident records. Such relationships support analysis and planning, but they do not establish normative equivalence or effectiveness in a deployed system. This technical methods note proposes an edition-locked, directed mapping protocol using the nine domains and 59 controls of ODA3 Institute’s Global AI Safety and Security Framework (GAISSF™) as the starting catalogue, with NIST AI RMF 1.0, ISO/IEC 42001:2023 and edition-specific OWASP guidance as possible comparison instruments. ODA3’s Unified AI Incident Framework (UAIF™) is treated separately as an incident-data layer rather than a preventive control catalogue.

The method distinguishes four propositions: semantic mapping, control design, observed operating effectiveness, and incident classification. It defines evidence sufficiency ratings, presents five explicitly unverified candidate mappings and a constructed restricted-payment-agent scenario, and identifies evidence that would be needed for stronger claims. ODA3-controlled internal records report a 59-control source examination and 20/20 locally constructed JSON Schema expected-outcome checks; those internal results have not been independently reproduced in this editorial exercise. The note does not assert independent normative equivalence, production effectiveness, third-party interoperability or certification.

Keywords: AI security; AI assurance; cross-framework mapping; evidence sufficiency; incident classification; runtime controls; edition control; agentic AI.

Executive evidence boundary

Proposition Reported or available evidence Permissible conclusion Not established
P1 — Semantic mapping Public GAISSF catalogue and publisher-authored crosswalks; internally reported examination of 59 July-edition source records Source identities and candidate analytical relationships may be documented Independently adjudicated equivalence or a validated coverage percentage
P2 — Control design Proposed claim-and-evidence protocol and constructed specimens Control objectives, design requirements and requests for proof can be specified Implemented or effective production controls
P3 — Operating effectiveness A constructed restricted-payment scenario; no production execution under this note A bounded testing method and decision criteria can be illustrated Deployed-system effectiveness
P4 — Incident classification Published UAIF specifications and internally reported 20/20 local schema checks Local expected-outcome testing is reported for an archived schema and local fixtures Original publisher-fixture replay, semantic severity correctness, live endpoint parity or third-party interchange

This table is not a maturity score, compliance percentage or certification decision.

1. Problem, contributions and non-claims

Four materially different propositions are regularly conflated:

Proposition Claim What it does not prove
P1 — Semantic mapping Two identified requirements or instruments concern related subject matter That their normative requirements are equivalent
P2 — Control design A proposed mechanism is intended to prevent or detect a specified failure That it has been deployed or is effective
P3 — Operating effectiveness Behaviour has been observed for a stated build, identity, environment, test and time window That the result generalizes to other configurations or future operation
P4 — Incident classification An event and its evidence, observed effect and degree of causal confidence have been recorded That a suspected mechanism is an established root cause

These propositions are analytically distinct; none automatically establishes another. A P1 row is not evidence of P3, and a P4 incident record is not a substitute for a P2 control requirement. Their ordering in this paper does not imply that one must happen before another.

Contributions. This note provides (1) an edition-locked, directed relationship-coding protocol; (2) explicit P1–P4 claim separation; (3) a bounded evidence-sufficiency method demonstrated with a constructed payment-agent scenario; and (4) a claim-to-evidence and verification-dependency register.

Non-claims. The work presents no empirical finding about deployed AI systems, independent 59-control equivalence audit, completeness or conformity percentage, quantified savings, certification, external endorsement or independent reviewer agreement. The separately reported local source-extraction and JSON Schema checks are bounded technical QA, not deployment observations.

2. Roles and boundaries of the reference instruments

NIST AI RMF 1.0 organizes voluntary AI risk management across GOVERN, MAP, MEASURE and MANAGE; it is not a universal runtime-control test or incident interchange format [S7]. ISO/IEC 42001:2023 specifies requirements for an artificial intelligence management system (AIMS); it is not a list of individual attack techniques [S8]. OWASP guidance addresses technical risks and emerging agent-control approaches; edition-specific categories and identifiers must be identified before a relationship is relied upon [S4, S9, S10].

GAISSF™ v1.0 supplies ODA3’s control catalogue, arranged in nine domains and 59 control IDs [S1, S12]. UAIF™ v1.0 supplies incident taxonomy and schema concepts, not additional GAISSF preventive controls [S5, S6]. Different instruments answer different questions and cannot be reduced to one equivalence or completeness score.

2.1 Edition locking and the OWASP 2025–2026 boundary

The existing GAISSF-CRO-024 crosswalk explicitly maps the OWASP Top 10 for LLM Applications 2025 edition; it does not map the later 2026 edition [S4]. OWASP’s 2026 resource page provides a separate publication [S9]. Publication-date labels can differ across OWASP web properties; the resource edition and exact item identifier, rather than an inferred date alone, govern the row.

An entry describing “prompt injection” or “Excessive Agency” without an exact source edition and identifier cannot safely be treated as an edition-stable citation. This article therefore uses explicit unverified markers wherever primary category-level text was not compared and does not silently transfer a 2025 mapping into 2026.

2.2 Agent Control Standard: source identity versus validation

The OWASP Agent Control Standard (ACS) has an official public project record [S10]. A v0.1.0 specification is described in the project’s public materials; the exact specification and its repository release history must be distinguished. The identification of a published specification is not evidence of implementation maturity, conformance, GAISSF compatibility, exercised controls or third-party interoperability. ACS appears here only as a potential, separately versioned technical comparator.

2.3 Reported GAISSF and UAIF research examination

GAISSF source records. ODA3-controlled records report parsing the 1 July 2026 Final Publication Edition of GAISSF-NOR-004 and extracting technical-control descriptions, validation test specifications (VTS) and requested evidence for all 59 controls. Control identifiers were reconciled with publisher-authored CRO-019 and CRO-022 records. These are publisher-conducted source examination and provenance checks. The later October catalogue revision has not been demonstrated to be fully field-diffed against the July examination edition in this note.

ISO/IEC 42001. CRO-019 reports its own publisher-conducted revalidation across 59 GAISSF controls using ISO/IEC 42001:2023 source material supplied for that mapping [S2]. This note does not independently repeat or adjudicate the underlying clause-by-clause examination. The locally reported CRO-019 inventory contains 29 distinct ISO reference strings: that is a locator count, not normative coverage. CRO-019 remains publicly identified as a draft for publication with external review open; ISO source-access and processing rights are not established by this article.

UAIF schema. ODA3-controlled research records report that an archived uaif-core-v1.0.json passed Draft 2020-12 metaschema validation and 20/20 locally constructed positive/negative expected-outcome tests using Python 3.13.5 and jsonschema 4.26.0 with format checking. These are internally reported results, not an independently executed test for this revision. The original 15-case publisher fixture corpus was not replayed; live-server schema identity, semantic severity calculations and Security Operations Center/Security Information and Event Management (SOC/SIEM) interchange were not established. Underlying local test logs and hashes are retained in the controlled archive, not supplied as public attachments here.

3. Directed mapping protocol

3.1 Unit of analysis

A mapping row represents one directed relationship from a specified GAISSF control to one identified external clause, category or risk entry under a stated edition. One control may have zero, one or several candidate rows. Reverse-direction coverage requires a separate test: A relating to B does not mean B fully covers A. UAIF fields are treated as a different type of linkage, not synthetic GAISSF controls.

3.2 Relationship codes and decision rules

Code Meaning Required discipline
D Direct Compare exact applicable source statements, direction, scope, exclusions and rationale; independent adjudication still separately reported
S Supporting Exact-text examination supports a narrower or indirect contribution, not equivalence
C Contextual Specific source statements examined and a contextual relation supported without requirement-level correspondence
N No substantiated relation Documented examined comparison universe, identified exact source statements and reasoned exclusion
U Unverified Candidate relationship lacks sufficient exact-text comparison or required supporting record

A row begins at U. A title-level similarity alone never justifies C, S or D. Move to C only after the exact external entry and relevant GAISSF statement have been examined; move to S or D only with written scope, direction, rationale and exclusions. N requires an identified comparison universe and a documented negative determination. None of the five worked candidates is upgraded beyond U here. Relationship codes do not represent compliance, effectiveness, verification-grade strength or endorsement.

3.3 Minimum mapping-register fields

GAISSF control ID; exact published title; GAISSF edition; control-statement locator; external family; exact external document ID; source edition; exact clause/category identifier or unverified; direction; relationship code; reasoned rationale; applicability and scope; example positive evidence; actual missing/contradictory evidence or not examined; exceptions; source URL or restricted locator; reviewer; review date; conflict/disagreement; review status; and approval state.

3.4 Detailed illustrative candidate: D3-CTL-01

The following is a field-complete illustrative candidate record, not a finalized normative mapping. Fields for which no examination is demonstrated are expressly marked unverified or not examined.

Field Value
GAISSF ID D3-CTL-01
Published title Least Agency Enforcement [S1]
GAISSF edition and locator v1.0; NOR-004, 1 July 2026 publication edition; control D3-CTL-01 [S12]
External family OWASP Top 10 for LLM Applications
External document identity OWASP 2026 resource [S9]; exact downloadable category document not independently examined in this mapping
Source edition 2026 candidate; separately, CRO-024 addresses 2025 [S4]
Exact external entry identifier Unverified; “Excessive Agency” is a thematic search label, not a verified 2026 entry citation
Direction GAISSF → OWASP
Relationship U — unverified
Candidate rationale Potential common concern with limiting agent authority and delegated operations; normative correspondence untested
Applicability/scope Agent/tool authorization and effective permission boundaries, not generalized prompt-injection resistance
Illustrative evidence request Agent/tool manifest, identities, effective permissions, deny-path tests, payment-system enforcement traces, time-aligned logs
Negative or contradictory evidence Not examined; no executed finding reported for this candidate
Exceptions Delegated overrides, escalation conditions and alternate identities require separate examination
Source or locator [S1], [S4], [S9], [S12]; restricted normative source locator, if any, requires authorized review
Reviewer and date No independent row reviewer or date established
Conflicts Edition-category identity unresolved; 2025 CRO-024 must not be transferred to 2026
Status and approval Candidate only; U; not independently adjudicated or approved as normative equivalence

3.5 Disputes and double-coder protocol

Two independent reviewers should separately examine the same exact version-locked source statements, propose direction and code, and record rationale and exclusions. Disagreements retain both original codes and their reasons until adjudication; unresolved rows remain U. Any inter-rater statistic must identify its denominator, distribution and handling of U; Cohen’s kappa may be used when appropriate. No independent double-coded sample or reviewer agreement statistic is reported for this publication.

4. GAISSF domain-level comparison inventory

GAISSF domain Controls Possible external comparison instrument Current conclusion
D1 — Model Integrity & Adversarial Robustness 9 NIST AI RMF MEASURE; edition-identified OWASP model/data risks Thematic candidate only — U
D2 — Runtime Security & Adversarial Defense 6 NIST MEASURE/MANAGE; edition-identified OWASP prompt-injection material Thematic candidate only — U
D3 — Agentic Risk & Autonomous System Security 7 Versioned OWASP agentic risk guidance and ACS Thematic candidate only — U
D4 — Supply Chain & Third-Party AI Security 7 NIST GOVERN/MAP; ISO/IEC 42001:2023 supplier-related management-system examination Thematic candidate only — U
D5 — Content Safety & Output Integrity 6 NIST risk measurement and edition-identified OWASP output-related guidance Thematic candidate only — U
D6 — Governance, Accountability & Human Oversight 7 NIST GOVERN; ISO/IEC 42001:2023 AIMS provisions Thematic candidate only — U
D7 — Human & Societal Harms 5 Relevant NIST AI RMF mapping questions; separately documented social-engineering/deepfake threat material where exactly identified Comparison universe incomplete — U; not a broad fairness equivalence claim
D8 — Regulatory Alignment & Compliance 5 ISO/IEC 42001:2023 management-system context; separately identified jurisdictional obligations Regulation- and context-dependent — U
D9 — Physical AI Safety 7 NIST AI risk-management context; physical-system safety standards require separate identification and review Contextual starting point only — U; no machinery-safety conformity finding
Total 59

The nine domain counts sum to 9 + 6 + 7 + 7 + 6 + 7 + 5 + 5 + 7 = 59. Domain similarity is not a 59-control mapping result, and D7 must not be represented as comprehensively covering fairness or bias. No physical safety standard equivalence is established for D9.

5. Worked candidate mapping rows

Five unique specimen control IDs are provided below. The detailed D3-CTL-01 example in §3.4 is an expanded view of one of these five, not an additional sixth mapping.

GAISSF control External comparison (edition/identifier discipline) Proposed theme Evidence needed for stronger assessment Relationship
D2-CTL-01 — Direct Prompt Injection Prevention OWASP Top 10 for LLM Applications 2026, exact entry identifier unverified [S9] Instruction-injection attack boundaries Versioned adversarial cases, legitimate-input baselines, blocked/bypassed execution traces U
D3-CTL-01 — Least Agency Enforcement OWASP 2026 “Excessive Agency” title-level hypothesis; exact identifier unverified; ACS specification must be separately version-locked [S9, S10] Agent authority and delegated permission boundaries Effective tool/IAM scope, negative authorization tests and backend enforcement logs U
D4-CTL-05 — Third-Party AI API Security Assessment NIST AI RMF 1.0 GOVERN/MAP functions; ISO/IEC 42001:2023 supplier-related clauses not adjudicated [S7, S8] Supplier and API exposure governance Contractual and technical scope, configuration inventory, dependency tests, evidence-access limits U
D6-CTL-02 — Audit Trail Completeness NIST AI RMF 1.0 MEASURE/MANAGE; ISO/IEC 42001:2023 documentation/monitoring provisions not clause-adjudicated [S7, S8] Record completeness and traceability Logging policy, coverage tests, clock synchronization, exclusions, integrity and retention checks U
D9-CTL-03 — Human Override and Emergency Stop NIST AI RMF 1.0 broader risk context; no identified safety-standard equivalence [S7] Human intervention for physical effects Authorized stop activation tests, response latency, measured safe state, operator access U

These five rows are candidate thematic relationships only, not independently validated control-to-requirement entailments. Exact-source reading, licensed source access where relevant, documented direction/rationale/exclusions and independent adjudication are required before stronger relationship claims.

6. UAIF as a distinct incident-evidence layer

A GAISSF control mapping asks what was required, designed or tested to prevent or detect a failure. A UAIF incident record addresses what was observed and with what causal confidence. A defensible incident record separates:

  1. Observation: what was actually seen and where recorded.
  2. Mechanism hypothesis: what attack or failure mechanism is suspected.
  3. Investigated root cause: what investigation supports as causal.
  4. Consequence: what actually happened to people, systems, funds or operations.
  5. Response: what containment, restoration, notification or follow-up took place.

A suspected prompt-injection origin cannot be upgraded to an established root cause without an adequate investigation. A link from an incident record to a mapped control is navigational and evidentiary, not automatically a finding that the control failed; deployment, applicability and actual causality remain separate questions.

The UAIF JSON Schema tests summarized in §2.3 assess only the archived file and locally authored fixtures. They do not demonstrate publisher-fixture conformance, semantic severity correctness, deployed integration or external SOC/SIEM interchange [S5, S6].

7. Constructed scenario: an AI agent attempting an over-limit payment

This is a constructed scenario, not an ODA3-executed test or a customer incident. Every outcome in this section is hypothetical.

An enterprise agent may retrieve invoices but must not initiate a payment above its delegated limit. A written policy and a proposed D3-CTL-01 mapping establish intent or analytic relevance at most. The actual control-effectiveness question is narrower: “In build X, under service identity Y, a payment above delegated limit Z is rejected at the payment API.”

7.1 Bind the examined claim

The examination must specify the agent/model/tool build, service account and delegated authorizations, payment interface and backend enforcement point, permitted and denied transaction classes, expected results, positive and negative test corpus, observation period, logs, timestamps and known bypass or exception paths. This is a claim boundary, not a generic assertion that the agent is safe.

7.2 Evidence-sufficiency outcomes

Hypothetical evidence Disposition Interpretation
A pre-specified over-limit attempt is rejected at the documented payment API; time-linked execution and rejection evidence are retained Supported Only for that observed build, identity, endpoint, test and period
Rejection is observed, but the actual enforcement point or material provenance is missing Partial Some outcome support, insufficient evidence for the full stated claim
A valid over-limit test results in the prohibited payment being issued Gap The specified rejection criterion was not met under the tested conditions
The policy exists, but no adequate test or observation establishes enforcement Unknown Absence of an effectiveness record is not proof of a control failure
One identity is tested and denied; alternate roles are not examined Supported for tested identity; Unknown for others Findings cannot be generalized beyond the test boundary

The distinctions are claim-dependent: if completeness of logging is itself the claim under examination, demonstrated logging failure can establish a Gap in that logging requirement even when payment rejection occurs. Unknown is not Gap, and a supported test is not a universal guarantee.

7.3 If the prohibited transaction succeeds

Record the actual payment, transaction identifiers and system observations separately from any proposed explanation (such as prompt injection, authorization misconfiguration or API-side policy bypass). Do not classify an uninvestigated proposed mechanism as root cause. UAIF may provide the incident-record vocabulary, but using its fields does not itself validate external incident-data interchange.

8. Risk-proportionate evidence planning

Prioritize examination of controls that can transfer funds, expose sensitive data, change permissions, issue external commands or actuate physical systems. Consider consequence severity, reversibility, detection difficulty, vendor reliance, changes since the last examination and incident signals. Evidence depth and re-examination intervals should be justified by the identified operating risk rather than a made-up universal schedule.

Keep normative mapping effort separate from production effectiveness testing in scopes, budgets, methods and acceptance decisions. The number of directed relationships cannot be computed by simply multiplying 59 controls by the number of referenced standards: some controls may yield no correspondence, several links or asymmetric reverse coverage. A timed and stratified pilot would be needed before estimating review workload; no throughput or completion percentage is claimed here.

9. Threats to validity and independent challenge

Threat Potential distortion Safeguard / residual limitation
Title-level comparison Shared wording conceals different obligations Candidate remains U pending exact-source comparison
Edition drift A category ID or requirement changes across versions Lock source edition, exact identifier and examination date
Publisher-authored crosswalk Internal self-reference is mistaken for independent verification Attribute CRO-019/022/024 to ODA3; external adjudication remains open
Single-researcher coding Confirmation bias or unchallenged rationale Double-code/adjudicate, retain original disagreement; none reported here
Internal QA records Local test claims mistaken for external verification Identify reported run, fixture scope and unavailable artifacts
Licensed ISO/IEC materials Unlawful copying or implied authorized reuse Rights-conscious examination protocol; no normative text reproduced
Constructed scenario Hypothetical case presented as actual breach/test Explicit labels and no empirical deployment conclusion
Management-system versus technical control Organizational requirement assumed to enforce a runtime function Record direction, scope, exclusions and implementation evidence separately

9.1 Negative-case challenge (constructed)

Suppose D9-CTL-03 (Human Override and Emergency Stop) were asserted to be directly equivalent to an ISO/IEC 42001 organizational-responsibility provision. A reviewer must ask whether that provision actually entails emergency-stop actuation, latency and observable safe-state behaviour. A management-system obligation cannot alone demonstrate a deployed emergency-stop mechanism.

Depending on exact lawfully examined text, the result might be supporting, contextual or no substantiated relationship. No specific ISO clause is coded N in this example; a valid N determination requires a defined comparison universe, exact-text examination and a documented negative rationale.

9.2 ISO/IEC copyright and licensed-text handling

Review of ISO/IEC 42001 normative provisions must be undertaken by appropriately authorized reviewers using lawfully obtained materials within the permissions of the applicable licence. Public analytical registers should identify source editions, clause locators, ODA3-authored rationales, mapping direction, applicability, exclusions and limitations without reproducing protected normative provisions.

Internal locators and reviewer workpapers may assist traceability and challenge only insofar as their creation, copying, storage, processing and disclosure are permitted by the applicable rights. Access controls alone do not authorize reproduction or AI-assisted ingestion. This methods statement is not legal clearance, permission to distribute copyrighted text, confirmation of any particular licence, or ISO/IEC endorsement.

10. Publication-quality criteria and open research gates

Publication of this methods-only note is not completion of the research required for stronger assurance claims. A validated directed mapping requires identified controlling editions, exact-source comparison, reasoned direction and exclusions, appropriate source rights and review/adjudication status. An operating-effectiveness assertion requires the observed deployment boundary, defined test, recorded result, provenance and exceptions. An incident-causality assertion requires separation of observed facts from investigated inferences.

Claim boundary What is reported or publicly identified What remains open
GAISSF control source inventory 59 July-edition records reported examined; nine-domain catalogue publicly described Full July-to-October control-by-control field reconciliation
ISO crosswalk CRO-019 publisher source revalidation stated; locator inventory reportedly examined Independent exact-text normative adjudication and licence-specific process verification
NIST crosswalk CRO-022 publisher-authored mapping identified Independent requirement-level review of individual directed rows
OWASP crosswalk CRO-024 identified as 2025 edition Exact, independently checked 2026 entry-level comparison and revised rows
ACS comparator Public ACS specification/project identified Exact release-to-specification linkage for each cited row; conformance and deployment tests
UAIF JSON Schema 20/20 local fixtures reported against archived file Original publisher-fixture replay, live-schema hash parity, semantic severity logic, external interchange
Deployed controls Constructed scenario only Production-scoped execution and retained evidence
Independent review No documented independent mapping adjudication in this article Named reviewer, declared independence/conflicts and retained disposition

These are open research or claim-validation gates. They do not imply that a particular WordPress publishing approval is currently granted or denied. Editorial release authorization and actual webpage quality assurance must be confirmed in the separate controlled publication record; this manuscript itself does not certify those administrative actions.

11. Notably Absent

This research note does not establish:

  1. An independently adjudicated 59-control normative equivalence or full-coverage audit.
  2. A reproduced independent examination of ISO/IEC 42001 normative clauses, or legal clearance for restricted uses of those clauses.
  3. An edition-complete 2026 OWASP control-level crosswalk replacing CRO-024’s 2025 scope.
  4. Exact ACS-to-GAISSF conformance or tested interoperability.
  5. A publisher-fixture UAIF replay, live-schema identity confirmation, semantic severity conformance or third-party SOC/SIEM ingest.
  6. An empirical deployed-system control-effectiveness result, including the restricted-payment scenario.
  7. Certification, regulatory conformity, endorsement, quantified savings or independently validated mapping coverage.
  8. An independently double-coded row set, inter-rater agreement statistic or closed external review.

These omissions define what the article cannot reasonably support; they are not implied failures of any unexamined deployed control.

12. Conclusion

Mapping can identify possible relationships among AI governance requirements, technical controls and incident classifications. It cannot substitute for control design, observed runtime enforcement or incident-causality investigation. Effective assurance requires a defensible chain from a narrow, versioned claim to the appropriate design or test record and a decision explicitly limited by the evidence. GAISSF and UAIF provide distinct vocabularies that may help organize these records, but their adequacy for any use case must itself be examined rather than assumed.

Figure 1. Four distinct evidence relationships

Narrow, versioned claim
    |
    +--> P1  Requirements mapping ----> GAISSF control / external reference
    |                                    Edition + identifier; U in examples
    |
    +--> P2  Control design -----------> Policy, architecture, configuration
    |                                    Intended behaviour, not observed proof
    |
    +--> P3  Operating observation ----> Defined test, identity, version, logs
    |                                    Supported | Partial | Gap | Unknown
    |
    +--> P4  Incident classification --> Observation | hypothesis | investigated
                                         cause | consequence | response

The branches represent different evidentiary propositions;
no branch automatically substantiates another.

Appendix A. Claim-to-evidence and source-provenance register

Evidence-basis codes in this appendix are distinct from the mapping relationship codes. E1 = internally reported direct source/execution examination, not independently reproduced here; E2 = independently accessible publisher/project record; E3 = author analytical method or constructed example; E0 = unavailable/unverified evidence. An E1 rating does not imply external independent adjudication.

Claim Principal basis Evidence type Boundary or open dependency
Nine GAISSF domains and 59 catalogue records Public control finder [S1]; controlling NOR-004 identified [S12] E2 for public catalogue; E1 for reported local extraction July–October field diff not demonstrated
Five candidate IDs/titles Published control finder [S1] E2 Normative row correspondence remains U
CRO-019 publisher ISO revalidation Public CRO-019 record [S2] E2 for the publisher’s stated process Independent clause-level equivalence not established
CRO-024 maps OWASP 2025 Public CRO-024 record [S4] E2 2026 mapping not performed here
OWASP 2026 and ACS resources exist OWASP project resources [S9, S10] E2 for public identity Specific candidate category entitlements and deployment claims remain U
20/20 locally constructed UAIF test expectations reportedly passed ODA3-controlled run summary; public UAIF specification identities [S5, S6] E1 for reported local tests; E2 for public document identities Local logs/hash manifest not public; no original 15-case replay
All five specimen relationships coded U Declared method and tables in §§3–5 E3 No independent normative relationship assessment
Payment-agent classifications Clearly constructed scenario in §7 E3 No executed case or production result

Source references

Rights and attribution

GAISSF™, UAIF™, AI-IRF™ and PAI-SF™ are ODA3 Institute frameworks referenced under the GAISSF Ecosystem Licence (GEL) v1.0. Mention of NIST, ISO/IEC and OWASP instruments does not suggest sponsorship, certification or endorsement. © 2026 ODA3 Pvt Ltd.

Methodology note

Methods-only directed crosswalk coding (D/S/C/N/U); P1–P4 claim separation; source-edition locking; evidence sufficiency Supported/Partial/Gap/Unknown; hypothetical agent payment example

Notably Absent

No independent 59-control normative equivalence audit; ISO full-text adjudication; publisher UAIF fixture replay; live endpoint parity; third-party SOC/SIEM ingest; production control testing; certification or endorsement