Comece pelo registro.
Mantenha o contrato explícito.

Um registro que um revisor pode acompanhar.

Um registro de evidência útil conecta a fonte, o contexto, a política e a referência autoritativa do recibo. O exemplo abaixo é explicativo. Não é um esquema publicado de solicitação de API.

{
  "record_kind": "illustrative_example",
  "tenant_scope": "demo-workspace",
  "source": "Fonte de exemplo (apenas ilustrativo)",
  "context": [
    "Contexto de exemplo (apenas ilustrativo)"
  ],
  "policy": "Support escalation v3.2",
  "receipt_reference": "demo_rct_7v2a\u2026e91c",
  "verification_status": "not_a_live_receipt"
}

Mantenha cada referência significativa.

Fonte

O material capturado como evidência e a referência necessária para inspecionar sua origem.

Contexto

Material recuperado e configuração disponíveis para o workflow registrado.

Política

O identificador ou versão da política associada ao evento.

Referência do recibo

Um identificador autoritativo retornado pelo backend de evidência, nunca inventado por um frontend de produção.

Escopo do tenant

A identidade do workspace aplicada pelo backend autenticado. Um valor fornecido pelo cliente não autoriza acesso.

Identidade antes da evidência.

A arquitetura de produto da PHIROK inclui fronteiras protegidas de MCP e gRPC. Autenticação, escopo de tenant e tratamento autoritativo de recibos fazem parte do contrato de integração.

• Resolva a identidade a partir do contexto autenticado do backend.
• Trate a retenção malsucedida como uma falha, não como um recibo verificado.
• Recupere registros por identificadores autoritativos.
• Mantenha o material de origem e seu contexto de verificação disponíveis.
• Mantenha fixtures de teste separados da evidência de produção.

Torne os critérios de aceitação observáveis.

Perguntas, respondidas.