EVIDE MCP

Camada externa de cristalização probatória para governança de IA, ancoragem de responsabilidade e registros de decisão verificáveis de forma independente.

GitHubExperimente este MCPPatrocinado

Documentação

Servidor EVIDE MCP v1.4.0

Servidor MCP que conecta agentes de IA à API do Depósito Evidencial Externo EVIDE.

O EVIDE cristaliza decisões de agentes de IA, escalonamentos e estados de governança em registros forenses verificáveis de forma independente — ancorados a uma identidade humana verificada, com carimbo de tempo no servidor em UTC e externalizados antes que a propagação de consequências comece.

O EVIDE não é uma camada de controle de execução. É uma camada externa de cristalização evidencial que opera no limite de fechamento de responsabilidade.

Novidades na v1.4.0

execution_identity expandido. Três novos descritores de nível de implantação (model_reference, agent_name, deployment_id) e dois novos identificadores específicos de execução, no momento da chamada (session_id, run_id). Todos os cinco são opcionais.
session_id e run_id são apenas no momento da chamada. Eles são aceitos como argumentos opcionais diretamente em evide_intake, evide_escalate e evide_intake_esb — não há equivalente de variável de ambiente para eles, por design, pois variam por chamada e não por implantação.
Placeholders gerados por software removidos. agent_unspecified e Unknown Agent System não aparecem mais dentro de execution_identity. Um campo opcional não definido agora é omitido, não preenchido — a ausência permanece ausência.
accountability_model: "owner_bound" inalterado. Ainda codificado de forma fixa, nunca derivado de nenhum campo de execution_identity. Consulte execution_identity -- Contexto de Execução Declarado abaixo para o limite completo.
Suíte de testes de regressão dedicada. Novos testes cobrem registros mínimos/expandidos/estilo legado, rejeição de apenas espaços em branco, propagação no momento da chamada e compatibilidade retroativa com registros históricos.
Endurecimento do limite de documentação e visualização de solicitações. Esclarecido, neste README e no aplicativo EVIDE, que identificadores de contexto de execução declarados não são identidade verificada do agente e não alteram quem é responsável por um depósito.
Totalmente compatível com versões anteriores. Um registro construído exatamente como na v1.3.0 permanece válido na v1.4.0 sem modificação.

Novidades na v1.3.0

EVIDE ANCHOR. declarations em evide_intake, evide_escalate e evide_intake_esb: declarações explícitas, atribuíveis e com limite de tempo do perímetro operacional (ambiente, privilégios, propósito, ferramentas, operações proibidas, configuração do agente) dentro do qual o agente estava autorizado, antes de agir. O EVIDE preserva apenas a declaração — nunca verifica sua correção, aplica-a como política ou a compara com o comportamento observado.
EVIDE Schema 2.1. Versões anteriores declaravam evide_schema: 2.0 e eram rejeitadas pela produção com unsupported_schema em cada depósito. Se você clonou antes de julho de 2026, sua cópia não conseguia depositar nada.
Continuidade Evidencial. parent_evide_id, chain_type e matter_reference em ambas as ferramentas de depósito, com os quatro códigos de recusa documentados.
Artefatos Externos. evidence_references com declaração estruturada de hash; o registro extensions é mantido alinhado pelo cliente.
Buffer de Estabilização Epistêmica. Três novas ferramentas: evide_intake_esb, evide_buffer_observe, evide_buffer_close.
Prontidão de Limite alinhada com declaração de portão independente. candidate agora é o padrão para ambas as ferramentas, e o cliente não fabrica mais um readiness_gate.
O cliente não completa mais declarações que pertencem a outra pessoa. hashed_by, readiness_gate, unresolved_signals e stabilization_score nunca são preenchidos em nome do chamador: um campo ausente falha a chamada em vez de ser inventado.

Pré-requisitos — Leia Antes de Instalar

Ambos os pré-requisitos são obrigatórios. O servidor não iniciará sem eles.

1. DAPI — Identidade Verificada

O EVIDE não aceita depósitos anônimos. Todo registro deve ser atribuível a uma identidade humana verificada.

DAPI (Atestação Digital de Identidade Pessoal) é a camada de identidade que vincula cada depósito a uma identidade verificada e atribuível. O número DAPI pertence ao humano ou à organização responsável pelo agente de IA — não ao próprio agente. O agente não pode se autoatestar.

O EVIDE não determina se a decisão em si estava correta. Ele preserva as condições de responsabilidade e governança externamente reconstruíveis presentes no momento do fechamento, tornando-as examináveis de forma independente.

Como obter um DAPI: dapi-certification.com

A verificação DAPI exige: 1 documento de identidade válido, 1 foto facial, 1 arquivo de áudio com voz, 1 vídeo curto. O processamento é manual. Reserve tempo antes de planejar sua integração.

2. Chave de API EVIDE — Assinatura Ativa

O acesso à API de entrada do EVIDE exige um plano ativo e uma chave de API dedicada (evd_...).

Planos e preços: app.certifywebcontent.com/pricing

Planos disponíveis: Entry (10 entradas/mês), Starter (75), Professional (200), Enterprise (500). Para volumes acima de 500 entradas/mês, é necessária infraestrutura dedicada — entre em contato antes de ativar.

O Que o EVIDE Deposita

Cada registro ancora:

a identidade da autoridade responsável (proprietário vinculado ao DAPI)
a identidade de execução do agente (arquiteturalmente separada do proprietário)
o estado de classificação e a estabilidade operacional no fechamento
a prontidão de limite e a superfície de visibilidade do portão
o nível de supervisão humana declarado no fechamento
sinais não resolvidos que não puderam ser confirmados no momento da travessia

O perfil evidencial calculado pelo servidor (profile_version: 1.1) inclui:

Dim 9 — Verificação Cruzada Forense — inferência de continuidade (classificação x visibilidade de execução) — sensor anti-Coerência Sintética
Dim 10 — Compressão de Onda de Decisão (DWC) — detecção de limite de vazão de supervisão
Dim 11 — Colapso Formal de Responsabilidade (FAC) — detecção de fragmentação de autoridade

Importante: O perfil evidencial contém sinais de governança inferidos. Esses sinais são indicadores probabilísticos de governança, não determinações judiciais ou acusações de má conduta. Um estado detected ou critical para DWC ou FAC indica uma condição estrutural presente no momento do fechamento — não constitui uma constatação de irregularidade por qualquer parte.

Instalação

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

Node.js >= 18 é necessário.

Configuração

Adicione à configuração do seu cliente MCP (claude_desktop_config.json ou 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"
      }
    }
  }
}

Variáveis de Ambiente

Variável	Obrigatória	Descrição
`EVIDE_API_KEY`	Sim	Sua chave de API EVIDE (`evd_...`)
`EVIDE_DAPI_NUMBER`	Sim	Seu número DAPI de 10 dígitos
`EVIDE_OWNER_ID`	Sim	Seu identificador no sistema de origem
`EVIDE_OWNER_ROLE`	Não	Descrição da função. Padrão: `AI System Operator`
`EVIDE_AGENT_SYSTEM`	Não	Nome do sistema do agente. Omitido de `execution_identity` se não definido — nenhum placeholder é substituído.
`EVIDE_AGENT_ID`	Não	Identificador da instância do agente. Omitido de `execution_identity` se não definido — nenhum placeholder é substituído.
`EVIDE_MODEL_REFERENCE`	Não	Nome/versão do modelo declarado em uso (ex.: `claude-sonnet-4-6-20260514`). Novo na v1.4.0.
`EVIDE_AGENT_NAME`	Não	Rótulo legível por humanos para o agente (ex.: `Legal Intake Agent`). Novo na v1.4.0.
`EVIDE_DEPLOYMENT_ID`	Não	Identificador desta implantação/versão específica do agente, distinto do `EVIDE_AGENT_ID` estável. Novo na v1.4.0.

session_id e run_id não são variáveis de ambiente. Eles variam por chamada e são aceitos como argumentos opcionais no momento da chamada nas próprias ferramentas de depósito — consulte execution_identity -- Contexto de Execução Declarado abaixo.

Ferramentas

`evide_intake`

Deposite uma decisão finalizada de IA como um 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"
}

Mantenha decision_summary curto — ele se torna o título do registro. Ele é armazenado e exibido como está, sem gerenciamento de comprimento no lado do servidor: um decision_summary do tamanho de um parágrafo se torna um título do tamanho de um parágrafo, e valores muito longos podem ser truncados pelo armazenamento subjacente de maneiras que cortam um título no meio de uma palavra. Trate-o como um rótulo de uma linha, não como uma narrativa.

Para a explicação mais completa — por que a decisão foi tomada, o que era ambíguo, quais evidências foram ponderadas — use o campo opcional rationale em vez disso. Ele existe exatamente para esse propósito e não tem expectativa prática de comprimento como um título tem.

{
  "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."
}

Artefatos externos opcionais (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"
    }
  ]
}

O EVIDE ancora a declaração de que um artefato existe — o arquivo em si nunca é enviado, e o EVIDE nunca calcula ou verifica seu hash. É por isso que hashed_by é obrigatório sempre que um hash é declarado: um resumo ancorado sem proveniência declarada seria inútil. O cliente valida isso antes que a solicitação saia, então um campo ausente produz uma mensagem que o nomeia em vez de uma rejeição genérica do servidor. Nada é inferido: hashed_by nunca é preenchido com a identidade do agente, porque afirmar que o agente calculou um resumo que ele apenas retransmitiu seria uma falsa alegação de proveniência.

Declarar a matriz define automaticamente extensions: ["evidence_references"]. Esse registro é opt-in em ambas as direções — um bloco presente, mas não declarado, é rejeitado, e uma declaração sem conteúdo também é rejeitada — então o cliente mantém os dois alinhados por construção.

Declarações opcionais de perímetro operacional (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"
    }
  ]
}

Uma Declaração é uma afirmação explícita, atribuível e com limite de tempo do perímetro operacional (ambiente, privilégios, propósito, ferramentas, operações proibidas, configuração do agente) dentro do qual um agente estava autorizado, antes de agir. O EVIDE preserva apenas a declaração — nunca verifica sua correção, aplica-a como política ou a compara com o comportamento observado. Este é o primitivo por trás do incidente que o motivou: um agente que confunde um banco de dados de produção com um ambiente de teste descartável é exatamente o caso em que um environment_classification declarado torna reconstruível de forma independente após o fato.

Este esquema de nível MCP é deliberadamente simplificado em relação à API completa: declaration_type, declared_value, declarant, declared_at, declared_description e um declared_attribution_status achatado são expostos aqui. subject_references, authority_source.references e declared_relations aninhados (declarando que uma Declaração substitui, esclarece ou revoga outra) não são — eles permanecem disponíveis através da API de entrada direta para chamadores que precisam da forma aninhada.

declaration_digest é calculado no lado do servidor, não por este cliente. Para cada Declaração, a API calcula SHA-256("EVIDE_DECLARATION_V1:" + canonical_json(Declaration)) no momento da entrada e o retorna como parte do registro armazenado. O cliente MCP nunca calcula ou envia esse valor — ele não tem campo declaration_digest no esquema da ferramenta acima. Isso dá a cada Declaração sua própria evidência de adulteração, independente do intake_hash geral da entrada, e é o que declared_relations na referência completa da API quando uma Declaração substitui outra.

Declarar a matriz define automaticamente extensions: ["declarations"], usando o mesmo registro opt-in que evidence_references — ambos podem ser declarados juntos no mesmo depósito.

Regra de Declaração Atômica

Cada Declaração deve representar uma única afirmação atribuível. Quando uma solicitação descreve múltiplos fatos independentes — por exemplo, tanto uma classificação de ambiente quanto um escopo de privilégio — cada um deve ser preservado como sua própria Declaração, não mesclado em um só.

Valores compostos de declaration_type (ex.: environment_and_privilege) são aceitos pelo esquema — declaration_type é texto livre por design — mas desencorajados: uma declaração mesclada não pode ser posteriormente substituída, esclarecida ou revogada independentemente dos fatos que ela agrupa. Se a classificação de ambiente mudar, mas o escopo de privilégio não, apenas a Declaração environment_classification deve ser substituída — isso se torna impossível uma vez que os dois são combinados em um só. Parâmetros opcionais de encadeamento (Continuidade 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"
}

O uso natural é passar o evide_id retornado por um evide_escalate anterior como parent_evide_id no depósito que o resolve — produzindo uma linhagem declarada de "o agente parou aqui" até "foi assim que foi encerrado".

A validação de encadeamento é estrita e não possui fallback silencioso. Se o pai não existir, pertencer a outro domínio evidencial, estiver em um status não encadeável ou declarar um matter_reference diferente, todo o depósito é recusado em vez de iniciar silenciosamente uma nova cadeia. As recusas são chain_parent_not_found (422), chain_parent_not_owned (403 — uma decisão de autorização, não um erro de payload), chain_parent_invalid_status (422) e chain_matter_mismatch (422).

Retorna: evide_id, intake_hash, intake_timestamp_utc, profile_version, estado de Verificação Cruzada Forense, estados DWC e FAC quando presentes e — quando o registro continua a partir de outro — chain_position, chain_type e chain_root_evide_id.

`evide_escalate`

Cristalize o estado do agente antes de prosseguir em uma fronteira de alto risco ou contestável.

{
  "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 aceita os mesmos parâmetros opcionais de encadeamento, evidence_references e declarations que evide_intake, para o caso em que uma escalada continua a partir de outra.

agent_state_summary alimenta o mesmo campo de título que decision_summary acima — mantenha-o curto pelo mesmo motivo. O quadro mais completo pertence a escalation_reason, que já existe exatamente para isso.

Gatilhos disponíveis: high_stakes_decision · contestable_state · legal_ambiguity · regulatory_threshold · governance_uncertainty · semantic_instability · human_review_required · authority_incoherence

`evide_owner_info`

Retorna o proprietário configurado e a identidade do agente. Não expõe a chave de API completa.

`evide_check`

Retorna orientações de verificação para um registro depositado anteriormente.

`execution_identity` — Contexto de Execução Declarado

Todo depósito feito por meio de evide_intake, evide_escalate e evide_intake_esb inclui um bloco execution_identity. Ele separa a identidade do proprietário responsável (sob authority, vinculado à DAPI) do contexto de execução declarado (agente, modelo, sessão, execução — conforme fornecido). Apenas type e accountability_model estão sempre presentes; todos os outros campos são opcionais e simplesmente omitidos quando não disponíveis.

Contexto de execução no nível de implantação

Estático por configuração de cliente, definido uma vez por meio das variáveis de ambiente acima e inalterado em todas as chamadas dessa implantação:

agent_id
agent_system
model_reference
agent_name
deployment_id

Identificadores específicos de execução no momento da chamada

Dinâmicos, aceitos como argumentos opcionais diretamente em evide_intake, evide_escalate e evide_intake_esb:

session_id
run_id

session_id e run_id:

são opcionais;
são fornecidos pelo chamador;
entram por meio da própria chamada de ferramenta, neste cliente MCP — não há equivalente por variável de ambiente para eles;
não são gerados pela EVIDE;
não são autenticados pela EVIDE;
não constituem identidade de agente verificada.

Registro mínimo (sem contexto opcional declarado):

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

Registro totalmente declarado, incluindo contexto no momento da chamada:

{
  "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"
  }
}

Fronteira

execution_identity preserva identificadores de contexto de execução declarados ou fornecidos externamente. Sua presença não verifica de forma independente a identidade, autenticidade, proveniência ou controle do agente, modelo, sessão ou execução referenciados.

accountability_model: "owner_bound" permanece codificado e registra que, dentro do modelo evidencial da EVIDE, a responsabilidade pelo depósito permanece associada ao proprietário verificado pela DAPI, em vez de ser transferida ao agente referenciado.

Nenhum campo opcional é jamais preenchido com um valor substituto. Se um valor não estiver disponível, ele é omitido — a ausência permanece ausência.

Buffer de Estabilização Epistêmica

Três ferramentas adicionais permitem que um agente conduza todo o ciclo de vida do ESB:

ferramenta	o que faz
`evide_intake_esb`	deposita o encerramento e abre um buffer sobre ele. Retorna `buffer_id`.
`evide_buffer_observe`	registra uma observação intermediária enquanto o buffer está aberto. Pode ser chamada mais de uma vez.
`evide_buffer_close`	fecha o buffer com um veredito.

O encerramento é ancorado imediatamente, exatamente como com evide_intake: o buffer abre junto a ele, não o atrasa nem o substitui. O que o buffer acrescenta é a trajetória — como as condições se estabilizaram ao longo de uma janela real, em vez de apenas como estavam no momento da travessia.

Uma janela de observação real é obrigatória. O servidor recusa um fechamento que ocorra menos de dois segundos após a abertura, porque um buffer que fecha instantaneamente não observou nada. A janela medida retorna como window_seconds. test_mode: true contorna isso e é exposto apenas porque o servidor o aceita: um buffer fechado em modo de teste não observou uma janela real, e o registro não fingirá o contrário.

stabilization_score é declarado, nunca calculado. Nem a EVIDE nem este cliente o calculam. Valores fora do intervalo são rejeitados em vez de limitados, porque a limitação ocultaria um erro do cliente. Se você não tiver base para uma pontuação, omita-a — o cliente não fornece uma em seu nome. O mesmo princípio já se aplicava a hashed_by e readiness_gate.

Os campos de fase são aplicados no lado do cliente. buffer/update e buffer/close aceitam conjuntos de chaves diferentes. Enviar stabilization_score a uma observação, ou stability_trend a um fechamento, é recusado com uma mensagem nomeando a ferramenta à qual pertence — em vez de ser silenciosamente descartado, que é o que a própria API fazia até julho 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"

Prontidão de Fronteira e o Portão Independente

Intakes originados por agente usam boundary_readiness: candidate por padrão. Na ausência de um portão de prontidão declarado de forma independente, FCC, DWC e FAC podem permanecer unknown. Isso é um resultado evidencial, não uma falha de processamento.

boundary_readiness declara se um portão independente avaliou a fronteira. Um agente depositante não é esse portão: ele não pode atestar sua própria prontidão em uma fronteira, assim como um sistema não pode se autoatestar. O cliente, portanto, nunca fabrica um — readiness_gate_id e readiness_gate_scope devem vir do chamador, e qualquer status diferente de candidate é recusado sem eles.

O mesmo se aplica a unresolved_signals, que carrega os identificadores que um portão não conseguiu resolver durante sua avaliação. Com candidate, o array é vazio por definição, não por restrição: nenhuma avaliação ocorreu, então nada poderia ter ficado em aberto. O que o agente não conseguiu decidir é uma coisa diferente e vive em escalation_reason e agent_state_summary.

Este é o ciclo de vida pretendido, e já é assim que integrações independentes usam o esquema em produção:

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

O agente nunca precisa se passar pelo portão. O mesmo princípio já se aplicava a hashed_by: o cliente não inventa uma declaração que pertence a outra pessoa.

Escopo das Abstrações Atuais

As abstrações MCP atuais expõem intencionalmente apenas os tipos de intervenção exigidos pelas ferramentas implementadas (approval para evide_intake, escalation para evide_escalate). Semânticas de intervenção adicionais — por exemplo, override ou rejection — serão introduzidas apenas quando um fluxo de trabalho concreto de agente as exigir, em vez de especular sobre casos de uso futuros.

O mesmo raciocínio se aplica a human_oversight.is_declared, que é sempre true. Isso não é um atalho: o servidor não pode iniciar sem um número DAPI, então todo depósito feito por meio dele é, por construção, atribuível a um humano responsável declarado. Não há caminho anônimo a deixar aberto. O nível de supervisão permanece uma escolha do chamador (L1 / L2 / L3); apenas a existência de uma autoridade declarada é fixa, porque o próprio transporte a garante.

Princípio Arquitetural

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

A responsabilidade é vinculada ao proprietário: ela permanece associada, dentro do modelo evidencial da EVIDE, ao proprietário verificado pela DAPI, em vez de ser transferida ao agente referenciado. O agente não pode se autoatestar.

Validação ao Vivo

As duas rodadas abaixo são a referência atual para o que foi efetivamente exercitado de ponta a ponta. Uma nota histórica sobre o primeiro depósito ao vivo, maio de 2026, segue no final desta seção.

Validação de ponta a ponta, agosto de 2026 (EVIDE ANCHOR)

A v1.3.0 foi exercitada por meio de cinco cenários em linguagem natural dados a um cliente MCP real (Claude Desktop), cada um produzindo um depósito genuíno e um Registro de Artefato Evidencial baixado — não uma reexecução dos construtores isoladamente.

exercitado	resultado
Intake padrão, sem extensões	depositado; FCC `unknown` (ver nota abaixo)
`evide_intake` com `evidence_references`	artefato externo ancorado — ponteiro, origem e campos de hash todos preenchidos exatamente como declarados, arquivo nunca enviado
`evide_intake_esb` com `evide_buffer_observe` / `evide_buffer_close`	buffer aberto e fechado; o agente o fechou cedo para a demonstração e disse isso em `buffer_notes`, em vez de apresentar uma janela encurtada como real
`evide_intake` com `declarations`	declaração de perímetro operacional (ambiente, declarante, timestamp, atribuição) preservada exatamente como declarada
`evide_intake_esb` com `evidence_references`, `declarations` e um buffer juntos	todos os três depositados no mesmo registro sem conflito

FCC leu unknown em todos os cenários, incluindo o que pretendia mostrar um estado estável. Nenhum dos cinco prompts declarou uma fronteira verificada de forma independente (boundary_status: verified com um readiness_gate real) — sem uma, runtime_visibility permanece nulo e a FCC não pode ler nada além de unknown. Isso é o modelo funcionando como projetado, não um defeito: reflete a ausência de um portão de prontidão declarado de forma independente nos cenários de teste, não um problema no código.

Um agente, em um cenário combinado, fundiu dois fatos independentes em uma única Declaração (declaration_type: "environment_and_privilege") em vez de duas separadas. Aceito pelo esquema — declaration_type é texto livre por design — mas é exatamente o caso que a Regra de Declaração Atômica acima existe para desencorajar: uma Declaração fundida não pode ser posteriormente substituída ou corrigida de forma independente para apenas um dos fatos que ela agrupa. Esta observação é relatada como uma nota de implementação, não como uma propriedade geral de LLMs.

Este foi um agente (Claude, via Claude Desktop) executado uma vez em cada cenário — não uma afirmação sobre como qualquer LLM se comportaria em geral. Dentro desse escopo, o agente preencheu corretamente todos os campos opcionais, incluindo objetos aninhados (authority_source, hash), sem exigir um modelo de payload predefinido.

Validação de ponta a ponta, julho de 2026

A v1.2.0 foi exercitada por meio de um cliente MCP real ao longo do caminho completo — cliente, JSON-RPC sobre stdio, construtores de payload, transporte HTTP, API de Intake da EVIDE — em vez de reexecutar os construtores isoladamente.

exercitado	resultado
`evide_intake` com uma declaração de hash incompleta	recusado no cliente, antes de qualquer chamada de rede
`evide_intake` com `verified_partial` e sem portão declarado	recusado no cliente
`evide_intake` com um hash estruturado e `boundary_status: candidate`	depositado; FCC, DWC e FAC todos `unknown`, como esperado sem portão independente
`evide_intake_esb` -> dois `evide_buffer_observe` -> `evide_buffer_close`	ciclo de vida completo ao longo de uma janela real de 502 segundos, com um `stabilization_score` declarado
Ainda não exercitado nesse caminho: `evide_escalate`, `evide_owner_info`, `evide_check` e os parâmetros da cadeia. Um defeito no handler `evide_escalate` — o padrão próprio da ferramenta sobrescreveu silenciosamente `boundary_status` para `verified_partial`, então qualquer escalada sem um status explícito falhava por falta de uma barreira de prontidão — foi encontrado por revisão de código imediatamente depois, justamente porque não fazia parte desta execução. Foi corrigido no mesmo mês, em 29 de julho de 2026 (commit `f4d0481`): o handler agora usa como padrão `candidate`, alinhado ao builder, e o schema da ferramenta expõe todos os quatro estados de fronteira. A distinção entre o que foi executado e o que foi apenas lido é mantida aqui pela mesma razão pela qual é mantida nos próprios registros probatórios.

Primeira cristalização ao vivo, maio de 2026 (histórico)

Primeira cristalização probatória ao vivo de agente, via Claude Desktop + MCP — superada pelas duas rodadas de validação acima, mantida aqui para registro.

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

O registro preservou um estado de governança degradado sem achatar a instabilidade em uma falsa certeza.

LinkedIn -- Primeira Cristalização Probatória ao Vivo de Agente

Documentação

Autor

Dott. Emanuel Celano -- Informatica in Azienda info@informaticainazienda.it Bolonha, Itália

Licença

MIT

O uso deste servidor requer uma identidade DAPI válida e uma assinatura EVIDE ativa. Condições de serviço: app.certifywebcontent.com/pricing#service-conditions

EVIDE MCP

Documentação

Servidor EVIDE MCP v1.4.0

Novidades na v1.4.0

Novidades na v1.3.0

Pré-requisitos — Leia Antes de Instalar

1. DAPI — Identidade Verificada

2. Chave de API EVIDE — Assinatura Ativa

O Que o EVIDE Deposita

Instalação

Configuração

Variáveis de Ambiente

Ferramentas

evide_intake

Regra de Declaração Atômica

evide_escalate

evide_owner_info

evide_check

execution_identity — Contexto de Execução Declarado

Contexto de execução no nível de implantação

Identificadores específicos de execução no momento da chamada

Fronteira

Buffer de Estabilização Epistêmica

Prontidão de Fronteira e o Portão Independente

Escopo das Abstrações Atuais

Princípio Arquitetural

Validação ao Vivo

Validação de ponta a ponta, agosto de 2026 (EVIDE ANCHOR)

Validação de ponta a ponta, julho de 2026

Primeira cristalização ao vivo, maio de 2026 (histórico)

Documentação

Autor

Licença

`evide_intake`

`evide_escalate`

`evide_owner_info`

`evide_check`

`execution_identity` — Contexto de Execução Declarado