#Originblok® White Paper

#The Nebula Framework™ — Scientific Edition v1.0

---

#Convenciones científicas, criptográficas y normativas

Originblok® designa la Trust Infrastructure de The Nebula Framework™ encargada de preservar identidad, procedencia, integridad verificable y continuidad temporal para Evidence, transformaciones, Scientific Models y Knowledge Claims. Su propósito no consiste en declarar que un registro es verdadero por haber sido firmado, sellado o incorporado a un ledger. Su propósito consiste en permitir que una afirmación pueda ser examinada mediante una cadena explícita de objetos, actores, actividades, controles y pruebas.

En este documento, integridad significa que una modificación posterior de un objeto o de su representación puede ser detectada bajo los supuestos del mecanismo utilizado. Autenticidad significa que existe Evidence verificable de que un actor controlaba una identidad o clave al producir una firma o declaración. Procedencia describe cómo una entidad fue generada, utilizada, transformada o atribuida. Trazabilidad describe la capacidad de reconstruir historia, ubicación, transformación o relación de un objeto dentro de un alcance definido. Confianza designa una decisión contextual de aceptar una afirmación para un propósito determinado; no constituye una propiedad intrínseca de un hash, una firma, una credencial o una blockchain.

Proof of Process™ designa un paquete verificable de Evidence que permite evaluar una afirmación sobre la ejecución y evolución de un proceso. No equivale a Proof of Work, Proof of Stake ni a otro mecanismo de consenso de redes distribuidas. Tampoco equivale a una certificación automática. Un Proof of Process™ puede apoyar una certificación, una auditoría, una investigación o una transacción, pero la autoridad y el criterio de aceptación pertenecen a Governance.

Una Observation es el resultado contextualizado de un acto de medición, muestreo, inspección o percepción. Una Inference es una proposición derivada mediante Scientific Model, cálculo, regla o interpretación. Una Knowledge Claim es una afirmación identificable cuyo alcance, Evidence y estado epistemológico pueden evaluarse. Originblok® DEBE preservar estas diferencias y NO DEBE presentar una Inference como Observation ni una declaración firmada como hecho material demostrado.

Las expresiones DEBE, DEBERÁ y NO DEBE indican requisitos de conformidad conceptual. DEBERÍA indica una práctica preferente que admite excepciones justificadas. PUEDE indica una alternativa permitida.

El estado Draft refleja que este documento formula una arquitectura científica y tecnológica susceptible de validación, refutación y evolución mediante The Nebula RFC™.

---

#Prólogo

La trazabilidad moderna ha permitido reconstruir movimientos, custodias y transformaciones en cadenas de suministro. Sin embargo, saber que un lote pasó por una instalación determinada no demuestra, por sí solo, qué ocurrió dentro del proceso, qué condiciones fueron observadas, qué instrumentos se utilizaron, qué incertidumbre acompañó a las mediciones ni qué parte del relato fue inferida posteriormente.

Esta limitación resulta especialmente importante en procesos biológicos. Una fermentación no queda científicamente descrita mediante un evento de inicio y otro de finalización. Entre ambos existen estados, cambios de régimen, intervenciones, muestras, fallos, decisiones e intervalos no observados. La historia material es más rica que la historia logística.

Los sistemas de registro suelen resolver solo una parte del problema. Una base de datos puede conservar valores, pero no necesariamente su procedencia. Una firma digital puede autenticar al firmante, pero no demostrar que el instrumento estaba calibrado. Un sello temporal puede acreditar que un digest existía antes de un instante, pero no que el objeto representado era exacto. Una blockchain puede volver un registro tamper-evident dentro de sus reglas de consenso, pero no impedir que datos falsos ingresen desde el mundo físico.

Originblok® surge de esta separación entre integridad de representación y validez del conocimiento.

La infraestructura se diseña para responder preguntas más exigentes que “¿dónde estuvo el producto?”: ¿qué entidad fue observada?, ¿quién realizó la Observation?, ¿qué procedimiento se aplicó?, ¿cómo se relaciona el resultado con la Biological Trajectory?, ¿qué transformaciones ocurrieron?, ¿qué Scientific Model produjo una Inference?, ¿qué Evidence contradice el claim?, ¿qué versión era válida cuando se tomó una decisión?

El objetivo no es eliminar la necesidad de confianza humana o institucional. Es cambiar su forma. En lugar de depender únicamente de reputación, autoridad o acceso privilegiado a sistemas, la confianza puede apoyarse en Evidence resoluble, contratos semánticos, identidades, firmas, auditoría y Governance.

Este enfoque exige modestia. La criptografía puede proteger objetos digitales y relaciones entre ellos; no observa directamente el mundo. Los oráculos, sensores, operadores, laboratorios y procesos de muestreo continúan siendo puntos críticos. Por ello, Originblok® debe construirse como Trust Infrastructure científica y no como una narrativa de “verdad inmutable”.

---

#Resumen Ejecutivo

Originblok® es la infraestructura de confianza, identidad, procedencia y trazabilidad verificable de The Nebula Framework™. Su misión es transformar Evidence distribuida sobre Biological Processes en paquetes de Proof of Process™ que puedan ser examinados por personas y sistemas independientes.

El paradigma parte de una tesis central:

La confianza sobre una transformación puede fortalecerse cuando las afirmaciones se vinculan con Evidence identificable, contextualizada, íntegra, temporalmente situada y verificable mediante mecanismos independientes.

Esta tesis es condicional. La integridad criptográfica no demuestra exactitud material; la procedencia no demuestra competencia; la repetición de un claim no demuestra su verdad. Originblok® solo puede fortalecer confianza cuando sus objetos de entrada, políticas, identidades, modelos y mecanismos de verificación son adecuados para el Context of Use.

La infraestructura organiza cinco funciones complementarias:

1. Identity, para reconocer materiales, lotes, muestras, instrumentos, agentes, organizaciones, Scientific Models y Knowledge Objects.
2. Provenance, para representar cómo esos objetos fueron generados, utilizados, transformados y atribuidos.
3. Integrity, para detectar alteraciones mediante hashes, firmas, sellos temporales, estructuras de compromiso y registros verificables.
4. Evidence Assembly, para vincular Observations, eventos, contexto, modelos, auditorías y limitaciones con una afirmación concreta.
5. Verification, para permitir que un tercero evalúe el paquete sin depender de acceso irrestricto a la plataforma que lo emitió.

Proof of Process™ es el objeto de salida principal. Se define como un paquete versionado que contiene o resuelve identidad, alcance, Biological Trajectory, eventos, Observations, Evidence Artifacts, procedencia, Scientific Models, Inferences, declaraciones, firmas, sellos temporales, política, estado y limitaciones.

Originblok® NO DEBE registrar indiscriminadamente todos los datos en blockchain. La infraestructura adopta un principio de anclaje proporcional. Los artefactos originales pueden permanecer en repositorios gobernados; sus digests, manifestaciones o raíces de Merkle pueden anclarse en servicios de timestamping, transparency logs, ledgers institucionales o redes distribuidas cuando el modelo de amenaza lo justifique.

NIST describe las blockchains como ledgers distribuidos, tamper-evident y tamper-resistant bajo sus reglas de validación y consenso [7]. Esta propiedad puede ser útil cuando múltiples organizaciones necesitan una referencia compartida sin conceder control exclusivo a una sola parte. No obstante, una blockchain agrega complejidad, costos, exposición de metadatos, Governance de claves y dependencia de una red. Su adopción será una decisión arquitectónica, no un requisito constitucional de Originblok®.

La interoperabilidad se apoya en estándares existentes. ISO 22005:2007 establece principios y requisitos básicos para sistemas de trazabilidad en cadenas alimentarias [1]. GS1 EPCIS 2.0 permite crear y compartir visibility event data entre aplicaciones y empresas; incorpora dimensiones de evento, TransformationEvent, sensor data, JSON/JSON-LD y REST bindings [2]. W3C PROV-O proporciona un modelo para Entity, Activity, Agent y derivación [3]. W3C Verifiable Credentials Data Model 2.0 define un ecosistema de issuer, holder y verifier para claims verificables [4]. Verifiable Credential Data Integrity 1.0 define mecanismos criptográficos para autenticidad e integridad [5]. DID Core 1.0 ofrece identificadores verificables desacoplados de registros centralizados específicos [6].

Originblok® deberá alinear o extender estos estándares sin crear equivalencias falsas. Un EPCIS TransformationEvent puede representar una transformación logística o productiva, pero no contiene por sí solo toda la Evidence científica de una Biological Trajectory. Una Verifiable Credential puede transportar un claim firmado, pero el verifier deberá decidir si confía en el issuer, la política, la Evidence y el propósito.

La arquitectura conceptual consta de ocho planos: Capture, Identity, Evidence, Provenance, Integrity, Semantic, Verification y Governance. Los planos pueden implementarse en componentes distintos o combinarse en despliegues pequeños, siempre que sus responsabilidades se mantengan distinguibles.

La validación deberá demostrar que un tercero puede reconstruir la cadena desde un claim hasta sus Observations, verificar integridad y firmas, identificar versiones, reconocer huecos, detectar revocaciones y distinguir Evidence de Inference. La infraestructura será refutada o restringida si sus pruebas generan falsa certeza, si la complejidad no mejora auditoría o decisión, si la privacidad se degrada, si las identidades no representan correctamente el mundo material o si los actores territoriales pierden control legítimo sobre su información.

---

#1. Propósito y alcance

#1.1 Propósito

Originblok® existe para convertir trazabilidad declarativa en trazabilidad respaldada por Evidence.

Su propósito comprende:

• preservar identidad y genealogía;
• registrar procedencia;
• proteger integridad;
• establecer temporalidad verificable;
• vincular Evidence con Knowledge Claims;
• facilitar auditoría independiente;
• permitir selective disclosure;
• sostener Interoperability;
• conservar Temporal Evolution.

#1.2 Alcance

El alcance incluye eventos materiales, Observations, muestras, instrumentos, decisiones, Scientific Models, Inferences, credenciales, certificaciones y Knowledge Objects relacionados con Biological Processes.

Originblok® puede utilizarse en café, cacao, vino, ingredientes, bioprocesos industriales, investigación y transferencia tecnológica. Cada dominio deberá definir perfiles propios de Evidence y conformidad.

#1.3 Fuera de alcance

Originblok® no pretende:

• declarar una única fuente de verdad universal;
• reemplazar auditorías, laboratorios o revisión científica;
• convertir toda información en pública;
• imponer blockchain;
• certificar automáticamente calidad sensorial, inocuidad o sostenibilidad;
• eliminar disputas sobre identidad, derechos o interpretación;
• garantizar que un sensor represente correctamente el fenómeno.

#1.4 Context of Use

Cada despliegue deberá declarar qué claims pretende respaldar. Los requisitos para demostrar que un evento ocurrió son diferentes de los necesarios para afirmar calidad, origen, reducción de emisiones o cumplimiento regulatorio.

El principio canónico es:

No existe Proof of Process™ sin un claim, un alcance y un criterio de verificación definidos.

---

#2. El problema de la confianza en procesos biológicos

#2.1 Trazabilidad de hitos

Muchos sistemas registran recepción, transformación, despacho y entrega. Esta estructura responde a necesidades logísticas, pero representa el proceso mediante hitos separados. Los estados intermedios y sus Evidence pueden desaparecer.

ISO 22005:2007 define la trazabilidad como herramienta para determinar historia o ubicación de un producto o componentes dentro de objetivos definidos [1]. Originblok® se apoya en este fundamento y amplía la representación hacia Evidence científica y Biological Trajectory.

#2.2 Fragmentación de Evidence

Los datos pueden encontrarse en sensores, hojas de cálculo, sistemas de laboratorio, fotografías, correos y memoria humana. Sin identidad y procedencia comunes, la auditoría requiere reconciliaciones manuales y puede producir conclusiones inconsistentes.

#2.3 Oracle problem

Todo sistema digital que representa el mundo depende de mecanismos que introducen información: sensores, operadores, interfaces, laboratorios o integraciones. La criptografía puede demostrar que un mensaje no cambió después de ser firmado; no demuestra que el mensaje describía correctamente el mundo.

Originblok® tratará cada fuente como un componente sujeto a identidad, competencia, procedimiento, calibración y riesgo.

#2.4 Confusión entre integridad y verdad

Un registro inmutable puede preservar un error indefinidamente. Una firma puede autenticar a un actor que realizó una afirmación incorrecta. Un timestamp puede probar anterioridad sin probar calidad.

La Trust Infrastructure deberá comunicar explícitamente qué propiedades verifica y cuáles permanecen fuera de alcance.

#2.5 Asimetría de información

Los participantes no poseen el mismo acceso a la historia, los instrumentos ni los modelos. Proof of Process™ puede reducir esta asimetría al proporcionar Evidence portable y verificable, pero también puede crear nuevas dependencias si el verificador requiere servicios propietarios.

#2.6 Temporal Evolution

Los registros científicos necesitan corrección, revisión y refutación. La inmutabilidad no deberá impedir que un error sea corregido. La solución consiste en preservar el registro anterior y añadir una relación explícita de corrección, retractación, sustitución o revocación.

---

#3. Hipótesis y principios

#3.1 Hipótesis central

Una cadena de Evidence semánticamente estructurada y criptográficamente verificable puede reducir la incertidumbre sobre cómo se ejecutó un proceso, siempre que sus fuentes, identidades, procedimientos y limitaciones permanezcan auditables.

#3.2 Subhipótesis de procedencia

La procedencia explícita mejora la capacidad de evaluar una afirmación frente a registros sin lineage.

#3.3 Subhipótesis de portabilidad

Un paquete interoperable permite verificación independiente y reduce dependencia de un proveedor.

#3.4 Subhipótesis de granularidad

La inclusión de eventos y Observations intermedios puede explicar variaciones que la trazabilidad de hitos no conserva.

#3.5 Subhipótesis criptográfica

Hashes, firmas, sellos temporales y estructuras de compromiso pueden detectar alteraciones y atribuir declaraciones bajo supuestos controlados.

#3.6 Principios canónicos

#La Evidence precede a la confianza

La confianza operacional o comercial no deberá basarse únicamente en reputación o marca cuando exista Evidence relevante disponible.

#La trazabilidad debe ser verificable

Un tercero autorizado deberá poder reconstruir las relaciones esenciales sin depender de afirmaciones no documentadas del emisor.

#El contexto es inseparable del dato

La interpretación requiere entidad, tiempo, procedimiento, unidad, calidad y propósito.

#La integridad debe poder auditarse

Los mecanismos criptográficos, algoritmos, claves, versiones y políticas deberán ser identificables.

#Interoperability facilita adopción

Los objetos deberán poder exportarse y verificarse mediante estándares y herramientas independientes.

#La privacidad limita la exposición

Verificabilidad no significa revelar todas las Evidence. El sistema deberá soportar disclosure proporcional.

#La corrección no borra la historia

Los errores deberán corregirse mediante nuevas afirmaciones y relaciones, preservando la versión previa cuando exista interés científico o regulatorio.

mindmap
  root((Originblok®))
    Evidence
      Observation
      Sample
      Audit
      Scientific Model
    Trust
      Identity
      Integrity
      Provenance
      Governance
    Proof of Process™
      Claim
      Scope
      Verification
      Limitations
    Interoperability
      GS1 EPCIS
      W3C PROV
      Verifiable Credentials
      Open APIs

---

#4. Modelo conceptual de confianza

#4.1 Confianza como decisión contextual

La confianza se representa como una decisión:

aceptar(claim, propósito, política, Evidence, riesgo)

No se trata de una puntuación universal. Un claim puede ser suficiente para una operación de bajo riesgo e insuficiente para una certificación o intervención automática.

#4.2 Capas de confianza

Originblok® distingue:

• Identity Trust: confianza en la relación entre un identificador y una entidad.
• Source Trust: confianza en competencia, dispositivo, laboratorio u organización.
• Integrity Trust: confianza en que el objeto no fue modificado sin detección.
• Process Trust: confianza en que el procedimiento declarado fue ejecutado.
• Model Trust: confianza en que una Inference es adecuada para el Context of Use.
• Governance Trust: confianza en políticas, responsabilidades, auditoría y apelación.

#4.3 No transitividad automática

La confianza no deberá propagarse sin regla. Confiar en una organización no implica confiar en todos sus dispositivos, modelos o claims. W3C Verifiable Credentials 2.0 no define por sí misma qué issuers debe aceptar un verifier; esa decisión pertenece al trust model del ecosistema [4].

#4.4 Evidence favorable y adversa

Un Proof of Process™ deberá poder incluir Evidence que contradice o limita el claim. Excluir sistemáticamente resultados adversos degrada su valor científico.

#4.5 Assurance Levels

Los perfiles podrán definir niveles de assurance, pero deberán vincularse con requisitos verificables.

Ejemplo conceptual:

• A0: claim declarado sin Evidence verificada;
• A1: identidad y procedencia mínimas;
• A2: integridad, timestamps y Evidence contextualizada;
• A3: revisión independiente o corroboración;
• A4: replicación, certificación o auditoría bajo perfil formal.

Los niveles no deberán compararse entre dominios sin equivalencia demostrada.

---

#5. Objetos fundamentales

#5.1 Origin Entity

Entidad material o informacional que posee identidad gobernada: lote, muestra, reactor, instrumento, organización, Scientific Model o documento.

#5.2 Evidence Artifact

Objeto utilizado para evaluar un claim. Puede ser señal, Observation Result, certificado, registro de calibración, muestra, imagen, dataset, informe o Decision Record.

#5.3 Process Event

Ocurrencia delimitada que modifica estado, identidad, custodia, relación o interpretación.

#5.4 Provenance Activity

Actividad que genera, utiliza o transforma entidades. El perfil deberá alinearse con PROV-O, donde Entity, Activity y Agent proporcionan el núcleo de procedencia [3].

#5.5 Integrity Proof

Objeto criptográfico que permite verificar integridad o autenticidad bajo un mecanismo y clave determinados.

#5.6 Timestamp Evidence

Evidence que permite sostener que un digest existía antes o en un instante bajo una autoridad o ledger. RFC 3161 define un Time-Stamp Protocol donde una Time Stamping Authority emite tokens sobre la existencia temporal de un datum [10].

#5.7 Knowledge Claim

Afirmación identificable evaluada por Evidence. Ejemplos:

• “El lote fue fermentado dentro del rango declarado”.
• “La muestra deriva del lote identificado”.
• “La Inference fue generada por el modelo y versión registrados”.

#5.8 Verifiable Credential

Contenedor de claims emitido por un issuer, mantenido o presentado por un holder y evaluado por un verifier. W3C VC Data Model 2.0 proporciona el modelo extensible y considera seguridad, privacidad e internacionalización [4].

#5.9 Proof of Process Package

Objeto compuesto que agrega o resuelve los elementos necesarios para verificar un claim sobre proceso.

classDiagram
    class ProofOfProcessPackage {
        +packageId
        +version
        +claimScope
        +assuranceLevel
        +verificationPolicy
    }
    class KnowledgeClaim {
        +statement
        +contextOfUse
        +epistemicStatus
    }
    class EvidenceArtifact {
        +artifactId
        +artifactType
        +qualityStatus
    }
    class ProcessEvent {
        +eventType
        +eventTime
        +recordTime
    }
    class ProvenanceRecord {
        +activity
        +agent
        +derivation
    }
    class IntegrityProof {
        +proofType
        +verificationMethod
        +proofValue
    }
    class Credential {
        +issuer
        +holder
        +status
    }

    ProofOfProcessPackage "1" *-- "1..*" KnowledgeClaim
    ProofOfProcessPackage "1" *-- "1..*" EvidenceArtifact
    ProofOfProcessPackage "1" *-- "*" ProcessEvent
    ProofOfProcessPackage "1" *-- "1..*" ProvenanceRecord
    ProofOfProcessPackage "1" *-- "1..*" IntegrityProof
    ProofOfProcessPackage "1" o-- "*" Credential

---

#6. Proof of Process™

#6.1 Definición

Proof of Process™ es un paquete versionado y verificable que vincula una afirmación sobre un proceso con identidad, eventos, Observations, Evidence, procedencia, integridad, temporalidad, modelos, políticas y limitaciones.

#6.2 Propósito

Proof of Process™ existe para permitir que una afirmación sea examinada sin exigir acceso total al sistema que la produjo. Su utilidad depende de la capacidad del verifier para resolver objetos, validar firmas, comprobar estados y comprender semántica.

#6.3 Estructura conceptual

PoP = <C, S, I, T, E, P, M, R, G, L>

Donde:

• C: claim;
• S: scope;
• I: identity;
• T: temporal evidence;
• E: Evidence;
• P: provenance;
• M: Scientific Models e Inferences;
• R: integrity records;
• G: Governance y política;
• L: limitations.

#6.4 Claim Profile

Cada tipo de claim deberá tener un profile que defina:

• semántica;
• Evidence mínima;
• fuentes admitidas;
• nivel de assurance;
• reglas de validez;
• política de revocación;
• privacy requirements;
• criterios de refutación.

#6.5 Manifest

El package deberá poseer un manifest canónico con identificadores, digests, media types, tamaños, versiones, relaciones y método de canonicalization.

La canonicalization es crítica: dos serializaciones semánticamente equivalentes pueden producir bytes diferentes y, por tanto, hashes diferentes. El profile deberá especificar qué representación se firma.

#6.6 Evidence Graph

El package deberá representar las relaciones entre Evidence y claims, no solo incluir archivos. Un certificado puede respaldar calibración; una Observation puede respaldar un estado; un Scientific Model puede producir una Inference; una auditoría puede evaluar conformidad.

#6.7 Verification Result

El verifier deberá producir un resultado estructurado:

• checks ejecutados;
• checks superados;
• checks fallidos;
• objetos no disponibles;
• credenciales revocadas;
• algoritmos no admitidos;
• limitaciones;
• decisión de política.

Un resultado “criptográficamente válido” no deberá resumirse como “claim verdadero”.

---

#7. Eventos, genealogía y Biological Trajectory

#7.1 Evento de trazabilidad y evento científico

Un evento de trazabilidad representa qué ocurrió con una entidad dentro de una cadena. Un evento científico puede representar muestreo, cambio de fase, calibración o generación de Inference.

Los eventos pueden relacionarse, pero no deberán fusionarse cuando sus significados difieren.

#7.2 GS1 EPCIS 2.0

EPCIS 2.0 permite compartir visibility event data dentro y entre empresas, incorpora ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent y AssociationEvent, y añade una dimensión “How” y SensorElement [2].

Originblok® deberá utilizar EPCIS cuando el caso requiera interoperabilidad de cadena de suministro. Las extensiones Nebula deberán preservar compatibilidad y separar vocabulario estándar de vocabulario propio.

#7.3 Genealogía

La genealogía representa división, mezcla, transformación, muestreo, agregación y desagregación.

Una mezcla crea normalmente una nueva identidad de lote relacionada con inputs. Una muestra deriva del lote, pero no es el lote. Una transformación puede conservar identidad administrativa y modificar estado material; el profile deberá declarar la política.

#7.4 Biological Trajectory

La Biological Trajectory integra eventos y estados a través del tiempo. Originblok® preserva las referencias verificables de la trayectoria, mientras Digital Terroir® organiza el contexto científico y The Nebula Mathematics™ modela su evolución.

#7.5 Corrección de eventos

Los eventos no deberán modificarse silenciosamente. Una corrección deberá referenciar el evento previo y declarar:

• error;
• actor;
• motivo;
• evidencia correctiva;
• tiempo de vigencia;
• tiempo de registro.

sequenceDiagram
    participant P as Biological Process
    participant S as Sensor or Operator
    participant E as Evidence Service
    participant O as Originblok®
    participant K as Knowledge Graph
    participant V as Independent Verifier

    P->>S: Material event or signal
    S->>E: Observation + identity + time
    E->>E: Quality and semantic validation
    E->>O: Evidence Artifact + provenance
    O->>O: Hash, signature and timestamp
    O->>K: Claim and Evidence relations
    V->>O: Request Proof of Process™
    O->>V: Manifest + proofs + disclosures
    V->>V: Integrity, status and policy checks

---

#8. Integridad criptográfica

#8.1 Hashes

Una función hash produce un digest de longitud fija. FIPS 180-4 define algoritmos SHA-2 utilizados para detectar cambios en mensajes [8]. El hash no cifra el contenido ni demuestra quién lo produjo.

Originblok® deberá registrar:

• algoritmo;
• versión o profile;
• digest;
• canonicalization;
• media type;
• objeto relacionado.

#8.2 Firmas digitales

Las firmas permiten detectar modificaciones y autenticar al firmante bajo el control de una clave. FIPS 186-5 define algoritmos de firma digital y sus usos [9].

Una firma no prueba que el firmante tenía competencia, autoridad o información correcta. Estas propiedades pertenecen a credenciales y Governance.

#8.3 Key management

La seguridad depende de generación, almacenamiento, rotación, recuperación, revocación y destrucción de claves. Un sistema con algoritmos sólidos y claves comprometidas no es confiable.

Cada proof deberá permitir resolver:

• verification method;
• periodo de validez;
• estado de revocación;
• política criptográfica;
• relación con la identidad.

#8.4 Merkle structures

Las estructuras de Merkle permiten comprometer múltiples objetos mediante una raíz. Pueden reducir el costo de anclaje y permitir inclusion proofs.

El package deberá declarar orden, hashing, canonicalization y algoritmo del árbol. Una raíz sin manifest gobernado no permite interpretar los objetos comprometidos.

#8.5 Proof chains

Las pruebas pueden encadenarse para demostrar derivación o secuencia. El encadenamiento deberá evitar sugerir causalidad cuando solo demuestra orden o dependencia digital.

#8.6 Crypto-agility

Los algoritmos pierden vigencia. Originblok® deberá permitir:

• múltiples proof types;
• re-signing;
• timestamp renewal;
• preservación de pruebas antiguas;
• migración a algoritmos nuevos;
• declaración de algoritmos no admitidos.

#8.7 Data Integrity

W3C Verifiable Credential Data Integrity 1.0 describe mecanismos para autenticidad e integridad de credenciales y documentos mediante firmas y pruebas criptográficas [5]. Originblok® podrá adoptar sus proof sets y proof chains cuando el objeto corresponda con ese modelo.

---

#9. Tiempo verificable

#9.1 Multiplicidad temporal

Originblok® deberá distinguir:

• event time;
• Observation time;
• record time;
• signature time;
• timestamp authority time;
• valid time;
• transaction time.

Confundir estos tiempos puede generar una secuencia falsa.

#9.2 Clock quality

El timestamp de un dispositivo depende de sincronización, deriva y configuración. La Evidence deberá indicar fuente y calidad temporal.

#9.3 Trusted timestamping

RFC 3161 define un protocolo en el que una Time Stamping Authority emite un token para indicar que un datum existía en un momento [10]. El token se aplica normalmente a un digest, preservando confidencialidad del objeto.

#9.4 Ledger timestamp

La inclusión de una transacción en un ledger puede proporcionar un límite temporal bajo las reglas de la red. No necesariamente proporciona tiempo civil exacto ni anterioridad frente a eventos no registrados.

#9.5 Backdating y delayed capture

Una Observation puede registrarse después de ocurrir. El sistema deberá conservar event time declarado y record time verificable, sin presentarlos como equivalentes.

---

#10. Identidad digital y credenciales verificables

#10.1 Identidad material y digital

Un identificador digital designa una representación. No demuestra automáticamente continuidad material.

La identidad de lote deberá vincularse con reglas de creación, transformación, división y cierre. La identidad de instrumento deberá vincularse con serial, modelo, configuración y custodia.

#10.2 DIDs

DID Core 1.0 define identificadores que pueden desacoplarse de registros centralizados y asociarse con documentos que expresan métodos de verificación y servicios [6]. Originblok® puede utilizar DIDs para organizaciones, dispositivos, modelos u otros subjects cuando exista una Governance adecuada.

El uso de DID no es obligatorio. Identificadores Web persistentes, PKI, GS1 y registros institucionales pueden ser más apropiados según el caso.

#10.3 Verifiable Credentials

Una credential puede afirmar:

• competencia de un laboratorio;
• autorización de un operador;
• calibración de un instrumento;
• certificación de una organización;
• estado de un lote;
• resultado de una auditoría.

El verifier deberá comprobar issuer, status, schema, proof, vigencia y política.

#10.4 Credential status y revocación

Las credenciales pueden expirar o revocarse. Un Proof of Process™ histórico deberá registrar el estado relevante en el momento de uso y permitir consultar cambios posteriores.

#10.6 Selective disclosure

El sistema debería permitir demostrar propiedades sin revelar Evidence completa cuando la tecnología, el profile y el riesgo lo permitan. Selective disclosure deberá considerar correlación, revocación y posibilidad de inferir información sensible mediante metadatos.

---

#11. Blockchain y registros distribuidos

#11.1 Neutralidad tecnológica

Originblok® no es una blockchain. Es una Trust Infrastructure que puede utilizar ledgers distribuidos cuando aporten propiedades necesarias.

#11.2 Cuándo considerar blockchain

Una red distribuida puede ser apropiada cuando:

• múltiples organizaciones necesitan escribir o verificar;
• ninguna debe controlar unilateralmente el historial;
• existe Governance de consenso;
• el costo es proporcional;
• la privacidad puede protegerse;
• la disponibilidad a largo plazo es defendible.

#11.3 Cuándo no utilizarla

No debería utilizarse cuando:

• existe una autoridad aceptada y auditable;
• el problema puede resolverse con firmas y logs;
• los datos requieren eliminación o alta confidencialidad;
• el throughput, costo o latencia son incompatibles;
• la Governance de nodos no está definida;
• solo se busca valor promocional.

#11.4 On-chain y off-chain

Los datos científicos y personales deberían permanecer normalmente off-chain. El ledger puede conservar digests, roots, credential status, anchors o referencias.

La permanencia de un hash puede continuar revelando correlación o confirmar la existencia de un documento. La privacidad deberá evaluarse incluso cuando no se publica el contenido.

#11.6 Smart contracts

Los smart contracts pueden automatizar estados, pagos o políticas. No pueden observar el mundo sin oráculos ni interpretar incertidumbre científica por sí solos.

Toda automatización de alto impacto deberá permitir suspensión, revisión y corrección bajo Governance.

#11.7 Tamper-evidence, no infalibilidad

NIST caracteriza blockchain como tamper-evident y tamper-resistant, no como garantía absoluta de inmutabilidad o verdad [7]. Originblok® adoptará ese lenguaje preciso.

---

#12. Arquitectura conceptual

#12.1 Planos

#Capture Plane

Recibe Data Artifacts, Observations, eventos e intervenciones.

#Identity Plane

Administra identificadores, claves, credenciales y resolución.

#Evidence Plane

Valida estructura, calidad, metrología y relevancia.

#Provenance Plane

Registra Entity–Activity–Agent y derivaciones.

#Integrity Plane

Genera hashes, firmas, timestamps y anchors.

#Semantic Plane

Aplica The Nebula Ontology™, schemas y mappings.

#Verification Plane

Construye packages, disclosure y resultados de verificación.

#Governance Plane

Administra políticas, acceso, lifecycle, revocación, incidentes y auditoría.

architecture-beta
    group sources(cloud)[Evidence Sources]
    group originblok(cloud)[Originblok® Trust Infrastructure]
    group knowledge(cloud)[Nebula Knowledge]
    group consumers(cloud)[Verification and Applications]

    service sensors(server)[Sensors and Instruments] in sources
    service humans(server)[Operators and Laboratories] in sources
    service external(server)[External Systems] in sources

    service capture(server)[Capture and Validation] in originblok
    service identity(database)[Identity and Credentials] in originblok
    service provenance(database)[Provenance Registry] in originblok
    service integrity(database)[Integrity and Timestamping] in originblok
    service package(server)[Proof of Process™ Builder] in originblok

    service ontology(database)[Semantic Infrastructure] in knowledge
    service graph(database)[Knowledge Graph] in knowledge
    service library(database)[The Nebula Library™] in knowledge

    service verifier(server)[Independent Verifier] in consumers
    service apps(server)[FermentOps® · TraceOps® · RoastOps®] in consumers

    sensors:R -- L:capture
    humans:R -- L:capture
    external:R -- L:capture
    capture:R -- L:provenance
    identity:B -- T:provenance
    provenance:R -- L:integrity
    integrity:R -- L:package
    ontology:B -- T:package
    graph:B -- T:package
    library:B -- T:package
    package:R -- L:verifier
    package:R -- L:apps

#12.2 Evidence Repository

El repositorio deberá almacenar objetos originales o resoluciones, versiones, retention policy, fixity y derechos. No deberá depender exclusivamente de un ledger.

#12.3 Transparency Log

Un append-only transparency log puede publicar compromisos y permitir monitorización. Su Governance deberá definir operadores, witnesses, disponibilidad y reacción ante inconsistencias.

#12.4 Package Builder

El builder selecciona Evidence según el claim profile, genera manifest, resuelve proofs y aplica disclosure. NO DEBE alterar la Evidence original.

#12.5 Independent Verifier

El verifier debería poder operar con código o especificación independiente del issuer. La dependencia de una API propietaria debilita portabilidad.

#12.6 APIs

Las APIs deberán ser versionadas, autenticadas y semánticamente documentadas. Los SDKs serán conveniencias, no la única forma de verificación.

---

#13. Semantic Infrastructure e Interoperability

#13.1 Interoperabilidad por niveles

Originblok® deberá preservar:

• Interoperability técnica;
• estructural;
• semántica;
• epistemológica;
• criptográfica;
• de Governance.

#13.2 ISO 22005

ISO 22005:2007 proporciona principios y requisitos para diseño e implementación de trazabilidad en cadenas de alimentos y fue confirmada como vigente en 2022 [1]. El perfil Nebula deberá demostrar cómo cumple objetivos declarados y coordinación entre actores.

#13.3 GS1 EPCIS

EPCIS 2.0 es la base preferente para visibility events cuando se requiera integración con cadenas GS1 [2]. Originblok® añadirá referencias a Evidence, Biological Trajectory y Knowledge Claims sin alterar la semántica del estándar.

#13.4 PROV-O

PROV-O proporciona relaciones de generación, uso, derivación y atribución [3]. El Provenance Plane deberá alinear sus entidades y actividades con este modelo.

#13.5 Verifiable Credentials

VC Data Model 2.0 y Data Integrity 1.0 proporcionan un ecosistema interoperable para claims emitidos y asegurados criptográficamente [4][5]. Originblok® podrá expresar certificados, autorizaciones y resultados como credentials cuando el perfil sea apropiado.

#13.6 The Nebula Ontology™

La Ontology define entidades y relaciones científicas que los estándares genéricos no cubren: Biological Trajectory, Evidence Relation, Scientific Model, Digital Terroir® y Proof of Process™.

---

#14. Privacidad, confidencialidad y disclosure

#14.1 Principio de minimización

Un Proof of Process™ deberá revelar únicamente Evidence necesaria para el claim y el verifier.

#14.2 Datos territoriales

Digital Terroir® puede contener ubicación, prácticas, rendimiento, infraestructura o conocimiento sensible de Caficultores. Originblok® deberá preservar clasificación, consentimiento, licencia y reglas de acceso.

#14.3 Data at rest y in transit

Los objetos deberán protegerse mediante cifrado, control de acceso, gestión de claves y logging. Los hashes no sustituyen cifrado.

#14.4 Metadata leakage

Los patrones de tiempo, frecuencia, tamaño, identifiers y relaciones pueden revelar información incluso cuando el contenido permanece cifrado.

#14.5 Redaction

Las redacciones deberán indicar que contenido fue omitido y bajo qué política, sin invalidar silenciosamente el manifest.

#14.6 Zero-knowledge y selective disclosure

Las pruebas de conocimiento cero y credenciales con disclosure selectivo constituyen una línea prometedora, pero su adopción deberá evaluar complejidad, madurez, revocación, performance y auditabilidad.

#14.7 Derecho a corrección y eliminación

La infraestructura deberá manejar obligaciones de corrección o eliminación. Los objetos off-chain pueden eliminarse o restringirse; los anchors permanentes pueden continuar existiendo y deberán evaluarse desde el diseño.

---

#15. Modelo de amenazas y seguridad

#15.1 Amenazas principales

Originblok® deberá considerar:

• dispositivos falsos;
• claves comprometidas;
• replay;
• backdating;
• alteración de firmware;
• captura selectiva;
• manipulación de muestras;
• identidad duplicada;
• credential fraud;
• collusion;
• denial of service;
• privacy leakage;
• model substitution;
• malicious verifier.

#15.2 Sensor spoofing

Una señal firmada por un dispositivo comprometido continúa siendo criptográficamente válida. La Trust Infrastructure deberá combinar attestation, calibración, redundancia, plausibility checks y auditoría.

#15.3 Replay

Los mensajes deberán incluir identifiers, timestamps, nonces o sequence information para detectar repetición.

#15.4 Key compromise

La respuesta deberá incluir revocación, notificación, re-evaluación de proofs afectados y preservación de Evidence de incidente.

#15.5 Insider threat

Los usuarios autorizados pueden manipular selección, clasificación o disclosure. La separación de funciones y audit trails deberá limitar este riesgo.

#15.6 Availability

Un proof que no puede resolverse no es verificable en la práctica. La arquitectura deberá considerar replicación, preservación, exportación y formatos abiertos.

#15.7 Long-term verification

La verificación a largo plazo requiere conservar algoritmos, certificados, status, timestamps, schemas, context files y software o documentación suficiente.

#15.8 Security claims

Originblok® NO DEBE utilizar expresiones absolutas como “imposible de alterar” o “verdad garantizada”. Los claims deberán declarar supuestos y alcance.

---

#16. Governance y modelo de roles

#16.1 Roles

#Evidence Producer

Genera o captura un Evidence Artifact.

#Issuer

Emite una credential o claim firmado.

#Holder

Custodia o presenta una credential o package.

#Verifier

Evalúa proofs y políticas.

#Steward

Gestiona ciclo de vida, calidad y acceso.

#Auditor

Evalúa conformidad, Evidence y controles.

#Trust Registry Operator

Administra listas, policies o status registries.

#Territorial Representative

Participa en decisiones sobre datos, identidad y uso territorial.

#16.2 Separación de funciones

El emisor de una solución no debería ser el único auditor de claims de alto impacto. La independencia requerida dependerá del assurance level.

#16.3 Trust registries

Un trust registry puede listar issuers, laboratories, devices, schemas o policies admitidos. Su autoridad, actualización y apelación deberán ser transparentes.

#16.4 Revocación y suspensión

Los objetos podrán ser suspended, revoked, expired, superseded o withdrawn. El estado deberá ser verificable y conservar motivo y autoridad cuando sea legalmente posible.

#16.5 Disputas

Todo claim material deberá permitir objeción. El proceso deberá preservar Evidence adversa, Decision Records y resultado.

#16.6 The Nebula Governance Model™

NBL-FWK-011 define autoridad, revisión, conflicto y apelación. Originblok® operacionaliza estas decisiones mediante registros verificables, pero no las reemplaza.

---

#17. Verificación científica y técnica

#17.1 Verificación técnica

Determina si hashes, firmas, timestamps, manifests, schemas y status son válidos.

#17.2 Validación semántica

Determina si los objetos utilizan The Nebula Ontology™ y profiles correctos.

#17.3 Validación epistemológica

Determina si el package diferencia Observations, Evidence, Inferences, opiniones y decisiones.

#17.4 Validación científica

Determina si la Evidence es suficiente y relevante para el claim. Puede requerir competencia experta, replicación o laboratorio independiente.

#17.5 Validación operacional

Determina si el package reduce costos, disputas o tiempo de auditoría sin imponer cargas desproporcionadas.

#17.6 Interoperability testing

Dos implementaciones independientes deberán intercambiar y verificar packages.

#17.7 Pruebas adversariales

El programa deberá incluir:

• objeto modificado;
• firma expirada;
• credential revocada;
• timestamp inválido;
• Evidence faltante;
• context file alterado;
• identidad duplicada;
• evento fuera de orden;
• claim fuera de alcance;
• anchor no disponible.

---

#18. Casos de uso

#18.1 Fermentación de café

Proof of Process™ puede respaldar que una Biological Trajectory fue observada bajo un profile definido. El package puede incluir identidad de lote, eventos, sensores, calibración, muestras, intervenciones y Scientific Model.

No deberá afirmar calidad sensorial únicamente a partir de condiciones de proceso sin Evidence de relación.

#18.2 Cacao

Puede preservar genealogía, condiciones de fermentación, muestreo y resultados. Los profiles deberán adaptarse a dinámica, equipos y variables propias del cacao.

#18.3 Vino

Puede apoyar trazabilidad y Evidence de proceso, respetando denominaciones, regulación y tradición del dominio.

#18.4 Ingredientes premium

Puede respaldar origen, transformación, especificaciones, custodia y análisis, reduciendo asimetría entre proveedor y comprador.

#18.5 Certificaciones

Las credentials pueden expresar conformidad emitida por una entidad competente. Originblok® deberá conservar alcance, versión del Standard, fecha, auditor y status.

#18.6 Cumplimiento regulatorio

Puede proporcionar paquetes estructurados para auditoría, siempre que los profiles correspondan con requisitos legales y no se presente como sustitución de la autoridad.

#18.7 Investigación científica

Puede preservar dataset versions, Scientific Models, parámetros, ejecución y derivación, fortaleciendo reproducibilidad.

---

#19. Implicaciones científicas

#19.1 Evidence como grafo

La Evidence deja de ser un archivo adjunto y se convierte en una red de relaciones entre claims, objetos, actividades y agentes.

#19.2 Auditabilidad de Inferences

Las Inferences pueden relacionarse con modelo, versión, inputs y entorno. Esto permite revisar cómo un resultado fue producido.

#19.3 Temporalidad explícita

El conocimiento puede reconstruirse según lo que estaba disponible en un momento, evitando retroactividad silenciosa.

#19.4 Negative Evidence

La infraestructura puede preservar contradicciones y resultados nulos, reduciendo sesgo de publicación interna.

#19.5 Reproducibilidad

Un package bien formado puede facilitar que terceros reproduzcan análisis, pero no garantiza que el proceso biológico produzca resultados idénticos.

#19.6 Nuevos objetos científicos

Proof of Process™ puede convertirse en unidad de intercambio para estudios comparativos, metaanálisis y validación multiterritorial.

---

#20. Implicaciones tecnológicas y económicas

#20.1 Portabilidad

Los packages pueden reducir dependencia de proveedores y facilitar integración.

#20.2 Costo de confianza

La Trust Infrastructure puede reducir due diligence, disputas y reconciliación, pero añade costos de captura, curación, claves, almacenamiento y Governance.

#20.5 Riesgo de concentración

Quien controla identidades, schemas, trust registries o APIs puede concentrar poder. La Governance deberá permitir portabilidad y participación.

#20.6 Sostenibilidad

El uso de ledgers y almacenamiento deberá evaluarse por energía, costo, durabilidad y beneficio. Blockchain no deberá adoptarse cuando una solución más simple produzca assurance equivalente.

---

#21. Limitaciones

La primera limitación es física. Originblok® representa el mundo mediante fuentes falibles.

La segunda es epistemológica. Integridad y procedencia no prueban verdad.

La tercera es identitaria. Un identifier puede vincularse incorrectamente con una entidad material.

La cuarta es temporal. Los clocks pueden derivar y los registros pueden retrasarse.

La quinta es criptográfica. Algoritmos y claves pueden comprometerse u obsoletarse.

La sexta es semántica. Profiles y Ontology pueden contener ambigüedades.

La séptima es operacional. La captura rigurosa puede aumentar carga de trabajo.

La octava es económica. Verificación y preservación tienen costos continuos.

La novena es de privacidad. Metadata y genealogía pueden revelar información sensible.

La décima es jurídica. Validez de firmas, timestamps y credentials varía por jurisdicción.

La undécima es de Governance. Trust registries y issuers pueden abusar de autoridad.

La duodécima es de interoperabilidad. Implementaciones pueden interpretar extensiones de forma distinta.

La decimotercera es de adopción. Los participantes pueden no aceptar el modelo o carecer de infraestructura.

La decimocuarta es ambiental. Algunas redes distribuidas pueden consumir recursos desproporcionados.

---

#22. Condiciones de refutación

Originblok® deberá revisarse, restringirse o considerarse fallido si:

1. los packages no permiten verificación independiente;
2. la integridad criptográfica se presenta sistemáticamente como verdad;
3. la Evidence necesaria permanece inaccesible sin justificación;
4. los profiles no distinguen Observation e Inference;
5. las identidades materiales no sobreviven a escenarios reales;
6. las correcciones destruyen historial o generan confusión;
7. blockchain aumenta costo sin mejorar assurance;
8. los claims no pueden ser impugnados;
9. los actores territoriales pierden control o beneficios;
10. las credenciales no pueden revocarse o resolver estado;
11. la Semantic Infrastructure no mejora Interoperability;
12. la privacidad se degrada de forma desproporcionada;
13. la complejidad impide adopción;
14. las pruebas no resisten ataques básicos;
15. los packages no sobreviven a migración tecnológica.

La refutación de un mecanismo no invalida necesariamente el paradigma. Puede demostrar que una implementación, profile o trust model es inadecuado.

---

#23. Agenda de investigación y evolución

#23.1 Proof of Process™ Profiles

Definir profiles para fermentación, laboratorio, certificación y transferencia tecnológica.

#23.2 Evidence quality models

Investigar cómo expresar calidad sin producir puntuaciones universales engañosas.

#23.3 Identity continuity

Desarrollar reglas para lotes, muestras, mezclas y transformaciones.

#23.4 Verifiable Credentials

Implementar credentials para instrumentos, actores, laboratorios y claims.

#23.5 Selective disclosure

Evaluar mecanismos que reduzcan exposición y preserven verification.

#23.6 Transparency logs

Comparar ledgers institucionales, logs witness-based y redes distribuidas.

#23.7 Long-term verification

Desarrollar renovación de timestamps, crypto-agility y preservación.

#23.8 Automated audit

Investigar verificadores reproducibles y machine-readable policies.

#23.9 Trust registries federados

Permitir múltiples autoridades con reglas de reconocimiento.

#23.10 Scientific reproducibility

Integrar packages con datasets, modelos y entornos ejecutables.

#23.11 Territorial Governance

Definir control, consentimiento, atribución y beneficio para Caficultores.

#23.12 Independent validation

Publicar test vectors, conformance suites y reference verifier.

timeline
    title Agenda de Originblok®
    Fase I : Evidence manifest
           : Hashing y firmas
           : Provenance profile
    Fase II : Proof of Process™ para café
            : EPCIS 2.0 alignment
            : Verifiable Credentials
    Fase III : Selective disclosure
             : Transparency logs
             : Independent verifier
    Fase IV : Federated trust registries
            : Cacao y otros dominios
            : Automated audit
    Fase V : Long-term verification
           : Independent replication
           : Standards candidate

---

#24. Relación con The Nebula Framework™

#24.1 Digital Terroir®

Digital Terroir® representa contexto y Biological Trajectory. Originblok® preserva identidad, procedencia e integridad de sus Evidence.

#24.2 The Nebula Epistemology™

Define Observation, Evidence, Inference, Hypothesis y Knowledge Claim. Originblok® operacionaliza su separación mediante objetos y proofs.

#24.3 The Nebula Mathematics™

Define estados, parámetros, incertidumbre y modelos. Originblok® conserva versiones, inputs y outputs.

#24.4 The Nebula Ontology™

Define significado e identidad semántica para los objetos.

#24.5 La Arquitectura Nebula™

Proporciona Capture, Evidence, Knowledge, Intelligence y Application layers. Originblok® opera como plano transversal de Trust Infrastructure.

#24.6 The Nebula Knowledge Model™

Define Knowledge Objects, metaconocimiento y lifecycle. Originblok® proporciona pruebas de integridad y procedencia.

#24.7 The Nebula Governance Model™

Define autoridades, policies, appeals y Temporal Evolution.

#24.8 The Nebula Economic Model™

Define creación, distribución y captura de valor. Originblok® puede reducir asimetría y respaldar transacciones sin determinar por sí solo su justicia.

#24.9 FermentOps®, RoastOps® y TraceOps®

Las aplicaciones generan y consumen eventos y Proof of Process™ mediante contratos comunes.

---

#Conclusiones

Originblok® establece una infraestructura de confianza basada en Evidence y no únicamente en declaraciones.

Su contribución principal es separar integridad, autenticidad, procedencia, trazabilidad y verdad científica. Un hash puede detectar modificaciones; una firma puede autenticar una clave; un timestamp puede acreditar existencia temporal; un ledger puede producir tamper-evidence. Ninguno de estos mecanismos demuestra por sí solo que una Observation representa correctamente el mundo o que un Knowledge Claim es verdadero.

Proof of Process™ integra esas propiedades dentro de un paquete gobernado que vincula claims con Biological Trajectory, Observations, Evidence, Scientific Models, Inferences, identidades, eventos, firmas, timestamps y limitaciones.

La infraestructura adopta estándares existentes donde resultan adecuados. ISO 22005 proporciona principios de trazabilidad; GS1 EPCIS 2.0 proporciona visibility events y TransformationEvent; PROV-O proporciona procedencia; Verifiable Credentials proporciona claims portables; Data Integrity proporciona proofs; DID Core proporciona una opción de identidad verificable.

Blockchain permanece como mecanismo opcional. Su uso deberá justificarse por un modelo de confianza distribuido, no por expectativa promocional. Los datos sensibles y científicos permanecerán normalmente off-chain, mientras digests, roots o status podrán anclarse cuando ello mejore assurance.

Originblok® deberá preservar privacidad, permitir selective disclosure, soportar correcciones y mantener crypto-agility. También deberá resistir la tentación de convertir la confianza en una puntuación universal.

La infraestructura será científicamente legítima cuando permita cuestionar y refutar claims, no solo confirmarlos. Será tecnológicamente legítima cuando un tercero pueda verificar packages sin dependencia exclusiva del emisor. Será territorialmente legítima cuando los Caficultores y demás actores conserven derechos, atribución y capacidad de objeción.

El objetivo de Originblok® no es producir una historia imposible de cambiar.

Es producir una historia cuya evolución, Evidence, correcciones y límites puedan ser examinados.

---

#Glosario

#Anchor

Referencia criptográfica registrada en un servicio, log o ledger para demostrar existencia o integridad de un compromiso.

#Authenticity

Propiedad que permite evaluar que una declaración fue producida por el controlador de una identidad o clave.

#Biological Trajectory

Representación temporal y contextualizada de la evolución de un Biological Process.

#Credential

Conjunto de claims emitido por un issuer y susceptible de verificación.

#DID

Decentralized Identifier conforme o relacionado con el modelo W3C DID Core.

#Evidence

Objeto o relación verificable que respalda, contradice o deja indeterminada una afirmación.

#Evidence Artifact

Entidad material o informacional utilizada para evaluar un claim.

#Hash

Digest producido por una función criptográfica para detectar cambios en un mensaje.

#Integrity

Capacidad de detectar modificaciones no autorizadas o no declaradas.

#Issuer

Actor que emite una credential o claim verificable.

#Knowledge Claim

Afirmación identificable con alcance, Evidence, incertidumbre y estado epistemológico.

#Ledger

Registro ordenado de transacciones o eventos administrado bajo reglas definidas.

#Originblok®

Trust Infrastructure de identidad, procedencia, integridad y Proof of Process™ de The Nebula Framework™.

#Proof of Process™

Paquete versionado que vincula un claim sobre proceso con Evidence, identidad, procedencia, integridad, tiempo y Governance.

#Provenance

Información sobre generación, uso, transformación, derivación y atribución de entidades.

#Selective Disclosure

Presentación de una parte limitada de claims o Evidence necesaria para un propósito.

#Signature

Valor criptográfico utilizado para autenticar al firmante y detectar modificaciones.

#Timestamp

Evidence que relaciona un datum o digest con un momento bajo un mecanismo definido.

#TraceOps®

Dominio operacional encargado de eventos, identidad, custodia y genealogía.

#Trust Infrastructure

Mecanismos científicos, técnicos, semánticos y de Governance utilizados para evaluar credibilidad.

#Verifier

Actor o sistema que evalúa proofs, status, Evidence y policy.

---

#Bibliografía recomendada

1. International Organization for Standardization. ISO 22005:2007 — Traceability in the Feed and Food Chain — General Principles and Basic Requirements for System Design and Implementation. 2007; confirmada en 2022.

2. GS1. EPCIS Standard, Release 2.0. Ratified, junio de 2022.

3. World Wide Web Consortium. PROV-O: The PROV Ontology. W3C Recommendation, 2013.

4. World Wide Web Consortium. Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 de mayo de 2025.

5. World Wide Web Consortium. Verifiable Credential Data Integrity 1.0. W3C Recommendation, 15 de mayo de 2025.

6. World Wide Web Consortium. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 de julio de 2022.

7. Yaga, D.; Mell, P.; Roby, N.; Scarfone, K. NISTIR 8202 — Blockchain Technology Overview. National Institute of Standards and Technology, 2018.

8. National Institute of Standards and Technology. FIPS 180-4 — Secure Hash Standard. 2015.

9. National Institute of Standards and Technology. FIPS 186-5 — Digital Signature Standard. 2023.

10. Adams, C.; Cain, P.; Pinkas, D.; Zuccherato, R. RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol. IETF, 2001; actualizado por RFC 5816.

11. GS1. Core Business Vocabulary Standard, Release 2.0. Referencia sugerida.

12. World Wide Web Consortium. Semantic Sensor Network Ontology. W3C Recommendation, 2017. Referencia sugerida.

13. World Wide Web Consortium. Data Integrity ECDSA Cryptosuites v1.0. W3C Recommendation, 2025.

14. World Wide Web Consortium. Data Integrity EdDSA Cryptosuites v1.0. W3C Recommendation, 2025. Referencia sugerida.

15. Haber, S.; Stornetta, W. S. “How to Time-Stamp a Digital Document.” Referencia sugerida.

16. Merkle, R. C. “A Digital Signature Based on a Conventional Encryption Function.” Referencia sugerida.

17. Kshetri, N. “Blockchain’s Roles in Meeting Key Supply Chain Management Objectives.” Referencia sugerida.

18. Lemieux, V. L. “Trusting Records: Is Blockchain Technology the Answer?” Referencia sugerida.

---

#Anexo A — Registro mínimo de Proof of Process™

---

#Anexo B — Algoritmo conceptual de verificación

flowchart TD
    A[Receive Proof of Process™] --> B[Validate manifest and schema]
    B --> C[Resolve identifiers and credentials]
    C --> D[Verify hashes and signatures]
    D --> E[Verify timestamps and anchors]
    E --> F[Check revocation and lifecycle status]
    F --> G[Validate provenance graph]
    G --> H[Evaluate claim profile]
    H --> I[Assess Evidence quality and limitations]
    I --> J{Policy decision}
    J -->|Accept| K[Accepted for Context of Use]
    J -->|Conditional| L[Accepted with restrictions]
    J -->|Reject| M[Rejected with reasons]
    J -->|Indeterminate| N[Additional Evidence required]

---

#Anexo C — Prueba de conformidad

Una implementación será compatible con Originblok® cuando:

1. diferencie integridad y verdad;
2. identifique el claim y Context of Use;
3. preserve identidad de entidades;
4. conserve Observations y Evidence;
5. represente procedencia;
6. permita detectar alteraciones;
7. registre algoritmos y claves;
8. distinga tiempos relevantes;
9. permita correcciones y revocaciones;
10. aplique The Nebula Ontology™;
11. soporte exportación interoperable;
12. permita verificación independiente;
13. preserve privacy y disclosure proporcional;
14. represente Evidence adversa;
15. declare limitaciones y Governance.

---

#Anexo D — Canon de Originblok®

La Evidence precede a la confianza.

La integridad criptográfica no demuestra verdad científica.

Una firma autentica una declaración bajo una clave; no demuestra competencia ni exactitud.

Un timestamp demuestra una relación temporal bajo sus supuestos; no reconstruye el mundo material.

Proof of Process™ existe respecto a un claim y un Context of Use.

La procedencia deberá poder reconstruirse desde el claim hasta sus fuentes.

Blockchain es una opción arquitectónica, no el propósito de Originblok®.

Los datos sensibles deberán permanecer fuera de ledgers públicos salvo justificación excepcional.

La corrección deberá añadir conocimiento sin borrar la historia necesaria para interpretarlo.

La verificación independiente es condición de Trust Infrastructure.

---

#Anexo E — Declaración institucional

Originblok® constituye la infraestructura oficial de identidad, procedencia, integridad verificable y Proof of Process™ de The Nebula Framework™.

Su propósito es permitir que las afirmaciones sobre procesos biológicos puedan examinarse mediante Evidence contextualizada, temporalmente situada, semánticamente interoperable y protegida contra alteraciones no declaradas.

Nebula reconoce que ninguna firma, blockchain, credential o ledger demuestra por sí solo la verdad de un proceso. La legitimidad de Originblok® dependerá de su capacidad para preservar Evidence, comunicar limitaciones, permitir refutación, proteger privacidad y sostener verificación independiente.

Versión: 1.0.0
Estado: Draft
Idioma canónico: Español Latino (es-419)
Documento: NBL-WP-014

The Nebula Framework™