Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework
draft-jacobs-web4-sovereign-entity-comprehension-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tim Jacobs | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jacobs-web4-sovereign-entity-comprehension-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc5378>.
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,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
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]