Network Working Group T. Jacobs Internet-Draft KTS Global Intended status: Informational 5 August 2026 Expires: 6 February 2027 Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework draft-jacobs-web4-sovereign-entity-comprehension-00 Abstract This document defines requirements and an external conformance framework for sovereign Machine Entity Comprehension (MEC) systems operating in Internet-connected or Internet-capable environments. MEC is defined as an externally observable capability. A conforming system preserves entity identity across changing contexts, distinguishes similar but separate entities, determines relevant relationships and constraints, responds appropriately to material changes, handles contradictory assertions, and produces repeatable outcomes under equivalent declared conditions. The framework evaluates behavior through controlled inputs, pre- registered reference outcomes, declared system state, and observable outputs. It does not prescribe or disclose internal representations, implementation algorithms, source code, deployment architecture, confidential operational methods, or other implementation-specific mechanisms. The document also defines operational-sovereignty requirements for systems intended to remain under operator control and retain declared core capabilities without dependence on an external intelligence service. A minimal, implementation-neutral conformance record supports comparable reporting across heterogeneous systems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Jacobs Expires 6 February 2027 [Page 1] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 4. Machine Entity Comprehension Model . . . . . . . . . . . . . 8 4.1. Behavioral Definition . . . . . . . . . . . . . . . . . . 8 4.2. Identity and Context . . . . . . . . . . . . . . . . . . 8 4.3. Relationships and Constraints . . . . . . . . . . . . . . 8 4.4. Contradictory Assertions . . . . . . . . . . . . . . . . 9 4.5. Repeatability . . . . . . . . . . . . . . . . . . . . . . 9 5. Sovereignty Requirements . . . . . . . . . . . . . . . . . . 9 5.1. Dependency Declaration . . . . . . . . . . . . . . . . . 9 5.2. Operator Control . . . . . . . . . . . . . . . . . . . . 9 5.3. Disconnected Core Operation . . . . . . . . . . . . . . . 10 5.4. Information Movement . . . . . . . . . . . . . . . . . . 10 6. External Conformance Requirements . . . . . . . . . . . . . . 10 6.1. Pre-Registered Test Plan . . . . . . . . . . . . . . . . 10 6.2. Protected Evaluation Boundary . . . . . . . . . . . . . . 10 6.3. Withheld and Negative Controls . . . . . . . . . . . . . 11 6.4. Audit Record . . . . . . . . . . . . . . . . . . . . . . 11 7. Conformance Test Profiles . . . . . . . . . . . . . . . . . . 11 7.1. MEC-1: Identity Persistence . . . . . . . . . . . . . . . 11 7.2. MEC-2: Entity Disambiguation . . . . . . . . . . . . . . 11 7.3. MEC-3: Relationship Invariance . . . . . . . . . . . . . 12 Jacobs Expires 6 February 2027 [Page 2] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 7.4. MEC-4: Material Change Response . . . . . . . . . . . . . 12 7.5. MEC-5: Contradiction Handling . . . . . . . . . . . . . . 12 7.6. MEC-6: Multi-Node Outcome Equivalence . . . . . . . . . . 13 7.7. MEC-7: Disconnected Continuity . . . . . . . . . . . . . 13 7.8. MEC-8: Repeatability . . . . . . . . . . . . . . . . . . 14 7.9. MEC-9: Retrieval-Baseline Differentiation . . . . . . . . 14 8. Conformance Classes . . . . . . . . . . . . . . . . . . . . . 14 8.1. Independent Verification Label . . . . . . . . . . . . . 15 9. Result Reporting . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Required Report Fields . . . . . . . . . . . . . . . . . 15 9.2. Minimum Conformance Record . . . . . . . . . . . . . . . 15 9.3. Conformance Record Fields . . . . . . . . . . . . . . . . 16 9.4. Prohibited Reporting Practices . . . . . . . . . . . . . 16 10. Federation and Multi-Node Evaluation . . . . . . . . . . . . 17 10.1. Federation Claims . . . . . . . . . . . . . . . . . . . 17 10.2. Operational Evidence . . . . . . . . . . . . . . . . . . 17 10.3. Independent Interoperability . . . . . . . . . . . . . . 17 10.4. Partition and Recovery . . . . . . . . . . . . . . . . . 17 11. Implementation Independence and Evaluation Boundary . . . . . 17 11.1. Architecture Independence . . . . . . . . . . . . . . . 17 11.2. Evidence Without Implementation Disclosure . . . . . . . 18 11.3. Separate Protocol Bindings . . . . . . . . . . . . . . . 18 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 12.1. KTS Global Reference Deployment . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13.1. Entity Substitution . . . . . . . . . . . . . . . . . . 19 13.2. Evidence Poisoning . . . . . . . . . . . . . . . . . . . 19 13.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.4. Unauthorized Inference . . . . . . . . . . . . . . . . . 20 13.5. Test-Harness Integrity . . . . . . . . . . . . . . . . . 20 13.6. Denial of Service . . . . . . . . . . . . . . . . . . . 20 13.7. Dependency Substitution . . . . . . . . . . . . . . . . 20 13.8. Conformance Record Integrity . . . . . . . . . . . . . . 20 14. Privacy and Governance Considerations . . . . . . . . . . . . 20 14.1. Personal and Sensitive Entities . . . . . . . . . . . . 20 14.2. Inferred Relationships . . . . . . . . . . . . . . . . . 20 14.3. Contestability . . . . . . . . . . . . . . . . . . . . . 21 14.4. Governance Authority . . . . . . . . . . . . . . . . . . 21 14.5. Data Minimization . . . . . . . . . . . . . . . . . . . 21 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . . . 21 Informative References . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Jacobs Expires 6 February 2027 [Page 3] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 1. Introduction Networked systems can identify, index, retrieve, and connect records describing entities. Those functions do not, by themselves, establish Machine Entity Comprehension as that term is defined in this document. A system may retrieve a record without preserving the identity of the underlying entity when descriptions change. It may associate records without distinguishing a durable relationship from superficial similarity. It may produce an answer without identifying whether that answer remains coherent after relevant evidence changes. This document defines MEC as a testable behavioral property rather than a claim about a particular internal architecture. A conforming system demonstrates that it can: * preserve stable entity identity across materially equivalent representations; * distinguish contextually similar but separate entities; * identify relevant relationships and constraints; * preserve outcomes under irrelevant variation; * update affected outcomes following material change; * identify and contain contradictory assertions; and * produce repeatable outcomes under equivalent declared conditions. This framework applies where entity-comprehension capabilities are exposed, coordinated, or evaluated across Internet-connected or Internet-capable systems. Common conformance semantics reduce ambiguity when heterogeneous systems declare capabilities, dependencies, operational-sovereignty conditions, and evaluation results. The term "Web4" is used as an architectural label for sovereign, entity-aware systems. It does not define a new Internet layer, transport protocol, replacement for the World Wide Web, or mandatory internal intelligence architecture. Conformance is determined through externally observable behavior. No implementation is required to disclose confidential implementation details to be evaluated under this document. Jacobs Expires 6 February 2027 [Page 4] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 2. Scope and Non-Goals 2.1. Scope This document specifies: * a bounded behavioral definition of MEC; * minimum operational-sovereignty requirements; * black-box conformance test profiles; * composite conformance classes; * multi-node consistency and disconnected-continuity tests; * minimum evidence, adjudication, and reporting requirements; * an implementation-neutral conformance-record structure; and * security, privacy, and governance considerations. 2.2. Non-Goals This document does not define an internal data model, state representation, implementation algorithm, reasoning process, software architecture, storage architecture, deployment architecture, confidential coordination method, proprietary implementation interface, transport protocol, URI scheme, media type, or IANA registry. It does not define consciousness, subjective experience, human- equivalent understanding, or general intelligence, and it does not claim that one internal architecture is necessary for conformance. Implementations MAY expose protocol bindings in separate documents. Such bindings are outside the scope of this framework. 3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Web4: Jacobs Expires 6 February 2027 [Page 5] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 An Internet-connected or Internet-capable environment in which software systems operate on entities, relationships, evidence, and state while preserving declared controls over identity, information movement, dependencies, and governance. This definition does not imply replacement of the existing Web or Internet protocol stack. Machine Entity Comprehension (MEC): The bounded behavioral capability defined in Section 4.1 and evaluated through the profiles in Section 7. Entity: A distinct real-world, digital, or conceptual subject that an implementation can identify and evaluate. Stable Entity Identifier: An identifier that persists across context changes and is not replaced solely because an entity's descriptive attributes change. Representation: A set of observations, claims, records, descriptions, or other inputs concerning an entity. Material Change: A change established by the pre-registered test plan as relevant to the tested identity, relationship, constraint, or outcome. Irrelevant Variation: A change established by the pre-registered test plan as not altering the conditions defining the tested identity, relationship, constraint, or outcome. Declared State: The externally recorded test conditions, implementation version, evidence set, policy profile, and dependency state under which an outcome is produced. Equivalent Test State: Node states containing the same versioned evidence, policy, and configuration required for an applicable test, as established through externally verifiable identifiers. Reference Outcome: The identity, distinction, relationship, change, contradiction, or result class established before system execution. Adjudication Record: Jacobs Expires 6 February 2027 [Page 6] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 The evidence and documented decision establishing why a reference outcome and its acceptance criteria are appropriate. Comprehension Outcome: An externally observable result concerning entity identity, distinction, relationship, constraint, state, or contradiction. Equivalent Outcome: Outcomes materially the same according to comparison rules fixed before execution. Acceptance Criteria: The pass, fail, and indeterminate rules established by the evaluator before controlled execution. External Intelligence Service: A separately controlled service that supplies model inference, reasoning, entity decisions, or another intelligence capability necessary to produce the declared core outcome. Infrastructure Service: A service such as transport, time synchronization, certificate validation, operating-system maintenance, or administrative monitoring that does not itself determine the tested comprehension outcome. Dependency Class: NONE, INFRASTRUCTURE-ONLY, EXTERNAL-EVIDENCE, EXTERNAL- INTELLIGENCE, or MIXED. Network Condition: CONNECTED, INTERNET-DISCONNECTED, LOCAL-NETWORK-ONLY, PRIVATE- FEDERATION-ONLY, or CUSTOM. A CUSTOM condition MUST be described. Withheld Test Status: FULLY-WITHHELD, PARTIALLY-WITHHELD, DISCLOSED, or NOT-APPLICABLE. Operational Sovereignty: The property that declared core capabilities remain under operator control and do not require an undeclared or unavailable external intelligence service. Node: An independently addressable deployment participant evaluated as part of a multi-node system. Independent Implementation: Jacobs Expires 6 February 2027 [Page 7] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 An implementation developed separately and not merely another instance or node of the same codebase. Evaluator: The party responsible for fixing the test plan, reference outcomes, adjudication records, and acceptance criteria before execution. 4. Machine Entity Comprehension Model 4.1. Behavioral Definition MEC is the externally observable ability of a system to identify an entity, distinguish it from contextually similar entities, determine relevant relationships and constraints, preserve identity across changing contexts, and produce coherent outcomes when entity state or surrounding evidence changes. A system MUST NOT be declared conformant solely because it retrieves a stored record, returns a similarity score, reproduces a cached answer, or passes one isolated test profile. Conformance establishes only the behavioral capabilities and claim class defined here. It does not establish consciousness, subjective experience, human-equivalent understanding, general intelligence, or use of a particular internal architecture. 4.2. Identity and Context A conforming implementation MUST maintain an externally observable distinction among stable entity identity, descriptions, context- dependent attributes, claims, and relationships. The implementation MAY use any internal mechanism to maintain these distinctions. 4.3. Relationships and Constraints A relationship outcome MUST identify the entities and declared context to which it applies. Where a tested relationship depends on material conditions, the evaluation MUST determine whether changing those conditions changes the outcome according to the pre-registered reference outcome. Jacobs Expires 6 February 2027 [Page 8] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 4.4. Contradictory Assertions A conforming system MUST be capable of representing or reporting materially contradictory assertions without silently merging them into a single uncontested fact. If the implementation selects a preferred outcome, the result MUST identify that a material contradiction was present. 4.5. Repeatability Equivalent authorized requests under equivalent declared states MUST produce equivalent outcomes within acceptance criteria established before execution. For a nondeterministic implementation, the evaluator MUST pre- register the source of permitted variation, number of repetitions, statistical method, and acceptance threshold. The operator MUST NOT alter acceptance criteria after receiving withheld inputs or observing preliminary outcomes. 5. Sovereignty Requirements 5.1. Dependency Declaration An implementation claiming operational sovereignty MUST publish a machine-readable or human-readable dependency declaration for the tested configuration. It MUST identify external intelligence, storage, retrieval, and infrastructure services; whether information leaves the declared test boundary; expected disconnected behavior; and unavailable disconnected functions. A confirmed external intelligence dependency required to produce the outcome but absent from the declaration invalidates the operational- sovereignty result for that test. A declared infrastructure service does not by itself invalidate sovereignty if it does not determine the tested outcome. 5.2. Operator Control The operator MUST be able to authorize and revoke access, stop the tested system, determine where test information is stored, identify dependencies, preserve the audit record, and determine whether an outcome was produced locally or with external intelligence assistance. Jacobs Expires 6 February 2027 [Page 9] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 5.3. Disconnected Core Operation If disconnected continuity is claimed, the implementation MUST retain its declared core capability after removal of connectivity to services outside the declared test boundary for the declared duration and scope. Connectivity among nodes inside the boundary MAY remain available if declared before execution. A bounded claim MUST identify entity scope, evidence scope, duration, excluded functions, and network condition. 5.4. Information Movement During a sovereignty test, the evaluator MUST monitor inbound and outbound network activity at the declared boundary. The report MUST distinguish test-harness transport, administrative monitoring, infrastructure services, external evidence access, and external intelligence services. 6. External Conformance Requirements 6.1. Pre-Registered Test Plan Before controlled execution, each test MUST define and preserve the test identifier, input evidence or integrity reference, expected conditions, reference outcome, adjudication record, adjudicator, dependencies, initial state, applied changes, acceptance criteria, comparison tolerance, repetitions, withheld status, and retained evidence. An integrity reference for the complete plan, outcomes, adjudication records, and acceptance criteria MUST be associated with a verifiable timestamp before execution. The operator MUST NOT unilaterally alter acceptance criteria after receiving inputs or observing outcomes. 6.2. Protected Evaluation Boundary Conformance MUST be determined without requiring source code, confidential implementation details, proprietary algorithms, protected deployment information, or trade-secret operational methods. An evaluator MAY require signed measurements, controlled execution, network observation, independent witnessing, or trusted execution attestations. Jacobs Expires 6 February 2027 [Page 10] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 6.3. Withheld and Negative Controls At least one test set used for an independent claim SHOULD be withheld until controlled evaluation begins. The report MUST state whether the operator, development team, or implementation had prior access to test cases or reference outcomes. Evaluation SHOULD include newly constructed cases where practical and negative controls designed to detect exact-text matching, answer caching, superficial name matching, uncontrolled external retrieval, and indiscriminate response to irrelevant variation. 6.4. Audit Record The evaluator MUST retain test identifiers, UTC times, evaluator and adjudicator identities, implementation and configuration identifiers, integrity references, declared dependencies, applicable node identifiers, observable outcomes, result status, and deviations from the plan. Confidential internal telemetry is not required. 7. Conformance Test Profiles 7.1. MEC-1: Identity Persistence *Purpose:* Determine whether identity is preserved across materially equivalent representations. 1. Present an entity using an initial representation. 2. Record its stable identifier. 3. Present pre-registered non-material variations. 4. Present a separate control entity with similar surface attributes. *Pass:* Identity remains stable across equivalent variations, permitted contextual attributes may change, and the control entity is not merged. 7.2. MEC-2: Entity Disambiguation *Purpose:* Determine whether similar but separate entities remain distinct. 1. Present at least two entities with overlapping surface attributes. Jacobs Expires 6 February 2027 [Page 11] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 2. Provide distinguishing evidence or context. 3. Submit references requiring correct resolution. *Pass:* References resolve correctly, entities are not merged solely because of similarity, and insufficient evidence produces an ambiguity result. 7.3. MEC-3: Relationship Invariance *Purpose:* Determine whether a relationship remains stable under irrelevant variation. 1. Establish a relationship and defining conditions. 2. Record the baseline. 3. Apply pre-registered irrelevant variations. 4. Repeat evaluation. *Pass:* The material relationship remains equivalent and changed contextual attributes remain distinguishable. 7.4. MEC-4: Material Change Response *Purpose:* Determine whether an outcome changes appropriately after a relevant condition changes. 1. Establish a baseline outcome. 2. Introduce a pre-registered material change. 3. Repeat evaluation. 4. Evaluate unaffected controls. *Pass:* The affected outcome changes according to the reference outcome, identity is preserved unless invalidation is tested, and unaffected controls remain materially unchanged. 7.5. MEC-5: Contradiction Handling *Purpose:* Determine whether contradictory assertions are detected and contained. 1. Present an initial evidence set. Jacobs Expires 6 February 2027 [Page 12] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 2. Record the baseline. 3. Introduce a materially contradictory assertion with identifiable provenance. 4. Repeat evaluation. *Pass:* The contradiction is observable, assertions remain distinguishable, unaffected relationships remain intact, and equivalent repetitions produce equivalent results. 7.6. MEC-6: Multi-Node Outcome Equivalence *Purpose:* Determine whether nodes holding equivalent test state produce equivalent outcomes. 1. Select eligible nodes. 2. Record externally verifiable state and version identifiers. 3. Establish equivalent test state. 4. Submit equivalent authorized requests. 5. Compare outcomes under pre-registered rules. *Pass:* Stable identities and material relationships are equivalent, authorized differences are identified, and stale or unavailable state is explicitly reported. 7.7. MEC-7: Disconnected Continuity *Purpose:* Determine whether a sovereign deployment retains declared core capability without external intelligence services. 1. Record dependencies, the test boundary, and baseline network activity. 2. Establish bounded scope. 3. Remove connectivity outside the declared boundary. 4. Execute applicable MEC-1 through MEC-5 tests. 5. Record network activity. 6. Restore connectivity and evaluate reconciliation if claimed. Jacobs Expires 6 February 2027 [Page 13] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 *Pass:* Declared capability remains available, no undeclared external intelligence produces the outcome, local state remains auditable, and reconciliation follows declared policy. The report MUST identify the applicable execution boundary. 7.8. MEC-8: Repeatability *Purpose:* Determine whether equivalent requests under equivalent states produce equivalent outcomes. 1. Select cases from MEC-1 through MEC-7. 2. Execute each a pre-registered number of times. 3. Reset or preserve state according to the plan. 4. Compare outcomes under pre-registered criteria. *Pass:* Deterministic implementations produce equivalent outcomes, nondeterministic implementations satisfy pre-registered statistical criteria, and divergence is attributable to declared state change. 7.9. MEC-9: Retrieval-Baseline Differentiation *Purpose:* Determine whether behavior differs from a declared retrieval-only or similarity-only baseline. 1. Select cases from MEC-1 through MEC-5. 2. Execute them against the evaluated implementation. 3. Execute equivalent cases against at least one declared baseline. 4. Compare outcomes under pre-registered metrics. Results are DIFFERENTIATED, NOT-DIFFERENTIATED, or INDETERMINATE. A superiority claim MUST pre-register its metric, direction, minimum effect threshold, case count, and statistical rule, and MUST remain limited to tested conditions. 8. Conformance Classes An implementation MUST NOT claim comprehensive MEC conformance based on one profile. Claims MUST identify a class and list profiles not tested or not passed. MEC Identity Conformance: Jacobs Expires 6 February 2027 [Page 14] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 MEC-1 and MEC-2. MEC Structural Conformance: MEC-1 through MEC-5. MEC Repeatable Conformance: MEC-1 through MEC-5 and MEC-8. MEC Federated Conformance: MEC-1 through MEC-6 and MEC-8. MEC Sovereign Conformance: MEC-1 through MEC-5, MEC-7, and MEC-8. MEC Comprehensive Profile Conformance: MEC-1 through MEC-8 under one declared evaluation scope. MEC-9 is RECOMMENDED for claims of behavior different from or superior to conventional retrieval or entity-resolution baselines. 8.1. Independent Verification Label A result MAY be described as independently verified only if the evaluator is organizationally independent, controls acceptance criteria, protects withheld cases, reports deviations and unsuccessful cases, can examine evidence integrity, and discloses material relationships with the operator. Where operator and evaluator are the same party, results MUST be labeled "self-evaluated" and MUST NOT be described as independently verified. 9. Result Reporting 9.1. Required Report Fields A conformance report MUST identify the report and framework version; evaluator, adjudicator, operator, and implementation; implementation version and hardware class; profiles and class claimed; cases and repetitions; dependencies and network condition; test boundary and withheld status; case results and deviations; capability boundaries; and integrity references. 9.2. Minimum Conformance Record A report MUST be capable of representing the following abstract record: Jacobs Expires 6 February 2027 [Page 15] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 MEC-Conformance-Record = { framework_version, report_id, evaluator_id, adjudicator_id, operator_id, implementation_id, implementation_version, conformance_class, profile_ids, execution_start, execution_end, dependency_class, network_condition, test_boundary, withheld_test_status, result_class, test_plan_integrity_reference, adjudication_record_reference, evidence_integrity_reference } This is an abstract information model. It does not mandate an encoding, register a media type, expose an intelligence request interface, or define an internal entity representation. 9.3. Conformance Record Fields All fields are REQUIRED. Identifiers MUST be unique or collision- resistant within their declared scope. Execution times MUST be UTC timestamps. The implementation version MUST be a version, build identifier, or integrity reference. The profile set MUST be non- empty. The conformance class MUST be a class defined here or NO- CLASS. The result class MUST be PASS, FAIL, INDETERMINATE, NOT-TESTED, DIFFERENTIATED, or NOT-DIFFERENTIATED, as applicable. Integrity references MUST identify the pre-registered test plan, adjudication record, and retained evidence. 9.4. Prohibited Reporting Practices A report MUST NOT misrepresent self-evaluation as independent verification, treat nodes of one codebase as independent implementations, omit unsuccessful cases, claim disconnected continuity without boundary observation, alter acceptance criteria after execution begins, infer a proprietary mechanism solely from external conformance, or represent a result as applicable beyond its Jacobs Expires 6 February 2027 [Page 16] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 tested scope. 10. Federation and Multi-Node Evaluation 10.1. Federation Claims A federation claim MUST identify participating and tested node counts, whether nodes share one implementation, the declared consistency model, and conditions under which nodes may legitimately differ. A report is not required to disclose confidential node arrangements, routing information, coordination methods, or node functions. 10.2. Operational Evidence Operational evidence MAY include signed node attestations, time- bounded status records, test transcripts, or other integrity- protected artifacts. A node count establishes deployment scale but does not by itself establish independent interoperability. 10.3. Independent Interoperability Independent interoperability requires at least two independently developed implementations to exchange or compare outcomes through a declared public binding or common test harness. Nodes running one implementation MUST NOT be reported as independent implementations. 10.4. Partition and Recovery Where partition tolerance is claimed, the evaluator SHOULD test outcome availability, identification of stale or bounded state, preservation of audit records, reconciliation after recovery, and containment of conflicting changes. The report MUST describe observable behavior without requiring confidential recovery methods. 11. Implementation Independence and Evaluation Boundary 11.1. Architecture Independence This framework standardizes observable requirements, evaluation semantics, conformance classes, and reporting fields. It does not standardize the internal mechanism used to produce an outcome. Proprietary and open implementations remain eligible. Jacobs Expires 6 February 2027 [Page 17] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 11.2. Evidence Without Implementation Disclosure Conformance MAY be demonstrated through black-box testing, independent observation, boundary monitoring, cryptographic integrity references, time-stamped audit artifacts, and witnessed execution. Publication of confidential implementation details, source code, proprietary algorithms, protected deployment information, or trade- secret methods is not required. 11.3. Separate Protocol Bindings A future document MAY specify an interoperable request, response, or report binding. Such a document SHOULD use opaque stable identifiers and extensible result envelopes and SHOULD NOT require a particular internal architecture. 12. Implementation Status This section records a known implementation informing the framework at the time of posting and follows the approach described in [RFC7942]. It may be updated during development and removed before RFC publication. 12.1. KTS Global Reference Deployment Implementation: KTS Global reference deployment. Operator: KTS Global, Dubai, United Arab Emirates. Maturity: Operational reference deployment. Operational chronology: Operational since 26 January 2026 according to the operator's preserved records. Deployment scale: Twenty-one participating nodes as of 5 August 2026 according to the operator's deployment record. Supporting public field record: The operator-published field record is available at https://geometricintelligence.ai/. It records 26 January 2026 as the beginning of production operation and identifies Tim Jacobs as developer and KTS Global as operator. Jacobs Expires 6 February 2027 [Page 18] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 Evidence classification: The cited record is first-party evidence and does not constitute independent verification or independent interoperability certification. Relationship to this draft: The operational system predates this document. Implementation experience informed its behavioral requirements and test profiles. Formal evaluation against this revision is pending. Candidate evaluation scope: MEC-1 through MEC-8. No conformance result is claimed until controlled evaluations have been executed and reported. Implementation licensing: Proprietary. No implementation license is specified here. Licensing enquiries should be directed to the operator. Interoperability status: Multi-node operation has been reported within the KTS deployment. Independent cross-implementation interoperability has not been established. Disclosure boundary: Proprietary implementation details, confidential deployment information, and protected operational methods are outside scope. Last updated: 5 August 2026. Contact: Tim Jacobs, KTS Global, tim@ktsglobal.live. 13. Security Considerations 13.1. Entity Substitution Implementations MUST authenticate protected updates and SHOULD preserve provenance sufficient to investigate attempted entity substitution or merging. 13.2. Evidence Poisoning Implementations SHOULD preserve source identity, acquisition time, integrity information, and policy decisions relevant to accepted evidence. Jacobs Expires 6 February 2027 [Page 19] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 13.3. Replay Implementations SHOULD use timestamps, nonces, version identifiers, or equivalent controls where replay would affect an outcome. 13.4. Unauthorized Inference Implementations MUST apply authorization to relationship-resolution outputs and contradiction reports, not only to raw records. 13.5. Test-Harness Integrity Reports SHOULD include integrity-protected test plans, input references, execution records, and evaluator identity. 13.6. Denial of Service Implementations SHOULD enforce bounded input size, execution time, concurrency, and authorization appropriate to the deployment. 13.7. Dependency Substitution Boundary monitoring and dependency declarations are REQUIRED for disconnected-continuity evaluation. 13.8. Conformance Record Integrity Published records SHOULD be integrity-protected and identify the evaluator, implementation version, execution interval, and evidence reference. 14. Privacy and Governance Considerations 14.1. Personal and Sensitive Entities Deployments are responsible for identifying and following privacy and data-governance obligations applicable to their evaluation and operating jurisdictions. 14.2. Inferred Relationships Implementations SHOULD support controls governing who may request, receive, retain, and redistribute relationship outcomes. Jacobs Expires 6 February 2027 [Page 20] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 14.3. Contestability Where outcomes materially affect a person or organization, deployments SHOULD provide a process to identify the evidence scope, register a correction or dispute, preserve the original audit record, distinguish correction from deletion, and record resulting state change. 14.4. Governance Authority A deployment claiming governance sovereignty MUST identify the entity authorized to control access, policy, updates, suspension, and termination for the evaluated system. 14.5. Data Minimization Test corpora SHOULD use synthetic or appropriately authorized data where real personal information is unnecessary. Published reports SHOULD avoid revealing private entity relationships, protected evidence, or confidential deployment information. 15. IANA Considerations This document has no IANA actions. Acknowledgements The author acknowledges the KTS Global engineering team involved in operating and maintaining the reference deployment. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Informative References [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, . Jacobs Expires 6 February 2027 [Page 21] Internet-Draft Web4 Sovereign Entity Comprehension August 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, . Author's Address Tim Jacobs KTS Global United Arab Emirates Email: tim@ktsglobal.live URI: https://ktsglobal.live/ Jacobs Expires 6 February 2027 [Page 22]