Verify by DSEO Marketing
EN ES
Architecture

Simple, then technical.

Read the diagram in plain language first. The technical layer beneath it names the same boxes the source material does, and nothing is exposed here that would read as an exploit recipe.

01 Simple 
EXTERNAL ROOTS / PINS
              │
      VERIFICATION ADAPTERS         (signatures, attestation formats — future)
              │
      MASTER FRONT ASSURANCE KERNEL (the small core that decides)
              │
      ASSESSMENT RESULT             (record_valid / security_status / release_authority=false)
              │
      EXTERNAL RELYING PARTY        (someone else, deciding)
              │
      OPTIONAL EFFECT PATH          (often: nothing happens)
02 Technical

What is inside the reference kernel

  • Canonicalisation (MF-CANON-1): strict JSON, NFC-normalised keys, no floats, no non-finite values.
  • Hashing and pin comparison against externally supplied digests.
  • Authority–policy binding: authority must reference the exact policy consumed.
  • A finite evidence graph: five relations, no code, no arbitrary operations.
  • Run binding and staleness/time checks against declared windows.
  • Conflict and completeness evaluation under the policy's declared mode.
  • One-use consistency for permits and their consumption records.
  • Property and result aggregation into record_valid / security_assessment_status.

What is deliberately outside it

  • Filesystem, network, subprocess and ambient clock access.
  • Concrete signature or COSE/DSSE verification.
  • A transparency service or durable external anchor.
  • The Secure Execution Gate — a separate reference component, not reachable from this website or its CLI.

The part that could change something on a machine is a separate component from the part that decides. They are not the same trusted base.

V Verified against source bytes Where this comes from
Source file
03_ARCHITECTURE/00-ARCHITECTURE-OVERVIEW.md
Section
3. Qué está deliberadamente fuera
File digest
78c19b5bae12a001f385a6f2d1afb22ed507f72d019f806beebf73a466e01c8c
Verbatim quote
secure runner/effect gate **dentro del kernel**

The gate lives in 11_SECURE_EXECUTION_GATE as a separate TCB. This website never invokes it.

How far the gate’s sandboxing actually reaches is a limit rather than a structure, and is recorded on Status & limits.

03 Trusted bootstrap, at the appropriate depth

Before any candidate code runs, an external bootstrap verifies the candidate ZIP's SHA-256, checks manifest and content-root, and only then imports the kernel from sealed, verified bytes. This website goes no deeper than that — the same adapter discipline this site's own CLI uses, at a smaller scale, to bind its kernel import to a digest before trusting it.

04 The mechanism

How the core reaches a result.

How this works

  1. 01

    The record is canonicalised

    Strict JSON, normalised keys, no floats, no ambiguous values. Two records that mean the same thing must reduce to the same bytes, or a digest proves nothing.

  2. 02

    Identity is compared against pins supplied from outside

    The core checks the record, policy, authority and artifact against digests the caller committed to in advance. It never invents an identity.

  3. 03

    The evidence graph is validated, then reasoned over

    Endpoints must exist, duplicates are refused, and a rule may only consume evidence it declared. Evidence from another run cannot be borrowed.

  4. 04

    Finite rules produce properties, properties aggregate to a result

    A small fixed set of operations — no submitted code is ever executed — yields the three axes and, always, release_authority: false.