OmnimeshUK-developedDiscuss a requirement

04 / Evidence and evaluation

Design intent is not demonstrated assurance

Omnimesh is at the specification gate: system architecture and protocol specifications are being finalised before further MVP implementation. Controlled evaluation comes later, against separately defined methods, criteria and limitations.

Discuss a scoped requirement Review the platform

Public evidence register

What is public—and what each next claim requires

Every entry names its evidence class, supporting artefact and the gate that separates the current state from a stronger claim.

  1. 01

    Finalising

    Architecture specification

    System boundaries, dependencies and operational assumptions are being resolved.

  2. 02

    Finalising

    Protocol specification

    Protocol behaviour and testable requirements are being specified.

  3. 03

    Next phase

    MVP implementation

    Further implementation continues after the specification gate.

  4. 04

    Future gate

    Controlled evaluation

    Scope, methods, criteria and limitations must be defined before evaluation.

Item and evidence classStatusSupporting artefactEvidence gate

Public system boundary

Public architecture statement

StatusPublished · Version 0.1

Supporting artefactPublic System Boundary and Terminology

Evidence gateFreeze the versioned architecture rationale, dependencies and unresolved decisions before treating it as implementation input.

Transport-exposure analysis

Source-linked framework analysis

StatusPublished

Supporting artefactTransport-Layer Gaps in Your CAF Assessment

Evidence gateEnvironment-specific threat modelling and measurement are required before the analysis can support a product-efficacy claim.

Protocol specification

Specification

StatusFinalising

Supporting artefactNo public protocol specification

Evidence gateA versioned protocol, security assumptions and conformance plan are required before implementation claims can be assessed.

MVP implementation

Implementation evidence

StatusNext phase

Supporting artefactNo current public implementation artefact

Evidence gateAn identified build and scoped conformance, fuzzing, impairment and performance outputs are required.

Controlled evaluation

Evaluation method

StatusFuture gate

Supporting artefactNo formal assessment service offered

Evidence gateScope, eligibility, methods, criteria, outputs, limitations and data handling must be defined first.

Future assessment path

A controlled assessment should support a clear next decision

An initial discussion can determine whether the transport-assurance question is relevant and identify the evidence required for a responsible next decision.

Illustrative only; Omnimesh does not currently offer a formal assessment service.

  1. 01

    Frame

    Define the scenario

    Identify protected environments, material outcomes, relevant adversaries and observable or concentrated dependencies.

    Decision point: scoped problem
  2. 02

    Map

    Review architectural fit

    Establish the current control stack, system boundaries, operational owners and questions that require deeper evidence.

    Decision point: architectural relevance
  3. 03

    Plan

    Agree the evidence path

    Define what would be reviewed or tested, success and stop criteria, limitations and safe handling requirements.

    Decision point: evidence required
  4. 04

    Decide

    Choose the next action

    Stop, request targeted evidence or plan a deeper technical evaluation when maturity permits.

    Decision point: next action

First technical conversation

What the first discussion must establish

The first decision may be to stop. That is a valid outcome when scope, maturity or available evidence is insufficient.

Establish

  • A specific threat and assurance requirement.
  • A clear separation between facts, assumptions and design objectives.
  • The evidence needed for the next decision.
  • Scope, exclusions and data-handling boundaries.
  • Permission for either party to conclude that Omnimesh is not yet suitable.

Exclude

  • Classified or operationally sensitive material sent by general email.
  • A production trial before scope and maturity are confirmed.
  • Organisational certification presented as product assurance.
  • Adversary-resistance claims without defined criteria.
  • Government, defence or CNI focus presented as endorsement.

Assurance language

Assurance begins where evidence can be examined

Security terms only become assurance claims when their scope, criteria and limitations are explicit.

Claims relating to anonymity, metadata protection, post-quantum security, sovereign assurance, nation-state resistance, defence readiness or critical-infrastructure suitability require defined test conditions and supporting artefacts.

Until then, Omnimesh describes them only as design objectives or research directions.