EVIDE MCP

Capa externa de cristalización probatoria para gobernanza de IA, anclaje de responsabilidad y registros de decisiones verificables de forma independiente.

GitHubPrueba este MCPPatrocinado

Documentación

Servidor EVIDE MCP v1.4.0

Servidor MCP que conecta agentes de IA a la API del Depósito Evidencial Externo EVIDE.

EVIDE cristaliza las decisiones de los agentes de IA, las escalaciones y los estados de gobernanza en registros forenses verificables de forma independiente -- anclados a una identidad humana verificada, con marca de tiempo en el servidor en UTC, y externalizados antes de que comience la propagación de consecuencias.

EVIDE no es una capa de control de ejecución. Es una capa externa de cristalización evidencial que opera en el límite de cierre de responsabilidad.

Novedades en v1.4.0

execution_identity ampliado. Tres nuevos descriptores a nivel de despliegue (model_reference, agent_name, deployment_id) y dos nuevos identificadores específicos de ejecución, en el momento de la llamada (session_id, run_id). Los cinco son opcionales.
session_id y run_id son solo en el momento de la llamada. Se aceptan como argumentos opcionales directamente en evide_intake, evide_escalate y evide_intake_esb -- no existe un equivalente de variable de entorno para ellos, por diseño, porque varían por llamada y no por despliegue.
Marcadores de posición generados por software eliminados. agent_unspecified y Unknown Agent System ya no aparecen dentro de execution_identity. Un campo opcional no establecido ahora se omite, no se rellena -- la ausencia sigue siendo ausencia.
accountability_model: "owner_bound" sin cambios. Sigue codificado de forma fija, nunca se deriva de ningún campo de execution_identity. Consulte execution_identity -- Contexto de Ejecución Declarado a continuación para conocer el límite completo.
Suite de pruebas de regresión dedicada. Nuevas pruebas cubren registros mínimos/ampliados/de estilo heredado, rechazo de solo espacios en blanco, propagación en el momento de la llamada y compatibilidad retroactiva con registros históricos.
Endurecimiento del límite entre documentación y vista de solicitudes. Se aclaró, en este README y en la aplicación EVIDE, que los identificadores de contexto de ejecución declarados no son identidad de agente verificada y no alteran quién es responsable de un depósito.
Totalmente compatible con versiones anteriores. Un registro construido exactamente como en v1.3.0 sigue siendo válido en v1.4.0 sin modificación.

Novedades en v1.3.0

EVIDE ANCHOR. declarations en evide_intake, evide_escalate y evide_intake_esb: declaraciones explícitas, atribuibles y limitadas en el tiempo del perímetro operativo (entorno, privilegios, propósito, herramientas, operaciones prohibidas, configuración del agente) dentro del cual el agente estaba autorizado, antes de actuar. EVIDE solo preserva la declaración -- nunca verifica su corrección, la aplica como política ni la compara con el comportamiento observado.
Esquema EVIDE 2.1. Las versiones anteriores declaraban evide_schema: 2.0 y eran rechazadas por producción con unsupported_schema en cada depósito. Si clonó antes de julio de 2026, su copia no podía depositar en absoluto.
Continuidad Evidencial. parent_evide_id, chain_type y matter_reference en ambas herramientas de depósito, con los cuatro códigos de rechazo documentados.
Artefactos Externos. evidence_references con declaración de hash estructurada; el registro extensions se mantiene alineado por el cliente.
Buffer de Estabilización Epistémica. Tres nuevas herramientas: evide_intake_esb, evide_buffer_observe, evide_buffer_close.
Preparación de límites alineada con la declaración de compuerta independiente. candidate es ahora el valor predeterminado para ambas herramientas, y el cliente ya no fabrica un readiness_gate.
El cliente ya no completa declaraciones que pertenecen a otra persona. hashed_by, readiness_gate, unresolved_signals y stabilization_score nunca se rellenan en nombre del llamante: un campo faltante falla la llamada en lugar de ser inventado.

Requisitos previos -- Leer antes de instalar

Ambos requisitos previos son obligatorios. El servidor no se iniciará sin ellos.

1. DAPI -- Identidad Verificada

EVIDE no acepta depósitos anónimos. Cada registro debe ser atribuible a una identidad humana verificada.

DAPI (Atestación Digital de Identidad Personal) es la capa de identidad que vincula cada depósito a una identidad verificada y atribuible. El número DAPI pertenece al humano u organización responsable del agente de IA -- no al agente en sí. El agente no puede autocertificarse.

EVIDE no determina si la decisión en sí fue correcta. Preserva las condiciones de responsabilidad y gobernanza externamente reconstruibles presentes en el momento del cierre, haciéndolas examinables de forma independiente.

Cómo obtener un DAPI: dapi-certification.com

La verificación DAPI requiere: 1 documento de identidad válido, 1 foto facial, 1 archivo de audio con voz, 1 video corto. El procesamiento es manual. Permita tiempo antes de planificar su integración.

2. Clave API de EVIDE -- Suscripción Activa

El acceso a la API de ingesta de EVIDE requiere un plan activo y una clave API dedicada (evd_...).

Planes y precios: app.certifywebcontent.com/pricing

Planes disponibles: Entry (10 ingestiones/mes), Starter (75), Professional (200), Enterprise (500). Para volúmenes superiores a 500 ingestiones/mes, se requiere infraestructura dedicada -- contáctenos antes de activar.

Qué Deposita EVIDE

Cada registro ancla:

la identidad de la autoridad responsable (propietario vinculado a DAPI)
la identidad de ejecución del agente (separada arquitectónicamente del propietario)
el estado de clasificación y la estabilidad operativa en el cierre
la preparación de límites y la superficie de visibilidad de compuerta
el nivel de supervisión humana declarado en el cierre
señales no resueltas que no pudieron confirmarse en el momento del cruce

El perfil evidencial calculado por el servidor (profile_version: 1.1) incluye:

Dim 9 -- Verificación Cruzada Forense -- inferencia de continuidad (clasificación x visibilidad de ejecución) -- sensor anti-Coherencia Sintética
Dim 10 -- Compresión de Onda de Decisión (DWC) -- detección de límites de rendimiento de supervisión
Dim 11 -- Colapso Formal de Responsabilidad (FAC) -- detección de fragmentación de autoridad

Importante: El perfil evidencial contiene señales de gobernanza inferidas. Estas señales son indicadores de gobernanza probabilísticos, no determinaciones judiciales ni acusaciones de mala conducta. Un estado detected o critical para DWC o FAC indica una condición estructural presente en el momento del cierre -- no constituye un hallazgo de irregularidad por parte de ninguna de las partes.

Instalación

git clone https://github.com/emanuelcelano/evide-mcp
cd evide-mcp
npm install

Se requiere Node.js >= 18.

Configuración

Agregue a la configuración de su cliente MCP (claude_desktop_config.json o equivalente):

{
  "mcpServers": {
    "evide": {
      "command": "node",
      "args": ["/path/to/evide-mcp/index.js"],
      "env": {
        "EVIDE_API_KEY":      "evd_your_key_here",
        "EVIDE_DAPI_NUMBER":  "0123456789",
        "EVIDE_OWNER_ID":     "your_owner_id",
        "EVIDE_OWNER_ROLE":   "AI System Operator",
        "EVIDE_AGENT_SYSTEM": "MyAgentSystem",
        "EVIDE_AGENT_ID":     "agent_xyz"
      }
    }
  }
}

Variables de Entorno

Variable	Requerida	Descripción
`EVIDE_API_KEY`	Sí	Su clave API de EVIDE (`evd_...`)
`EVIDE_DAPI_NUMBER`	Sí	Su número DAPI de 10 dígitos
`EVIDE_OWNER_ID`	Sí	Su identificador en el sistema de origen
`EVIDE_OWNER_ROLE`	No	Descripción del rol. Predeterminado: `AI System Operator`
`EVIDE_AGENT_SYSTEM`	No	Nombre del sistema del agente. Omitido de `execution_identity` si no se establece -- no se sustituye ningún marcador de posición.
`EVIDE_AGENT_ID`	No	Identificador de instancia del agente. Omitido de `execution_identity` si no se establece -- no se sustituye ningún marcador de posición.
`EVIDE_MODEL_REFERENCE`	No	Nombre/versión del modelo declarado en uso (p. ej. `claude-sonnet-4-6-20260514`). Nuevo en v1.4.0.
`EVIDE_AGENT_NAME`	No	Etiqueta legible por humanos para el agente (p. ej. `Legal Intake Agent`). Nuevo en v1.4.0.
`EVIDE_DEPLOYMENT_ID`	No	Identificador de este despliegue/versión específico del agente, distinto del `EVIDE_AGENT_ID` estable. Nuevo en v1.4.0.

session_id y run_id no son variables de entorno. Varían por llamada y se aceptan como argumentos opcionales en el momento de la llamada en las propias herramientas de depósito -- consulte execution_identity -- Contexto de Ejecución Declarado a continuación.

Herramientas

`evide_intake`

Deposite una decisión finalizada de IA como registro evidencial.

{
  "source_reference": "CDR-2026-00421",
  "decision_type": "candidate_evaluation",
  "decision_summary": "Candidate approved for second round interview.",
  "classification_status": "stable",
  "threshold_status": "met",
  "boundary_status": "candidate",
  "human_oversight_level": "L2"
}

Mantenga decision_summary corto: se convierte en el título del registro. Se almacena y muestra tal cual, sin gestión de longitud en el lado del servidor: un decision_summary de longitud de párrafo se convierte en un título de longitud de párrafo, y los valores muy largos pueden truncarse por el almacenamiento subyacente de maneras que cortan un título a mitad de palabra. Trátelo como una etiqueta de una línea, no como una narrativa.

Para la explicación más completa -- por qué se tomó la decisión, qué era ambiguo, qué evidencia se sopesó -- use el campo opcional rationale en su lugar. Existe exactamente para este propósito y no tiene una expectativa de longitud práctica como la tiene un título.

{
  "decision_summary": "Clause 8.3 - liability scope ambiguous, Rossi Manufacturing contract",
  "rationale": "The limitation-of-liability clause's scope is ambiguous relative to a recent similar dispute, decided differently by two lower courts. Final assessment is on hold pending internal legal opinion and updated case law."
}

Artefactos externos opcionales (evidence_references):

{
  "source_reference": "CDR-2026-00423",
  "decision_type": "claim_assessment",
  "decision_summary": "Claim rejected: documentation inconsistent with policy terms.",
  "evidence_references": [
    {
      "artifact_type": "document",
      "pointer": "s3://evidence-store/claim-8812/policy.pdf",
      "declared_origin": "policy_management_system",
      "declared_relationship": "supporting_document",
      "declared_retention_status": "persistent_storage",
      "hash_algorithm": "sha256",
      "hash_value": "9f2c7a1b4e6d...",
      "hash_scope": "full_file",
      "hashed_by": "policy_management_system"
    }
  ]
}

EVIDE ancla la declaración de que un artefacto existe -- el archivo en sí nunca se sube, y EVIDE nunca calcula ni verifica su hash. Por eso hashed_by es obligatorio siempre que se declare un hash: un digest anclado sin procedencia declarada no tendría valor. El cliente valida esto antes de que la solicitud salga, por lo que un campo faltante produce un mensaje que lo nombra en lugar de un rechazo genérico del servidor. No se infiere nada: hashed_by nunca se rellena con la identidad del agente, porque afirmar que el agente calculó un digest que simplemente retransmitió sería una afirmación de procedencia falsa.

Declarar la matriz establece automáticamente extensions: ["evidence_references"]. Ese registro es de participación voluntaria en ambas direcciones -- un bloque presente pero no declarado se rechaza, y una declaración sin contenido también se rechaza -- por lo que el cliente mantiene ambos alineados por construcción.

Declaraciones de perímetro operativo opcionales (declarations, EVIDE ANCHOR):

{
  "source_reference": "CDR-2026-00424",
  "decision_type": "operational_perimeter_declaration",
  "decision_summary": "Environment classification declared before agent action.",
  "declarations": [
    {
      "declaration_type": "environment_classification",
      "declared_value": "production",
      "declarant": "devops-lead",
      "declared_at": "2026-08-03T16:30:00Z",
      "declared_attribution_status": "attributed"
    }
  ]
}

Una Declaración es una declaración explícita, atribuible y limitada en el tiempo del perímetro operativo (entorno, privilegios, propósito, herramientas, operaciones prohibidas, configuración del agente) dentro del cual un agente estaba autorizado, antes de actuar. EVIDE solo preserva la declaración -- nunca verifica su corrección, la aplica como política ni la compara con el comportamiento observado. Este es el primitivo detrás del incidente que lo motivó: un agente que confunde una base de datos de producción con un entorno de prueba desechable es exactamente el caso que un environment_classification declarado hace reconstruible de forma independiente después del hecho.

Este esquema a nivel de MCP está deliberadamente simplificado en relación con la API completa: declaration_type, declared_value, declarant, declared_at, declared_description y un declared_attribution_status aplanado se exponen aquí. Los subject_references, authority_source.references y declared_relations anidados (que declaran que una Declaración reemplaza, aclara o revoca otra) no lo están -- permanecen disponibles a través de la API de ingesta directa para los llamantes que necesiten la forma anidada.

declaration_digest se calcula en el lado del servidor, no por este cliente. Para cada Declaración, la API calcula SHA-256("EVIDE_DECLARATION_V1:" + canonical_json(Declaration)) en el momento de la ingesta y lo devuelve como parte del registro almacenado. El cliente MCP nunca calcula ni envía este valor -- no tiene un campo declaration_digest en el esquema de la herramienta anterior. Esto le da a cada Declaración su propia evidencia de manipulación independiente del intake_hash general de la ingesta, y es lo que declared_relations en la referencia completa de la API cuando una Declaración reemplaza a otra.

Declarar la matriz establece automáticamente extensions: ["declarations"], usando el mismo registro de participación voluntaria que evidence_references -- ambos pueden declararse juntos en el mismo depósito.

Regla de Declaración Atómica

Cada Declaración debe representar una única declaración atribuible. Cuando una solicitud describe múltiples hechos independientes -- por ejemplo, tanto una clasificación de entorno como un alcance de privilegios -- cada uno debe preservarse como su propia Declaración, no fusionarse en una sola.

Los valores compuestos de declaration_type (p. ej. environment_and_privilege) son aceptados por el esquema -- declaration_type es texto libre por diseño -- pero se desaconsejan: una declaración fusionada no puede luego ser reemplazada, aclarada o revocada independientemente de los hechos que agrupa. Si la clasificación de entorno cambia pero el alcance de privilegios no, solo la Declaración de environment_classification debería ser reemplazada -- eso se vuelve imposible una vez que los dos se combinan en una sola. Parámetros de cadena opcionales (Continuidad Evidencial):

{
  "source_reference": "CDR-2026-00422",
  "decision_type": "candidate_evaluation",
  "decision_summary": "Escalation resolved: candidate approved after compliance review.",
  "parent_evide_id": "aed9e966-6f25-4358-b784-b06eff939e91",
  "chain_type": "escalation_resolution",
  "matter_reference": "MATTER-2026-4471"
}

El uso natural es pasar el evide_id devuelto por un evide_escalate anterior como parent_evide_id en el depósito que lo resuelve, produciendo un linaje declarado desde "el agente se detuvo aquí" hasta "así se cerró".

La validación de cadena es estricta y no tiene respaldo silencioso. Si el padre no existe, pertenece a otro dominio evidencial, está en un estado no encadenable o declara un matter_reference diferente, todo el depósito se rechaza en lugar de iniciar silenciosamente una nueva cadena. Los rechazos son chain_parent_not_found (422), chain_parent_not_owned (403 — una decisión de autorización, no un error de carga útil), chain_parent_invalid_status (422) y chain_matter_mismatch (422).

Devuelve: evide_id, intake_hash, intake_timestamp_utc, profile_version, estado de Verificación Cruzada Forense, estados DWC y FAC cuando están presentes, y — cuando el registro continúa desde otro — chain_position, chain_type y chain_root_evide_id.

`evide_escalate`

Cristaliza el estado del agente antes de proceder en un límite de alto riesgo o impugnable.

{
  "source_reference": "ESC-2026-00089",
  "agent_state_summary": "Transaction exceeds regulatory threshold. Human review required.",
  "escalation_trigger": "regulatory_threshold",
  "escalation_reason": "Amount exceeds €50,000 -- requires compliance officer approval.",
  "boundary_status": "verified_partial",
  "unresolved_signals": ["compliance_officer_availability", "aml_flag_status"]
}

evide_escalate acepta los mismos parámetros opcionales de cadena, evidence_references y declarations que evide_intake, para el caso en que una escalada continúa desde otra.

agent_state_summary alimenta el mismo campo de título que decision_summary anterior: mantenlo corto por la misma razón. La imagen más completa pertenece a escalation_reason, que ya existe exactamente para eso.

Disparadores disponibles: high_stakes_decision · contestable_state · legal_ambiguity · regulatory_threshold · governance_uncertainty · semantic_instability · human_review_required · authority_incoherence

`evide_owner_info`

Devuelve la identidad configurada del propietario y del agente. No expone la clave API completa.

`evide_check`

Devuelve orientación de verificación para un registro depositado previamente.

`execution_identity` -- Contexto de Ejecución Declarado

Cada depósito realizado a través de evide_intake, evide_escalate y evide_intake_esb incluye un bloque execution_identity. Separa la identidad responsable del propietario (bajo authority, vinculada a DAPI) del contexto de ejecución declarado (agente, modelo, sesión, ejecución — según lo proporcionado). Solo type y accountability_model están siempre presentes; cada otro campo es opcional y simplemente se omite cuando no está disponible.

Contexto de ejecución a nivel de implementación

Estático por configuración de cliente, establecido una vez mediante las variables de entorno anteriores y sin cambios en cada llamada de esa implementación:

agent_id
agent_system
model_reference
agent_name
deployment_id

Identificadores específicos de ejecución en tiempo de llamada

Dinámicos, aceptados como argumentos opcionales directamente en evide_intake, evide_escalate y evide_intake_esb:

session_id
run_id

session_id y run_id:

son opcionales;
son proporcionados por el llamador;
entran a través de la propia llamada a la herramienta, en este cliente MCP — no hay equivalente de variable de entorno para ellos;
no son generados por EVIDE;
no son autenticados por EVIDE;
no constituyen identidad de agente verificada.

Registro mínimo (sin contexto opcional declarado):

{
  "execution_identity": {
    "type": "agent_identity",
    "accountability_model": "owner_bound"
  }
}

Registro completamente declarado, incluido el contexto en tiempo de llamada:

{
  "execution_identity": {
    "type": "agent_identity",
    "agent_id": "legal-intake-agent",
    "agent_system": "CLARIXO",
    "model_reference": "claude-sonnet-4-6-20260514",
    "agent_name": "Legal Intake Agent",
    "deployment_id": "legal-intake-prod-eu-2026-07",
    "session_id": "sess_8f21c",
    "run_id": "run_3af90d",
    "accountability_model": "owner_bound"
  }
}

Límite

execution_identity preserva identificadores de contexto de ejecución declarados o proporcionados externamente. Su presencia no verifica de forma independiente la identidad, autenticidad, procedencia o control del agente, modelo, sesión o ejecución referenciados.

accountability_model: "owner_bound" permanece codificado y registra que, dentro del modelo evidencial de EVIDE, la responsabilidad del depósito permanece asociada al propietario verificado por DAPI en lugar de transferirse al agente referenciado.

Ningún campo opcional se completa jamás con un valor de relleno. Si un valor no está disponible, se omite — la ausencia permanece como ausencia.

Buffer de Estabilización Epistémica

Tres herramientas adicionales permiten que un agente gestione el ciclo de vida completo del ESB:

herramienta	qué hace
`evide_intake_esb`	deposita el cierre y abre un buffer sobre él. Devuelve `buffer_id`.
`evide_buffer_observe`	registra una observación intermedia mientras el buffer está abierto. Se puede llamar más de una vez.
`evide_buffer_close`	cierra el buffer con un veredicto.

El cierre se ancla inmediatamente, exactamente como con evide_intake: el buffer se abre junto a él, no lo retrasa ni lo reemplaza. Lo que el buffer añade es la trayectoria — cómo se establecieron las condiciones durante una ventana real, en lugar de solo cómo estaban en el cruce.

Se requiere una ventana de observación real. El servidor rechaza un cierre que ocurra menos de dos segundos después de la apertura, porque un buffer que se cierra instantáneamente no observó nada. La ventana medida regresa como window_seconds. test_mode: true omite esto, y se expone solo porque el servidor lo acepta: un buffer cerrado en modo de prueba no observó una ventana real, y el registro no fingirá lo contrario.

stabilization_score se declara, nunca se calcula. Ni EVIDE ni este cliente lo calculan. Los valores fuera de rango se rechazan en lugar de ajustarse, porque ajustarlos ocultaría un error del cliente. Si no tienes base para una puntuación, omítela — el cliente no proporciona una en tu nombre. El mismo principio ya se aplicó a hashed_by y readiness_gate.

Los campos de fase se aplican en el lado del cliente. buffer/update y buffer/close aceptan diferentes conjuntos de claves. Enviar stabilization_score a una observación, o stability_trend a un cierre, se rechaza con un mensaje que nombra la herramienta a la que pertenece — en lugar de descartarse silenciosamente, que es lo que la API misma hacía hasta julio de 2026.

evide_intake_esb        → closure anchored, buffer_id returned, buffer OPEN
      ↓
evide_buffer_observe    → stability_trend, continuity_state,
      ↓                   causal_persistence_signal, stabilization_source
evide_buffer_close      → verdict + window_seconds
                          "crossing-sufficient, NOT absolute epistemic truth"

Preparación de Límites y la Compuerta Independiente

Las admisiones originadas por agentes tienen como valor predeterminado boundary_readiness: candidate. En ausencia de una compuerta de preparación declarada de forma independiente, FCC, DWC y FAC pueden permanecer como unknown. Este es un resultado evidencial, no una falla de procesamiento.

boundary_readiness declara si una compuerta independiente evaluó el límite. Un agente depositante no es esa compuerta: no puede atestiguar su propia preparación en un límite más de lo que un sistema puede autocertificarse. Por lo tanto, el cliente nunca fabrica una — readiness_gate_id y readiness_gate_scope deben provenir del llamador, y cualquier estado que no sea candidate se rechaza sin ellos.

Lo mismo se aplica a unresolved_signals, que lleva los identificadores que una compuerta no pudo resolver durante su evaluación. Con candidate la matriz está vacía por definición, no por restricción: no se realizó ninguna evaluación, por lo que nada podría haber quedado abierto. Lo que el agente no pudo decidir es algo diferente, y vive en escalation_reason y agent_state_summary.

Este es el ciclo de vida previsto, y así es como las integraciones independientes ya usan el esquema en producción:

agent
  ↓  evide_escalate / evide_intake  →  boundary_readiness: candidate
  ↓                                    FCC / DWC / FAC: unknown
independent gate (human supervisor, orchestrator, external governance component)
  ↓  assessment                      →  boundary_readiness: verified_partial
                                       with its own readiness_gate

El agente nunca tiene que hacerse pasar por la compuerta. El mismo principio ya se aplicó a hashed_by: el cliente no inventa una declaración que pertenece a otra persona.

Alcance de las Abstracciones Actuales

Las abstracciones MCP actuales exponen intencionalmente solo los tipos de intervención requeridos por las herramientas implementadas (approval para evide_intake, escalation para evide_escalate). Semánticas de intervención adicionales — por ejemplo override o rejection — se introducirán solo cuando un flujo de trabajo de agente concreto las requiera, en lugar de especular sobre casos de uso futuros.

El mismo razonamiento se aplica a human_oversight.is_declared, que siempre es true. Esto no es un atajo: el servidor no puede iniciarse sin un número DAPI, por lo que cada depósito realizado a través de él es, por construcción, atribuible a un humano responsable declarado. No hay una ruta anónima que dejar abierta. El nivel de supervisión sigue siendo elección del llamador (L1 / L2 / L3); solo la existencia de una autoridad declarada es fija, porque el propio transporte lo garantiza.

Principio Arquitectónico

authority          = accountable human / organization (DAPI-bound)
execution_identity = declared execution context associated with the closure
escalation_context = why crystallization was requested

La responsabilidad está vinculada al propietario: permanece asociada, dentro del modelo evidencial de EVIDE, con el propietario verificado por DAPI en lugar de transferirse al agente referenciado. El agente no puede autocertificarse.

Validación en Vivo

Las dos rondas siguientes son la referencia actual de lo que realmente se ha ejercitado de extremo a extremo. Una nota histórica sobre el primer depósito en vivo, mayo de 2026, sigue al final de esta sección.

Validación de extremo a extremo, agosto de 2026 (EVIDE ANCHOR)

v1.3.0 se ejercitó a través de cinco escenarios en lenguaje natural dados a un cliente MCP real (Claude Desktop), cada uno produciendo un depósito genuino y un Registro de Artefacto Evidencial descargado — no una re-ejecución de los constructores de forma aislada.

ejercitado	resultado
Admisión estándar, sin extensiones	depositado; FCC `unknown` (ver nota a continuación)
`evide_intake` con `evidence_references`	artefacto externo anclado — puntero, origen y campos de hash todos poblados exactamente como se declararon, archivo nunca subido
`evide_intake_esb` con `evide_buffer_observe` / `evide_buffer_close`	buffer abierto y cerrado; el agente lo cerró temprano para la demostración y lo dijo en `buffer_notes`, en lugar de presentar una ventana acortada como una real
`evide_intake` con `declarations`	declaración de perímetro operativo (entorno, declarante, marca de tiempo, atribución) preservada exactamente como se indicó
`evide_intake_esb` con `evidence_references`, `declarations` y un buffer juntos	los tres depositados en el mismo registro sin conflicto

FCC leyó unknown en cada escenario, incluido el destinado a mostrar un estado estable. Ninguno de los cinco avisos declaró un límite verificado de forma independiente (boundary_status: verified con un readiness_gate real) — sin uno, runtime_visibility permanece nulo y FCC no puede leer nada más que unknown. Este es el modelo funcionando como se diseñó, no un defecto: refleja la ausencia de una compuerta de preparación declarada de forma independiente en los escenarios de prueba, no un problema en el código.

Un agente, en un escenario combinado, fusionó dos hechos independientes en una sola Declaración (declaration_type: "environment_and_privilege") en lugar de dos separadas. Aceptado por el esquema — declaration_type es texto libre por diseño — pero es exactamente el caso que la Regla de Declaración Atómica anterior existe para desalentar: una Declaración fusionada no puede luego ser reemplazada o corregida de forma independiente para solo uno de los hechos que agrupa. Esta observación se informa como una nota de implementación, no como una propiedad general de los LLM.

Este fue un agente (Claude, a través de Claude Desktop) ejecutado una vez a través de cada escenario — no una afirmación sobre cómo se comportaría cualquier LLM en general. Dentro de ese alcance, el agente pobló cada campo opcional correctamente, incluidos objetos anidados (authority_source, hash), sin requerir una plantilla de carga útil predefinida.

Validación de extremo a extremo, julio de 2026

v1.2.0 se ejercitó a través de un cliente MCP real a lo largo de la ruta completa — cliente, JSON-RPC sobre stdio, constructores de carga útil, transporte HTTP, API de Admisión de EVIDE — en lugar de re-ejecutar los constructores de forma aislada.

ejercitado	resultado
`evide_intake` con una declaración de hash incompleta	rechazado en el cliente, antes de cualquier llamada de red
`evide_intake` con `verified_partial` y sin compuerta declarada	rechazado en el cliente
`evide_intake` con un hash estructurado y `boundary_status: candidate`	depositado; FCC, DWC y FAC todos `unknown`, como se esperaba sin compuerta independiente
`evide_intake_esb` -> dos `evide_buffer_observe` -> `evide_buffer_close`	ciclo de vida completo sobre una ventana real de 502 segundos, con un `stabilization_score` declarado
Aún no ejercitado en esa ruta: `evide_escalate`, `evide_owner_info`, `evide_check` y los parámetros de la cadena. Un defecto en el manejador de `evide_escalate` —el valor predeterminado propio de la herramienta sobrescribió silenciosamente `boundary_status` a `verified_partial`, por lo que cualquier escalada sin un estado explícito fallaba por falta de una compuerta de preparación— fue encontrado mediante revisión de código inmediatamente después, precisamente porque no formaba parte de esta ejecución. Se corrigió el mismo mes, el 29 de julio de 2026 (commit `f4d0481`): el manejador ahora usa por defecto `candidate`, coincidiendo con el constructor, y el esquema de la herramienta expone los cuatro estados límite. La distinción entre lo que se ha ejecutado y lo que solo se ha leído se mantiene aquí por la misma razón por la que se mantiene en los propios registros probatorios.

Primera cristalización en vivo, mayo de 2026 (histórica)

Primera cristalización probatoria de agente en vivo, mediante Claude Desktop + MCP —superada por las dos rondas de validación anteriores, se conserva aquí para el registro.

continuity.state:    degraded
boundary_readiness:  verified_partial
unresolved_signals:  8
FCC:                 DEGRADED

El registro preservó un estado de gobernanza degradado sin aplanar la inestabilidad en una falsa certeza.

LinkedIn -- Primera Cristalización Probatoria de Agente en Vivo

Documentación

Autor

Dott. Emanuel Celano -- Informatica in Azienda info@informaticainazienda.it Bolonia, Italia

Licencia

MIT

El uso de este servidor requiere una identidad DAPI válida y una suscripción activa a EVIDE. Condiciones del servicio: app.certifywebcontent.com/pricing#service-conditions

EVIDE MCP

Documentación

Servidor EVIDE MCP v1.4.0

Novedades en v1.4.0

Novedades en v1.3.0

Requisitos previos -- Leer antes de instalar

1. DAPI -- Identidad Verificada

2. Clave API de EVIDE -- Suscripción Activa

Qué Deposita EVIDE

Instalación

Configuración

Variables de Entorno

Herramientas

evide_intake

Regla de Declaración Atómica

evide_escalate

evide_owner_info

evide_check

execution_identity -- Contexto de Ejecución Declarado

Contexto de ejecución a nivel de implementación

Identificadores específicos de ejecución en tiempo de llamada

Límite

Buffer de Estabilización Epistémica

Preparación de Límites y la Compuerta Independiente

Alcance de las Abstracciones Actuales

Principio Arquitectónico

Validación en Vivo

Validación de extremo a extremo, agosto de 2026 (EVIDE ANCHOR)

Validación de extremo a extremo, julio de 2026

Primera cristalización en vivo, mayo de 2026 (histórica)

Documentación

Autor

Licencia

`evide_intake`

`evide_escalate`

`evide_owner_info`

`evide_check`

`execution_identity` -- Contexto de Ejecución Declarado