Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework

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.¶

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.¶

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.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.¶

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.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.¶

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.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.¶

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.¶

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.¶

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.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.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:¶

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 tested scope.¶

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.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.¶

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.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.¶

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.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.¶

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.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.¶

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.¶