PRD-045 — Agentic Evidence & Audit Intelligence Fabric

1. Objetivo

O PRD-045 cria a camada responsável por transformar dados, eventos, documentos, registros e resultados de controles em evidências confiáveis, rastreáveis e utilizáveis para auditoria.

O sistema deverá ser capaz de responder:

O que aconteceu?

Quando aconteceu?

Quem estava envolvido?

Qual regra estava vigente?

Qual controle foi executado?

Qual evidência comprova o resultado?

Essa evidência ainda é válida?

Podemos reproduzir a conclusão posteriormente?

2. Princípio Fundamental

Uma informação não é automaticamente uma evidência.

Uma evidência precisa possuir contexto, origem, temporalidade, integridade e relação explícita com aquilo que pretende comprovar.

DATA
 ↓
SOURCE
 ↓
PROVENANCE
 ↓
EVIDENCE
 ↓
VALIDATION
 ↓
TRUST
 ↓
CONTROL
 ↓
COMPLIANCE

3. Problema que o PRD-045 Resolve

Atualmente o sistema poderá saber:

Training = VALID

Mas uma auditoria poderá perguntar:

Qual registro?
De qual sistema?
Obtido quando?
Qual era a validade?
Quem emitiu?
Qual versão do sistema?
O dado foi alterado?
Qual controle utilizou?
Qual requisito regulamentar estava sendo atendido?

O Evidence Fabric deverá responder a todas essas perguntas.

4. Evidence vs Data vs Fact

Esses conceitos não podem ser confundidos.

Conceito	Significado
Data	valor armazenado
Fact	fato estabelecido pelo sistema
Evidence	material que sustenta um fato
Control Result	resultado de uma verificação
Compliance Conclusion	conclusão sobre conformidade

Exemplo:

training.validUntil = 2026-10-15

é data.

Training is valid on 2026-09-01

é um fact.

O registro oficial do LMS utilizado para demonstrar isso é a evidence.

5. Evidence Registry

Todos os elementos relevantes deverão possuir registro único.

interface EvidenceRecord {
  evidenceId: string;

  tenantId: string;

  type: EvidenceType;

  source: EvidenceSource;

  subjectRefs: string[];

  observedAt: string;

  capturedAt: string;

  validFrom?: string;

  validUntil?: string;

  provenance: EvidenceProvenance;

  integrity: EvidenceIntegrity;

  status: EvidenceStatus;
}

6. Evidence Types

O Registry deverá suportar:

DATABASE_RECORD
API_RESPONSE
DOCUMENT
CERTIFICATE
TRAINING_RECORD
INSPECTION
MEASUREMENT
APPROVAL
SIGNATURE
PHOTO
VIDEO
SYSTEM_EVENT
AUDIT_RECORD
CONTROL_RESULT
USER_ATTESTATION
EXTERNAL_RECORD
REPORT

7. Evidence Source

interface EvidenceSource {
  sourceId: string;

  sourceType:
    | "BUSINESS_API"
    | "DATABASE"
    | "EVENT"
    | "EXTERNAL_SYSTEM"
    | "DOCUMENT"
    | "USER"
    | "SYSTEM";

  authorityLevel: string;

  sourceVersion?: string;
}

8. Provenance

Toda evidência deverá responder:

WHERE DID IT COME FROM?

interface EvidenceProvenance {
  sourceId: string;

  collectedBy: string;

  collectedAt: string;

  method: string;

  transformationChain: string[];

  originalReference?: string;
}

9. Transformation Chain

Se um documento gerar um fato:

Document
 ↓
Parser
 ↓
Extraction
 ↓
Normalization
 ↓
Fact

essa cadeia deverá permanecer registrada.

10. No Hidden Transformation

O sistema não poderá produzir:

Evidence A

a partir de:

Document B

sem preservar a relação entre ambos.

11. Evidence Integrity

interface EvidenceIntegrity {
  hash?: string;

  algorithm?: string;

  signature?: string;

  signedBy?: string;

  integrityStatus:
    | "VERIFIED"
    | "UNVERIFIED"
    | "FAILED";
}

12. Hash

Quando aplicável:

SHA-256(document)

poderá ser utilizado para detectar alteração.

O hash não prova, sozinho, autenticidade.

13. Authenticity

Autenticidade deverá considerar:

source authority
+
authentication
+
digital signature
+
trusted system
+
chain of custody

14. Chain of Custody

Para evidências relevantes:

CREATED
 ↓
CAPTURED
 ↓
TRANSFERRED
 ↓
STORED
 ↓
USED
 ↓
ARCHIVED

Cada transição poderá gerar um evento de custódia.

15. Custody Event

interface EvidenceCustodyEvent {
  custodyEventId: string;

  evidenceId: string;

  action:
    | "CREATED"
    | "CAPTURED"
    | "TRANSFERRED"
    | "ACCESSED"
    | "EXPORTED"
    | "ARCHIVED";

  actor: PrincipalRef;

  timestamp: string;

  integrityHash?: string;
}

16. Evidence Lifecycle

DISCOVERED
 ↓
CAPTURED
 ↓
VALIDATING
 ↓
VALID
 ↓
USED
 ↓
EXPIRED
 ↓
ARCHIVED

Também:

REJECTED
COMPROMISED
REVOKED

17. Evidence Status

VALID
INVALID
EXPIRED
STALE
REVOKED
COMPROMISED
PENDING_VALIDATION
UNKNOWN

18. Expired ≠ Invalid

Uma evidência pode continuar autêntica, mas não ser válida para o período atual.

Exemplo:

Training Certificate

Authentic: YES
ValidUntil: 2026-08-31
CurrentDate: 2026-09-01

Evidence:
VALID RECORD
BUT
EXPIRED FOR CURRENT COMPLIANCE

19. Evidence Freshness

Freshness deverá ser independente de validade.

Freshness = quão recentemente o dado foi observado
Validity = até quando ele é válido

20. Evidence Quality

Cada evidência poderá possuir:

interface EvidenceQuality {
  authorityScore: number;

  freshnessScore: number;

  integrityScore: number;

  completenessScore: number;

  authenticityScore: number;

  reliabilityScore: number;
}

21. Trust ≠ Quality

O Trust Engine do PRD-029 continua sendo responsável pela avaliação global.

O Evidence Fabric fornece os sinais necessários.

Evidence Quality
        ↓
Trust Evaluation
        ↓
Trust Score

22. Evidence Sufficiency

Uma única evidência pode não ser suficiente.

Exemplo:

Employee says:
"I completed the training."

pode ser insuficiente.

Mas:

LMS record
+
certificate
+
completion event

poderá formar um conjunto suficiente.

23. Evidence Bundle

interface EvidenceBundle {
  bundleId: string;

  tenantId: string;

  purpose: string;

  evidenceRefs: string[];

  requirementRefs: string[];

  controlRefs: string[];

  createdAt: string;
}

24. Evidence Chain

Uma conclusão poderá possuir:

Requirement
 ↓
Control
 ↓
Evaluation
 ↓
Evidence
 ↓
Source

Essa cadeia deverá ser navegável.

25. Evidence Graph

Dentro do HAG/Knowledge Graph:

Requirement
   ↓
Control
   ↓
Evaluation
   ↓
Evidence
   ↓
Source

26. Semantic IDs

Novos IDs:

compliance.evidence
compliance.evidence.source
compliance.evidence.bundle
compliance.evidence.chain
compliance.evidence.custody
compliance.audit
compliance.audit.package

27. Evidence → Requirement

Cada evidência relevante poderá estar associada diretamente a requisitos:

requirementRefs: [
  "reg.nrXX.requirement.123"
]

28. Evidence → Control

controlRefs: [
  "control.workPermit.trainingValidity"
]

29. Evidence → Entity

subjectRefs: [
  "employee:EMP-100",
  "workPermit:WP-1001"
]

30. Point-in-Time Evidence

Uma das funcionalidades mais importantes será responder:

“Mostre a evidência existente em 15 de agosto.”

O sistema deverá considerar:

observedAt
validFrom
validUntil
createdAt
revokedAt
sourceVersion

31. Historical Reconstruction

Será possível reconstruir:

Estado
+
Requisitos vigentes
+
Controles vigentes
+
Evidências existentes
+
Políticas vigentes

em determinado instante.

32. Audit Snapshot

interface AuditSnapshot {
  snapshotId: string;

  tenantId: string;

  asOf: string;

  regulationVersion: string;

  controlVersion: string;

  policyVersion: string;

  knowledgeVersion: string;

  organizationVersion: string;

  evidenceRefs: string[];
}

33. Audit Package

O sistema deverá gerar um pacote estruturado:

AUDIT PACKAGE
 ├── Scope
 ├── Requirements
 ├── Controls
 ├── Evaluations
 ├── Evidence
 ├── Exceptions
 ├── Remediations
 ├── Approvals
 ├── Responsibilities
 └── Audit Trail

34. Audit Package Model

interface AuditPackage {
  packageId: string;

  tenantId: string;

  scope: AuditScope;

  snapshotId: string;

  requirementRefs: string[];

  controlRefs: string[];

  evidenceRefs: string[];

  exceptionRefs: string[];

  remediationRefs: string[];

  generatedAt: string;
}

35. Audit Scope

Poderá ser:

TENANT
FACILITY
DEPARTMENT
PROCESS
WORK_PERMIT
EMPLOYEE
REGULATION
REQUIREMENT
CONTROL
DATE_RANGE

36. Audit Readiness

O sistema deverá calcular:

READY
PARTIALLY_READY
NOT_READY

37. Audit Readiness Score

Exemplo:

Requirements covered: 100%
Controls tested: 98%
Evidence valid: 96%
Evidence fresh: 94%
Open critical gaps: 0

Audit readiness:
READY

38. Evidence Gap

Quando um controle existe mas não possui evidência adequada:

CONTROL
 ↓
PASS
 ↓
Evidence missing

isso deverá gerar:

EVIDENCE_GAP

dependendo das regras do domínio.

39. Evidence Gap ≠ Compliance Failure

Importante:

Compliance failure

Evidence insufficiency

são problemas diferentes.

Uma operação pode ter ocorrido corretamente, mas não possuir evidência suficiente para demonstrá-lo.

40. Evidence Corroboration

O sistema poderá buscar evidências independentes:

LMS
+
HR
+
Training Certificate
+
Event

para corroborar um fato.

41. Conflicting Evidence

Exemplo:

LMS:
VALID

Certificate:
EXPIRED

O sistema deverá produzir:

EVIDENCE_CONFLICT

e encaminhar para:

Trust Engine
+
Decision Intelligence

42. Never Hide Conflict

O Agent não deverá escolher silenciosamente:

LMS = true

e ignorar:

Certificate = false

O conflito precisa permanecer visível.

43. Evidence Authority

Quando houver conflito, poderá ser aplicada uma hierarquia:

Official Regulatory Source
       ↓
Authoritative Business System
       ↓
Verified External System
       ↓
Controlled Document
       ↓
Human Attestation
       ↓
LLM Inference

Essa hierarquia será configurável por domínio.

44. Evidence Retention

Cada tipo de evidência deverá possuir política:

interface EvidenceRetentionPolicy {
  evidenceType: string;

  retentionPeriod: string;

  archiveAfter?: string;

  legalHoldSupported: boolean;
}

45. Legal Hold

Uma evidência sob retenção legal não poderá ser eliminada pela política normal de expiração.

Retention
     +
Legal Hold
     ↓
Protected

46. Evidence Deletion

Nunca apagar uma evidência crítica sem:

policy
+
authorization
+
audit
+
retention check
+
legal hold check

47. Evidence Redaction

Evidências poderão conter dados sensíveis.

O sistema deverá suportar:

FULL
REDACTED
MASKED
METADATA_ONLY

48. Auditor Access

Um auditor não deverá necessariamente receber todos os dados existentes.

O pacote deverá respeitar:

tenant
scope
authorization
sensitivity
purpose

49. Evidence Export

Exportações deverão ser auditadas:

Evidence Accessed
Evidence Exported
Audit Package Generated

50. Evidence Download

O acesso ao documento original deverá passar por autorização novamente.

Nunca utilizar:

public URL

para evidências privadas.

51. Object Storage

Arquivos grandes poderão ser armazenados em:

R2 / Object Storage

enquanto:

D1

mantém metadados e índices.

52. Evidence Metadata

O sistema não deverá duplicar desnecessariamente documentos grandes.

D1
 ↓
metadata
 ↓
R2
 ↓
binary evidence

53. Evidence Search

Pesquisa deverá utilizar:

Exact
Keyword
BM25
Graph
Vector
Temporal
Entity
Control
Requirement

reaproveitando o PRD-003.

54. Evidence Retrieval

Exemplo:

“Mostre as evidências que comprovam que o WP-1001 podia ser liberado.”

Fluxo:

WP-1001
 ↓
Compliance
 ↓
Controls
 ↓
Evaluations
 ↓
Evidence
 ↓
Evidence Chain

55. Natural Language Audit

O Agent poderá responder:

“Por que esse Work Permit estava conforme?”

com:

Requirement
 ↓
Applicable Rule
 ↓
Controls
 ↓
Evidence
 ↓
Conclusion

56. Evidence Explanation

A resposta deverá apresentar:

Conclusion
Evidence
Source
Timestamp
Validity
Control

e não uma cadeia interna de raciocínio do modelo.

57. Audit Question

Pergunta:

“Quem aprovou?”

Resposta deverá vir de:

Approval
+
Identity
+
Responsibility
+
Audit Event

não de inferência.

58. Audit Question

“Qual regra estava vigente?”

Consultar:

Regulatory Version
+
Effective Date

via PRD-043.

59. Audit Question

“Qual controle detectou o problema?”

Consultar:

Control Evaluation

via PRD-044.

60. Audit Question

“Quando o problema foi corrigido?”

Consultar:

Remediation
+
Event
+
Control Re-evaluation

61. Audit Timeline

O Auditor deverá visualizar:

01 Training valid
15 Work Permit created
20 Control passed
30 Training expired
31 Control failed
32 Attention created
10 Training renewed
11 Control passed
12 Compliance restored

62. Timeline vs Audit Trail

São diferentes.

Timeline
= visão operacional

Audit Trail
= registro formal e imutável

63. Evidence Version

Quando uma evidência for atualizada:

Evidence v1
Evidence v2
Evidence v3

deverão permanecer historicamente relacionadas quando a política de retenção exigir.

64. Revocation

Uma evidência poderá ser revogada:

Certificate
 ↓
Issuer reports fraud
 ↓
Evidence REVOKED

Isso deverá disparar reavaliação dos controles dependentes.

65. Evidence Revocation Event

EvidenceRevoked
 ↓
Dependent Controls
 ↓
Reevaluation
 ↓
Compliance Impact

66. Impact Graph

O Knowledge Graph deverá permitir:

Evidence
 ↓
Control
 ↓
Requirement
 ↓
Work Permit
 ↓
Employees

e calcular o impacto.

67. Evidence Blast Radius

Exemplo:

Revoked certificate
 ↓
1 employee
 ↓
7 training records
 ↓
23 Work Permits
 ↓
3 controls
 ↓
1 regulatory requirement

68. Automatic Impact Management

O sistema deverá criar:

Compliance Gap
Attention
Remediation
Goal Task

conforme as políticas.

69. Evidence Monitoring

Evidências importantes poderão ser monitoradas continuamente.

Evidence
 ↓
Expiration
 ↓
Temporal Event
 ↓
Control

70. Evidence Expiration

Exemplo:

Training expires in 30 days

gera:

EvidenceExpiringSoon

que alimenta o PRD-021.

71. Evidence Quality Monitoring

O sistema deverá detectar:

stale evidence
missing evidence
conflicting evidence
revoked evidence
low-quality evidence
source unavailable

72. Evidence Source Health

Uma fonte poderá estar:

HEALTHY
DEGRADED
UNAVAILABLE
UNKNOWN

Se o LMS estiver indisponível, isso deverá ser diferenciado de:

Employee has no training

73. Evidence Acquisition

Quando permitido, o Agent poderá solicitar atualização:

Evidence stale
 ↓
External Gateway
 ↓
LMS
 ↓
New evidence
 ↓
Control

74. Capability Boundary

A aquisição deverá utilizar:

Capability Registry
+
Policy Engine
+
Identity/Delegation
+
External Gateway

75. Automated Evidence Collection

Collectors poderão ser registrados:

interface EvidenceCollectorDefinition {
  collectorId: string;

  sourceType: string;

  capabilityId: string;

  schema: JSONSchema;

  freshnessPolicy: string;

  evidenceType: EvidenceType;
}

76. No Arbitrary Collector

O Agent não poderá:

fetch("https://some-url")

para buscar evidência.

Toda coleta deve passar por uma integração registrada.

77. Evidence Certification

Evidências críticas poderão receber:

UNCERTIFIED
REVIEWED
VERIFIED
CERTIFIED

78. Human Verification

Quando necessário:

Evidence
 ↓
Human Reviewer
 ↓
VERIFY
 ↓
Evidence status

79. Certification ≠ Truth Forever

Uma evidência certificada continua sujeita a:

expiration
revocation
new information
regulatory change
source correction

80. Audit Package Generation

A geração deverá ser determinística.

Scope
 ↓
Snapshot
 ↓
Requirements
 ↓
Controls
 ↓
Evidence
 ↓
Exceptions
 ↓
Remediation
 ↓
Audit Package

81. Package Integrity

O pacote poderá possuir:

packageHash
manifest
generatedAt
snapshotId
version

82. Package Manifest

interface AuditPackageManifest {
  packageId: string;

  generatedAt: string;

  snapshotId: string;

  evidenceCount: number;

  requirementCount: number;

  controlCount: number;

  hash: string;
}

83. Auditor Workspace

Nova área semântica:

compliance.audit
compliance.audit.scope
compliance.audit.requirements
compliance.audit.controls
compliance.audit.evidence
compliance.audit.gaps
compliance.audit.timeline
compliance.audit.package

84. Auditor Navigation

O Agent poderá receber:

“Abra a evidência que comprova esse controle.”

e navegar através de Semantic UI IDs, nunca através de URLs arbitrárias.

85. Audit Search

Filtros:

Requirement
Control
Employee
Work Permit
Evidence Type
Source
Validity
Date
Status
Risk

86. Audit Readiness Analysis

O Agent poderá produzir:

Requirements: 127
Controls: 119
Evidence complete: 113
Evidence missing: 6
Critical gaps: 0
Conflicts: 2

Readiness:
PARTIALLY_READY

87. Evidence Gap Remediation

Para cada gap:

Evidence Gap
 ↓
Responsible
 ↓
Attention
 ↓
Task
 ↓
Evidence Collection
 ↓
Verification

88. Evidence Quality Improvement

O sistema poderá recomendar:

“Este controle possui apenas uma declaração manual. Existe uma integração disponível com o LMS para obter evidência oficial.”

Essa recomendação passa por:

Recommendation
 ↓
Human/Policy
 ↓
Capability
 ↓
Implementation

89. LLM Usage

LLM poderá ajudar em:

document classification
evidence extraction
semantic matching
audit summary
conflict explanation
gap explanation

Não poderá decidir sozinho:

authenticity
legal validity
critical compliance
audit acceptance

90. Prompt Injection Defense

Documentos são dados.

Nunca:

document text
 ↓
instruction

O conteúdo de uma evidência não poderá alterar:

Policy
Capability
Authorization
Audit rules

91. Multi-Tenant Isolation

Toda evidência deverá possuir:

tenantId

e o backend deverá verificar novamente o tenant.

92. Cross-Tenant Protection

Não permitir:

tenant A evidence
       ↓
tenant B query

mesmo que:

Vector similarity

seja alta.

93. Cache Isolation

Caches deverão incluir:

tenantId
+
evidence scope
+
authorization context

94. Audit Security

A consulta:

“Mostre todas as evidências”

deverá ser tratada como operação autorizada.

95. Evidence Access Audit

Registrar:

WHO
WHAT
WHEN
WHY
WHICH EVIDENCE
WHICH SCOPE

96. Observability

Métricas:

Evidence Collection Latency
Evidence Validation Rate
Evidence Failure Rate
Evidence Freshness
Evidence Conflict Rate
Evidence Gap Rate
Evidence Revocation Rate
Audit Package Generation Time
Audit Readiness

97. Cost

Prioridade:

metadata
 ↓
indexed retrieval
 ↓
cached evidence
 ↓
incremental collection
 ↓
external API
 ↓
LLM

98. Large Audit

Para auditorias grandes:

Audit Scope
 ↓
Partition
 ↓
Parallel Evidence Retrieval
 ↓
Aggregate
 ↓
Integrity Check
 ↓
Package

99. Audit Reproducibility

O mesmo:

snapshotId

deverá produzir o mesmo conjunto lógico de evidências, considerando as versões registradas.

100. Regulatory Change

Quando PRD-043 detectar:

Requirement changed

o Evidence Fabric deverá identificar:

Evidence requirements changed

e possíveis lacunas.

101. Example

Nova regulamentação exige:

training evidence must include completion date

O sistema procura:

existing evidence
 ↓
does completionDate exist?

Se não:

EVIDENCE_SCHEMA_GAP

102. Evidence Schema Version

interface EvidenceSchemaVersion {
  schemaId: string;

  version: string;

  fields: JSONSchema;

  effectiveFrom: string;

  effectiveUntil?: string;
}

103. Schema Evolution

Mudanças de evidência deverão passar por:

PRD-043
 ↓
Impact Analysis
 ↓
Evidence Schema
 ↓
Control Tests
 ↓
Evaluation

104. Historical Audit

Uma auditoria histórica não deverá utilizar automaticamente a regra atual.

Deverá reconstruir:

regulationVersion
controlVersion
policyVersion
evidenceVersion
organizationVersion

vigentes naquele momento.

105. Evidence Snapshot

2026-08-01
 ↓
Regulation v4
Control v2
Policy v7
Evidence snapshot

106. Audit Conclusion

O sistema deverá conseguir produzir:

interface AuditConclusion {
  conclusionId: string;

  scope: AuditScope;

  status:
    | "COMPLIANT"
    | "NON_COMPLIANT"
    | "PARTIALLY_COMPLIANT"
    | "INSUFFICIENT_EVIDENCE"
    | "INCONCLUSIVE";

  requirementRefs: string[];

  evidenceRefs: string[];

  controlRefs: string[];

  generatedAt: string;
}

107. INSUFFICIENT_EVIDENCE

Essa categoria é fundamental.

O sistema não deve transformar:

lack of evidence

automaticamente em:

non-compliance

sem que o requisito/policy determine isso.

108. Auditor Question → Evidence Graph

QUESTION
   ↓
SCOPE
   ↓
REQUIREMENTS
   ↓
CONTROLS
   ↓
EVALUATIONS
   ↓
EVIDENCE
   ↓
PROVENANCE
   ↓
CONCLUSION

109. First Vertical Slice

Work Permit + Training

Controle:

control.workPermit.trainingValidity

110. Evidence

A evidência deverá ser:

LMS Training Record

contendo:

employeeId
trainingId
courseId
completedAt
validFrom
validUntil
status
sourceSystem
sourceVersion

111. Evidence Chain

Regulatory Requirement
        ↓
Training Control
        ↓
Evaluation
        ↓
LMS Record
        ↓
Employee
        ↓
Work Permit

112. Normal Scenario

Training valid
 ↓
Control PASS
 ↓
Evidence VALID
 ↓
Compliance COMPLIANT

113. Expired Training

Training expires
 ↓
Evidence still authentic
 ↓
Validity expired
 ↓
Control FAIL
 ↓
Compliance NON_COMPLIANT

114. LMS Unavailable

LMS unavailable
 ↓
Cannot obtain fresh evidence
 ↓
Evidence UNKNOWN/STALE
 ↓
Control UNKNOWN

A Policy poderá decidir:

BLOCK

ou:

REQUIRES_REVIEW

115. Revoked Certificate

Certificate
 ↓
Issuer revokes
 ↓
Evidence REVOKED
 ↓
Dependent Controls
 ↓
Reevaluation

116. Audit Query

Pergunta:

“Mostre por que WP-1001 foi liberado em 1º de agosto.”

Resposta estruturada:

Work Permit:
WP-1001

Release:
2026-08-01 14:22

Required Controls:
5

Passed:
5

Evidence:
12 records

Critical Exceptions:
0

Policy:
v17

Control Version:
v4

Compliance:
COMPLIANT

seguida das evidências correspondentes.

117. Acceptance Criteria

Evidência parcial de implementação — 2026-09-04

O contrato evidence-audit-governance separa validade, freshness, integridade, autenticidade, qualidade e confiança; identifica evidência stale, indisponível, comprometida ou revogada sem inferir não conformidade. Ele exige suficiência e corroboracão explícitas, mantém conflitos visíveis, cria snapshots canônicos point-in-time com versões fixadas e calcula readiness sem ocultar gaps críticos. As rotas autenticadas e a migration 0119_evidence_audit_governance.sql persistem profiles, gaps, conflitos, eventos e dispatches tenant-scoped, com guards append-only para os ledgers. Os 18 testes focados de contrato e rotas passaram em 2026-09-04.

Ainda faltam nesta evidência uma coleta real por fonte externa, validação de assinatura e cadeia de custódia de um provedor, inspeção de migration no D1 remoto, auditoria humana de um pacote e um vertical Work Permit completo. Assim, os critérios marcados representam cobertura implementada, não prova independente de aceitação externa.

118. Resultado Arquitetural

O SST passa a possuir uma cadeia completa de evidência:

REGULATION
     ↓
REQUIREMENT
     ↓
CONTROL
     ↓
CONTROL TEST
     ↓
EVALUATION
     ↓
EVIDENCE
     ↓
PROVENANCE
     ↓
TRUST
     ↓
COMPLIANCE
     ↓
AUDIT

E, mais importante, o sistema passa a conseguir reconstruir por que uma determinada conclusão de conformidade foi produzida, utilizando evidências verificáveis e versionadas.

Isso fecha uma lacuna importante dos PRDs anteriores:

PRD-042
Conhecemos o requisito.

PRD-043
Entendemos o impacto da mudança.

PRD-044
Executamos o controle continuamente.

PRD-045
Provamos, preservamos e reconstruímos a evidência.

119. Implementação Entregue

A entrega fecha o ciclo de governança de evidência sem transferir autoridade ao LLM ou ao coletor:

engine determinístico separa lifecycle, validity, freshness, integrity, authenticity, quality, certification, sufficiency e conflito;
treze endpoints autenticados cobrem fontes, schemas, perfis, assessments, certificações, snapshots, packages, coleta, blast radius, grafo, readiness, histórico e query preview;
snapshots point-in-time e packages mantêm manifesto canônico e hash SHA-256 imutáveis;
payload privado permanece em R2, com metadados tenant-safe, leitura limitada a 4 MiB, assinatura ECDSA P-256 e export redigido sem URL pública;
coleta externa só registra pedido policy-bound para capability ativa e gateway conhecido, sem fetch arbitrário;
consultas naturais são somente leitura, estruturadas, auditadas e rejeitam prompt injection;
cada assessment, package e plano de impacto grava receipts para 13 fabrics, sempre com authorityGranted=false e authorizesExecution=false.

A migration 0119_evidence_audit_governance.sql acrescenta 17 tabelas, 42 triggers de escopo/imutabilidade/retenção e 19 índices explícitos. O replay isolado aplicou as 119 migrations sem erro e confirmou esses mesmos totais.

120. Prova Local e Cloudflare

Verificação local final:

gate Evidence/Audit: 11 arquivos e 39 testes;
gate de exceções agentic: 52 arquivos e 254 testes;
predeploy: 53 arquivos e 297 testes, além do manifesto de 12 recursos semânticos, 9 capabilities e 27 bindings;
suíte integral: 449 arquivos aprovados, 1 ignorado; 7.227 testes aprovados, 10 ignorados;
typecheck de todos os workspaces e Wrangler dry-run aprovados;
bundle Worker: 4.621,15 KiB, 766,88 KiB gzip.

Em Cloudflare, a migration 0119 executou 79 comandos. A consulta remota confirmou 119 migrations, 17 tabelas, 42 triggers e 19 índices. O deploy canônico publicou o Worker 11a5ea04-f32e-4057-bd6e-4c0c7920e5c4; /health respondeu HTTP 200 com Durable Objects, D1, KV, R2, Vectorize e Queue ativos, e os quatro Workflows foram reconciliados.

O Pages https://49164179.elioria-sst-x-docs.pages.dev publicou as referências de rota e engine com HTTP 200 text/html (7.912 e 7.944 bytes). O /openapi.json respondeu HTTP 200 application/json com 454.545 bytes e exatamente os 13 endpoints de governança. A alias de branch também respondeu HTTP 200.

O canário público usou o tenant sintético c8338515-ecfb-4665-8671-93c8e4f087a6 e provou:

seis records e sete assessments, distinguindo VALID, STALE, UNKNOWN, EXPIRED ainda autêntico e REVOKED ainda autêntico;
conflito visível, gap por evolução de schema e insuficiência distinta de não conformidade;
três snapshots e três packages reproduzíveis, terminando em READY, score 1, SUFFICIENT e COMPLIANT sem inferência;
R2 privado, ECDSA P-256, export redigido, legal hold e quatro tentativas de adulteração/retenção rejeitadas;
143 dispatches para os 13 fabrics, consulta read-only auditada, prompt injection rejeitada, isolamento de tenant e acesso anônimo negado;
capability externa ACTIVE, sem coleta arbitrária, e zero autoridade de execução;
cleanup PostgreSQL com zero linhas residuais; os ledgers D1 sintéticos permanecem intencionalmente imutáveis como prova operacional.

Em 2026-09-06, a regressão atual de ledger, governança, export, fabric, payloads, assinaturas e health de fontes de evidência passou com 17 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A classificação PROVEN_CLOUDFLARE permanece sustentada pelo canário remoto registrado.

121. Incidente Detectado pelo Canário

A primeira execução válida do package revelou que a projeção SQL do perfil omitia schema_version, classificando assessments reais como incompatíveis. Foi criado teste de regressão, a consulta passou a carregar schema_id e schema_version, os gates foram reexecutados e o Worker foi republicado antes da prova final. A proteção point-in-time que rejeitou uma cronologia inválida permaneceu intacta.

PRD-046 — Agentic Audit, Inspection & Regulatory Examination Workspace

O próximo nível será transformar toda essa infraestrutura em uma experiência operacional completa para auditorias, inspeções e fiscalizações.

O PRD-046 deverá abordar:

AUDIT PLANNING
      ↓
AUDIT SCOPE
      ↓
AUDIT PROGRAM
      ↓
REQUIREMENTS
      ↓
CONTROLS
      ↓
EVIDENCE REQUESTS
      ↓
AUDITOR WORKSPACE
      ↓
FINDINGS
      ↓
NONCONFORMITIES
      ↓
OBSERVATIONS
      ↓
QUESTIONS
      ↓
MANAGEMENT RESPONSE
      ↓
CORRECTIVE ACTION
      ↓
FOLLOW-UP
      ↓
CLOSURE

E deverá permitir que um auditor ou responsável interno converse naturalmente com o sistema, por exemplo:

“Prepare uma auditoria dos requisitos aplicáveis aos trabalhos em altura realizados nos últimos 90 dias.”

ou:

“Quais não conformidades ainda estão abertas e quais evidências estão faltando para encerrá-las?”

ou ainda:

“Simule como um auditor externo avaliaria nossa conformidade com esses requisitos.”

A partir daí, o Agentic Work deixará de apenas monitorar compliance e produzir evidências e passará a operar um verdadeiro Audit & Inspection Workspace inteligente, conectado diretamente ao Compliance Fabric, Evidence Fabric, Responsibility Fabric, Decision Intelligence, Workflow, Attention Center e Regulatory Intelligence.

1. Objetivo​

2. Princípio Fundamental

3. Problema que o PRD-045 Resolve

4. Evidence vs Data vs Fact

5. Evidence Registry

6. Evidence Types

7. Evidence Source

8. Provenance

9. Transformation Chain

10. No Hidden Transformation

11. Evidence Integrity

12. Hash

13. Authenticity

14. Chain of Custody

15. Custody Event

16. Evidence Lifecycle

17. Evidence Status

18. Expired ≠ Invalid

19. Evidence Freshness

20. Evidence Quality

21. Trust ≠ Quality

22. Evidence Sufficiency

23. Evidence Bundle

24. Evidence Chain

25. Evidence Graph

26. Semantic IDs

27. Evidence → Requirement

28. Evidence → Control

29. Evidence → Entity

30. Point-in-Time Evidence

31. Historical Reconstruction

32. Audit Snapshot

33. Audit Package

34. Audit Package Model

35. Audit Scope

36. Audit Readiness

37. Audit Readiness Score

38. Evidence Gap

39. Evidence Gap ≠ Compliance Failure

40. Evidence Corroboration

41. Conflicting Evidence

42. Never Hide Conflict

43. Evidence Authority

44. Evidence Retention

45. Legal Hold

46. Evidence Deletion

47. Evidence Redaction

48. Auditor Access

49. Evidence Export

50. Evidence Download

51. Object Storage

52. Evidence Metadata

53. Evidence Search

54. Evidence Retrieval

55. Natural Language Audit

56. Evidence Explanation

57. Audit Question

58. Audit Question

59. Audit Question

60. Audit Question

61. Audit Timeline

62. Timeline vs Audit Trail

63. Evidence Version

64. Revocation

65. Evidence Revocation Event

66. Impact Graph

67. Evidence Blast Radius

68. Automatic Impact Management

69. Evidence Monitoring

70. Evidence Expiration

71. Evidence Quality Monitoring

72. Evidence Source Health

73. Evidence Acquisition

74. Capability Boundary

75. Automated Evidence Collection

76. No Arbitrary Collector

77. Evidence Certification

78. Human Verification

79. Certification ≠ Truth Forever

80. Audit Package Generation

1. Objetivo

Work Permit + Training

Evidência parcial de implementação — 2026-09-04