Technical Verification

Designed to be inspected, not trusted by claim.

MAX is built around a simple principle: important actions should leave technical evidence that can be inspected. Identity, signatures, hashes, public keys, signed manifests, device roles and node reports are objects that can be checked, compared and reviewed by technically competent people.

What verification means in MAX

MAX does not ask for blind trust. When an element is important, it should produce a technical object that can be inspected.

Concrete objects, not vague claims

It is not enough to say that an identity exists: there should be a MAX ID. It is not enough to say that a content was signed: there should be a verifiable signature. It is not enough to say that an IoT manifest was approved: there should be an identifiable signed manifest linked to an approval flow.

For devices, the same logic applies. A node should not be considered correctly configured only because it received a command. Its identity, role, applied manifest section, authorized peers and resulting report should make the state of the node observable.

Technical note

Verification does not replace audit. Verification makes audit possible. A system that produces readable evidence can be checked, tested and improved.

MAX ID and identity verification

A MAX ID is not a username, a password or a value assigned by a central account server.

The public root of identity

In the MAX model, the MAX ID is the public verifiable root of a locally generated identity. In practice, it coincides with the final Merkle root built from hashes generated during the local identity process.

For a person, it is connected to the local identity inside MAX App. For a device, it becomes the way to distinguish one machine from another inside MAX IoT.

The point is not only to know who someone or something is. The point is to connect that identity to signatures, public keys, authorizations, roles and verifiable actions.

Signatures, public keys and hashes

The basic verification layer is built from technical objects that can be checked.

Sig

Signatures

SPHINCS+

Signatures connect a content, request, manifest or authorization to an identity. In the current MAX model, SPHINCS+ is used for post-quantum signatures and verification.

Public verification

Public keys

A signature matters only if it can be verified. Public keys allow a verifier to check that a signature corresponds to a specific identity and a specific content.

Fingerprints

Hashes

Hashes identify contents, payloads, files or manifests through verifiable fingerprints. If the content changes, the hash changes as well.

Verification in MAX App

In MAX App, verification mainly concerns the human side of the ecosystem: local identity, signing, protected content, login and encrypted communication.

What a technician can inspect

MAX App can be evaluated by looking at how the MAX ID is represented, which contents are signed, which public keys verify signatures, which hashes identify data or payloads and how local identity connects to signature, vault, login and chat.

MAX App verification

MAX App should not be read as a simple password app or a simple encrypted chat. It is an environment where identity, signature, local protection, access and communication are connected inside a verification-oriented model.

Verification in MAX IoT

In MAX IoT, verification concerns the machine side of the ecosystem. A device should not act only because it receives a command.

Device identity

Machine identity

Each node can be distinguished through its own device identity and public verification material.

Signed manifest

Fleet rules

The Fleet Manifest defines devices, roles, peers, operators and rules for the fleet.

Reports

Observable node states

Reports and observable states show what a node has received, applied or failed to apply.

Device behavior from identity and rules

A device should act because its identity, role and signed rules authorize it to do so. The Raspberry Pi prototype is not the final product: it is the technical proof that machine identity, roles, signed manifests, controlled communication and reports can run on real devices.

Known components and MAX-specific architecture

MAX must be evaluated by separating what it uses from what it organizes. Known components are not presented as MAX inventions.

Known or studied components

MAX uses known cryptographic and technical components with different roles: signatures, post-quantum key encapsulation, authenticated encryption, derivation, fingerprints and public verification.

SPHINCS+ FrodoKEM XChaCha20-Poly1305 Argon2id HKDF hashes public keys digital signatures MAX ID / Merkle root signed manifests challenge-response

MAX-specific elements

The MAX-specific part is the way these elements are connected: MAX ID model, deterministic identity architecture, continuity between people and machines, integration of identity, signature, vault, login, chat and IoT, device roles through Fleet Manifests, observable node states and verification-oriented ecosystem design.

Verifiable does not automatically mean secure

This distinction is essential. A verifiable system is not automatically a secure system. A verifiable system is a system that makes technical control possible.

Security also requires correct implementation, code review, realistic testing, device protection, server-side security, operational hardening and independent audit. MAX should not be described as unbreakable. It should be described as designed to be analyzed.

What still requires audit

MAX already works in important parts, but it is not yet a third-party audited or industrially certified product.

App and cryptographic flows

External validation should review cryptographic implementation, local key generation, temporary in-memory use of keys, publication and verification of public keys, coherence between MAX ID, public keys and signatures, MAX App, MAX Login and MAX Chat flows.

IoT and operational hardening

External validation should also review backend security, MAX IoT provisioning and manifests, node behavior in edge cases, scalability and recovery, installable packaging, UX security and operational hardening.

Why this page exists

Technical Verification exists to make one point clear: MAX should not be trusted only because it claims to be secure. MAX should be read, checked, verified and improved.

The value is not in saying “trust me”. The value is in producing identities, signatures, hashes, manifests, roles and reports that can be analyzed by people with technical competence.