PRD-042 — Agentic Compliance & Regulatory Intelligence Fabric

1. Objetivo

O PRD-042 cria a camada de inteligência regulatória e conformidade contínua do Agentic Work.

Até aqui, construímos a infraestrutura para que o sistema saiba:

quem é o usuário
quem é o responsável
quem possui autoridade
qual é o estado atual
qual é o conhecimento disponível
quais são as regras
quais ações podem ser executadas
quais workflows existem
quais eventos ocorreram
quais riscos existem
quais evidências estão disponíveis

O PRD-042 conecta esses elementos à pergunta fundamental de SST:

“A organização está em conformidade com aquilo que é aplicável a ela, neste momento, e conseguimos provar isso?”

2. Problema

Conhecer uma norma não significa estar em conformidade.

Por exemplo:

NORMA
 ↓
REQUISITO
 ↓
APLICABILIDADE
 ↓
CONTROLE
 ↓
RESPONSÁVEL
 ↓
EVIDÊNCIA
 ↓
ESTADO

O sistema precisa determinar:

APLICÁVEL?
      ↓
SIM
      ↓
REQUISITO ATENDIDO?
      ↓
SIM ─────────→ COMPLIANT
      │
      NÃO
      ↓
NON_COMPLIANT
      ↓
REMEDIAÇÃO

Além disso, o sistema precisa responder:

“Por que você considera isso não conforme?”

e apresentar evidências verificáveis.

3. Princípio Fundamental

Compliance não é uma opinião do Agent. É uma conclusão baseada em requisitos aplicáveis, controles definidos, evidências verificáveis, regras de avaliação e contexto temporal.

O LLM poderá auxiliar na interpretação, mas não deverá transformar uma interpretação probabilística em fato regulatório sem validação adequada.

4. Separação Fundamental

O sistema deverá distinguir:

REGULATION
REQUIREMENT
CONTROL
EVIDENCE
COMPLIANCE
RECOMMENDATION
DECISION

Eles não são equivalentes.

5. Regulation

Representa a fonte regulatória.

interface Regulation {
  regulationId: string;

  jurisdictionId: string;

  title: string;

  identifier?: string;

  source: RegulatorySource;

  version: string;

  publishedAt?: string;

  effectiveFrom: string;

  effectiveUntil?: string;

  status: RegulationStatus;
}

6. Regulatory Source

A origem poderá ser:

GOVERNMENT
REGULATORY_BODY
OFFICIAL_PUBLICATION
CONTRACTUAL
INTERNAL_POLICY
INDUSTRY_STANDARD
CUSTOMER_REQUIREMENT
LEGAL_OPINION

A autoridade da fonte deverá ser registrada.

7. Requirement

Uma Regulation será decomposta em requisitos operacionalizáveis.

interface ComplianceRequirement {
  requirementId: string;

  regulationId: string;

  title: string;

  description: string;

  obligationType: ObligationType;

  applicabilityRule?: string;

  effectiveFrom: string;

  effectiveUntil?: string;

  status: RequirementStatus;
}

8. Requirement Types

Exemplos:

MANDATORY
PROHIBITION
CONDITIONAL
REPORTING
TRAINING
INSPECTION
DOCUMENTATION
AUTHORIZATION
MONITORING
RECORD_KEEPING

9. Requirement ≠ Regulation

Uma norma poderá conter dezenas ou centenas de requisitos.

Regulation
 ├── Requirement A
 ├── Requirement B
 ├── Requirement C
 └── Requirement D

O Agent deverá operar principalmente sobre requisitos estruturados.

10. Applicability

Um requisito poderá ser aplicável somente sob determinadas condições.

Exemplo conceitual:

IF
  company.industry == INDUSTRIAL
  AND facility.hasHazardousOperation == true
THEN
  requirement = APPLICABLE

11. Applicability Engine

Fluxo:

REQUIREMENT
      ↓
JURISDICTION
      ↓
ORGANIZATION
      ↓
FACILITY
      ↓
ACTIVITY
      ↓
EMPLOYEES
      ↓
HAZARDS
      ↓
APPLICABILITY RULE
      ↓
APPLICABLE / NOT_APPLICABLE / UNKNOWN

12. UNKNOWN

A ausência de informação não deverá significar:

NOT_APPLICABLE

Deverá resultar em:

UNKNOWN

quando não for possível determinar a aplicabilidade.

13. Applicability Result

interface ApplicabilityResult {
  requirementId: string;

  status:
    | "APPLICABLE"
    | "NOT_APPLICABLE"
    | "UNKNOWN";

  evaluatedAt: string;

  effectiveAt: string;

  evidenceRefs: string[];

  reasonCodes: string[];

  confidence: number;
}

14. Jurisdiction

O sistema deverá modelar jurisdição.

COUNTRY
STATE
MUNICIPALITY
REGION
FACILITY
CONTRACTUAL_SCOPE

Um requisito poderá depender da localização da operação.

15. Jurisdiction Hierarchy

Brazil
 └── State
      └── Municipality
           └── Facility

16. Regulatory Version

Regulamentos mudam.

Portanto:

Regulation v1
      ↓
Regulation v2
      ↓
Regulation v3

não deverá destruir o histórico.

17. Temporal Compliance

O sistema deverá responder:

“Estávamos em conformidade em 15/05/2026?”

e não apenas:

“Estamos em conformidade agora?”

18. Point-in-Time Compliance

Fluxo:

timestamp
 ↓
applicable regulation version
 ↓
applicable requirements
 ↓
controls
 ↓
evidence available at timestamp
 ↓
compliance state

19. Control

Um Control é o mecanismo utilizado para atender um requisito.

interface ComplianceControl {
  controlId: string;

  tenantId: string;

  name: string;

  objective: string;

  controlType: ControlType;

  requirementRefs: string[];

  ownerResponsibilityId: string;

  frequency?: string;

  status: ControlStatus;
}

20. Control Types

PREVENTIVE
DETECTIVE
CORRECTIVE
AUTOMATED
MANUAL
HYBRID

21. Requirement → Control

Exemplo:

Requirement
    ↓
requires
    ↓
Training Control

Um requisito poderá possuir múltiplos controles.

22. Control → Requirement

Um controle também poderá atender vários requisitos:

Training Management Control
 ├── Requirement A
 ├── Requirement B
 └── Requirement C

23. Control Objective

Cada controle deverá possuir um objetivo mensurável.

Exemplo:

Objective:
Ensure every employee performing activity X
has valid required training.

24. Evidence

Compliance exige evidência.

interface ComplianceEvidence {
  evidenceId: string;

  tenantId: string;

  type: EvidenceType;

  sourceId: string;

  entityRefs: string[];

  observedAt: string;

  validFrom?: string;

  validUntil?: string;

  provenance: EvidenceProvenance;

  integrityHash?: string;
}

25. Evidence Types

DATABASE_RECORD
DOCUMENT
CERTIFICATE
TRAINING_RECORD
INSPECTION
MEASUREMENT
APPROVAL
PHOTO
SIGNATURE
SYSTEM_EVENT
API_RESPONSE
AUDIT_RECORD
USER_ATTESTATION

26. Evidence Provenance

Toda evidência deverá informar:

source
sourceVersion
observedAt
retrievedAt
createdAt
origin
integrity

27. Evidence Authority

Nem toda evidência possui a mesma força.

Exemplo conceitual:

Official system record
        >
User statement
        >
LLM inference

A hierarquia deverá ser configurável por domínio.

28. Evidence Freshness

Evidências poderão ser:

FRESH
STALE
EXPIRED
UNKNOWN

29. Evidence ≠ Compliance

Uma evidência apenas demonstra uma condição.

O Compliance Engine deverá avaliar:

Requirement
+
Control
+
Evidence
+
Temporal Context
+
Policy

30. Compliance State

Estados:

COMPLIANT
NON_COMPLIANT
PARTIALLY_COMPLIANT
AT_RISK
UNKNOWN
NOT_APPLICABLE
PENDING_REVIEW
EXEMPTED

31. Compliance Evaluation

Fluxo:

REQUIREMENT
      ↓
APPLICABILITY
      ↓
CONTROL
      ↓
EVIDENCE
      ↓
VALIDITY
      ↓
RULE EVALUATION
      ↓
COMPLIANCE STATE

32. Deterministic First

Sempre que possível:

SQL
+
rules
+
temporal logic
+
state

deverão determinar a conformidade.

LLM não deverá ser necessário para verificações objetivas.

33. Example

Required training:
valid

Employee:
active

Training:
expires in 90 days

Result:
COMPLIANT

34. Non-Compliance

Required training:
expired

Employee:
active

Activity:
still authorized

Result:
NON_COMPLIANT

35. Compliance Gap

interface ComplianceGap {
  gapId: string;

  requirementId: string;

  controlId?: string;

  tenantId: string;

  entityRefs: string[];

  severity: Severity;

  state: ComplianceState;

  detectedAt: string;

  dueAt?: string;

  evidenceRefs: string[];

  responsibilityRefs: string[];
}

36. Gap Severity

LOW
MEDIUM
HIGH
CRITICAL

A severidade deverá ser determinada por regras/policies.

Não pelo LLM isoladamente.

37. Compliance Risk

O Decision Engine poderá combinar:

requirement criticality
+
gap severity
+
exposure
+
duration
+
affected population
+
historical incidents

38. Compliance Risk Score

interface ComplianceRisk {
  score: number;

  severity: "LOW" | "MEDIUM" | "HIGH" | "CRITICAL";

  factors: RiskFactor[];

  evaluatedAt: string;
}

39. Responsibility Binding

Cada controle deverá indicar:

responsible
accountable

usando o PRD-041.

Assim:

Requirement
 ↓
Control
 ↓
Responsibility
 ↓
Person/Team

40. Compliance Accountability

Pergunta:

“Quem é responsável por corrigir esta não conformidade?”

O sistema resolve:

Gap
 ↓
Control
 ↓
Responsibility
 ↓
Current Assignment

41. Compliance Approval

Algumas ações corretivas poderão exigir aprovação.

Fluxo:

Gap
 ↓
Remediation Plan
 ↓
Policy
 ↓
Approver Resolution
 ↓
Approval Workspace

42. Remediation

Uma não conformidade deverá poder gerar uma tarefa de remediação.

interface RemediationTask {
  remediationId: string;

  gapId: string;

  objective: string;

  owner: PrincipalRef;

  dueAt?: string;

  status: RemediationStatus;

  verificationCriteria: VerificationCriterion[];
}

43. Remediation Lifecycle

DETECTED
 ↓
TRIAGED
 ↓
ASSIGNED
 ↓
IN_PROGRESS
 ↓
WAITING_VERIFICATION
 ↓
VERIFIED
 ↓
CLOSED

44. Verification

Corrigir não significa estar conforme.

Exemplo:

Training expired
 ↓
Training renewed
 ↓
Verification
 ↓
Compliance = COMPLIANT

45. Evidence After Remediation

A nova evidência deverá ser associada ao Gap.

Gap
 ├── originalEvidence
 └── remediationEvidence

46. Continuous Compliance

O sistema não deverá depender apenas de auditorias periódicas.

EVENT
 ↓
STATE CHANGE
 ↓
COMPLIANCE RE-EVALUATION

47. Event Integration

Eventos como:

TrainingExpired
EmployeeCreated
EmployeeTransferred
WorkPermitCreated
WorkPermitApproved
InspectionFailed
CertificationExpired
FacilityChanged

podem disparar avaliação.

48. Proactive Compliance

PRD-021 poderá executar:

scheduled compliance scans

antes que uma obrigação seja violada.

49. Temporal Compliance

PRD-037 fornece:

deadline
calendar
SLA
expiration
grace period

O Compliance Fabric utiliza esses elementos.

50. Example

Treinamento vence em:

30 days

Sistema:

T-30
→ reminder

T-15
→ action required

T-3
→ escalation

T+0
→ non-compliance

51. Compliance Attention

PRD-038 deverá transformar gaps relevantes em:

ACTION_REQUIRED
WARNING
ESCALATION
CRITICAL

52. Compliance Goal

PRD-036 poderá manter:

Goal:
Maintain 100% compliance
for active Work Permits

O progresso será baseado em evidências.

53. Compliance Decision

PRD-023 poderá responder:

“Podemos liberar este Work Permit?”

Com base em:

requirements
+
controls
+
evidence
+
risk
+
responsibility
+
policy

54. Compliance ≠ Authorization

Muito importante:

COMPLIANT

não significa automaticamente:

AUTHORIZED

Authorization continua sendo PRD-008.

55. Regulatory Interpretation

Alguns requisitos poderão ser textuais e complexos.

Nesse caso:

Regulatory Document
 ↓
Semantic Extraction
 ↓
Candidate Requirement
 ↓
Human Validation
 ↓
Requirement Registry

56. LLM Role

O LLM poderá:

identificar possíveis obrigações;
sugerir decomposição;
identificar entidades;
sugerir relações;
resumir requisitos;
encontrar possíveis conflitos;
sugerir applicability rules.

Mas não deverá publicar automaticamente um requisito regulatório crítico como válido.

57. Regulatory Certification

Requisitos extraídos deverão possuir:

DRAFT
REVIEWED
VERIFIED
CERTIFIED
SUPERSEDED
REVOKED

58. Human Review

Requisitos críticos poderão exigir:

legal review
safety review
compliance review

antes de entrarem em produção.

59. Regulatory Change Detection

Quando uma nova versão de uma fonte for detectada:

Old Regulation
        ↓
Change Detection
        ↓
Semantic Diff
        ↓
Affected Requirements
        ↓
Affected Controls
        ↓
Affected Workflows
        ↓
Affected Responsibilities

60. Regulatory Impact Analysis

O sistema deverá responder:

“O que será afetado por essa mudança?”

Exemplo:

Regulation changed
 ↓
12 requirements
 ↓
8 controls
 ↓
3 workflows
 ↓
42 responsibilities
 ↓
1,204 employees

61. Compliance Knowledge Graph

O HAG existente deverá incorporar relações:

REGULATION
   ↓
REQUIRES
   ↓
REQUIREMENT
   ↓
IMPLEMENTED_BY
   ↓
CONTROL
   ↓
OWNED_BY
   ↓
RESPONSIBILITY
   ↓
SUPPORTED_BY
   ↓
EVIDENCE

62. Semantic IDs

Exemplos:

compliance.regulation
compliance.requirement
compliance.control
compliance.evidence
compliance.gap
compliance.remediation

63. Entity Binding

Um requisito poderá estar relacionado a:

employee:EMP-100
workPermit:WP-1001
facility:FAC-10
training:TR-100
risk:RISK-22

64. Requirement-to-Entity

Exemplo:

Requirement R-001
       │
       ├── appliesTo → Facility A
       ├── appliesTo → Work Permit
       └── appliesTo → Employee

65. Compliance Query

O Agent poderá responder:

“Esse Work Permit está conforme?”

Fluxo:

User
 ↓
Intent
 ↓
Reference Resolution
 ↓
Requirement Applicability
 ↓
Controls
 ↓
Evidence
 ↓
Compliance Evaluation
 ↓
Answer

66. Explainable Answer

Resposta estruturada:

Status:
COMPLIANT

Requirements evaluated:
12

Requirements satisfied:
12

Evidence:
8 records

Last verification:
2026-09-01 15:32

Next relevant deadline:
2026-10-01

67. Non-Compliance Answer

Status:
NON_COMPLIANT

Requirement:
R-102

Reason:
Required training expired

Affected employee:
EMP-100

Evidence:
Training record

Responsible:
Training Coordinator

Recommended remediation:
Renew training

68. Evidence Chain

O sistema deverá conseguir apresentar:

Regulation
 ↓
Requirement
 ↓
Control
 ↓
Evidence
 ↓
Evaluation
 ↓
Compliance Result

Essa cadeia é fundamental para auditoria.

69. Trust Integration

PRD-029 fornece:

source authority
evidence quality
freshness
confidence

O Compliance Engine utiliza esses dados.

70. Unknown Evidence

Se uma evidência crítica não puder ser validada:

UNKNOWN

e não:

COMPLIANT

71. Conflict

Se duas fontes conflitarem:

Source A
→ compliant

Source B
→ non-compliant

o sistema deverá executar:

Trust Evaluation
+
Source Authority
+
Freshness
+
Policy

72. Conflict Resolution

Resultado possível:

RESOLVED
UNRESOLVED
REQUIRES_REVIEW

73. Regulatory Exception

Algumas situações poderão possuir exceções formais.

interface ComplianceException {
  exceptionId: string;

  requirementId: string;

  scope: string;

  reason: string;

  approvedBy: PrincipalRef;

  effectiveFrom: string;

  effectiveUntil: string;

  evidenceRefs: string[];

  status: string;
}

74. Exception ≠ Ignoring Requirement

Uma exceção deverá sempre ser:

explicit
authorized
time-bound
auditable

75. Compensating Control

Quando permitido:

Requirement
 ↓
Exception
 ↓
Compensating Control
 ↓
Evidence

O Agent nunca deverá inventar um controle compensatório.

76. Regulatory Deadline

Requirements poderão possuir:

dueAt
gracePeriod
reviewPeriod
renewalPeriod

Integrados ao Temporal Fabric.

77. Compliance Calendar

O sistema poderá gerar:

training deadlines
inspection deadlines
renewals
reports
certifications
reviews

78. Compliance Dashboard

Indicadores:

Overall Compliance
Critical Gaps
Expired Controls
Upcoming Deadlines
Unverified Evidence
Overdue Remediation
Regulatory Changes

79. Compliance Score

Um score agregado poderá existir, mas:

o score nunca substituirá os estados individuais de conformidade.

Exemplo:

Compliance Score = 94%

não significa que:

Critical Requirement = COMPLIANT

80. Critical Requirement Override

Uma única não conformidade crítica poderá impedir uma decisão mesmo que:

overallScore = 99%

81. Policy Integration

O Policy Engine poderá declarar:

IF
criticalRequirement != COMPLIANT
THEN
DENY workPermit.release

82. Capability Integration

Capabilities poderão declarar:

requiredComplianceChecks

antes da execução.

83. Execution Gate

Fluxo:

Capability
 ↓
Compliance Check
 ↓
Policy
 ↓
Authorization
 ↓
Execution

84. Workflow Integration

Workflows poderão possuir:

complianceGate

Exemplo:

SUBMITTED
 ↓
Compliance Check
 ↓
APPROVAL
 ↓
RELEASE

85. State Integration

PRD-035 deverá sincronizar:

business state
+
compliance state

Exemplo:

TrainingExpired
 ↓
Compliance = NON_COMPLIANT
 ↓
WorkPermit = BLOCKED

86. Exception Integration

PRD-024 tratará:

ComplianceEvaluationFailed
EvidenceUnavailable
RegulatorySourceUnavailable
ControlVerificationFailed

87. Responsibility Integration

PRD-041 fornecerá:

Responsible
Accountable
Approver
Escalation Owner

88. Resource Integration

PRD-039 poderá verificar:

qualified personnel

para atender controles.

89. Collaboration Integration

PRD-040 poderá criar:

Compliance Review Workspace

quando houver ambiguidade ou risco elevado.

90. Audit Integration

PRD-013 deverá registrar:

requirement evaluated
evidence used
policy version
compliance result
responsibility
decision
remediation
verification

91. No Chain-of-Thought

O sistema deverá registrar:

evidence
rules
decision factors
reason codes

e não raciocínio privado do modelo.

92. Compliance Reason Codes

Exemplos:

REQUIREMENT_APPLICABLE
REQUIREMENT_NOT_APPLICABLE
EVIDENCE_MISSING
EVIDENCE_EXPIRED
CONTROL_FAILED
CONTROL_VERIFIED
REGULATION_OUTDATED
REQUIREMENT_CONFLICT
REVIEW_REQUIRED
EXCEPTION_ACTIVE
REMEDIATION_OVERDUE

93. Multi-Tenant

Cada tenant poderá possuir:

custom controls
custom policies
organizational scope
internal procedures

sem contaminar outro tenant.

94. Global Regulatory Knowledge

Conhecimento regulatório global poderá ser compartilhado quando permitido.

Mas:

Global Regulation
≠
Tenant Applicability

Cada tenant deverá possuir sua própria avaliação de aplicabilidade.

95. Architecture

                REGULATORY SOURCES
                       │
                       ▼
                KNOWLEDGE FABRIC
                       │
                       ▼
              REQUIREMENT REGISTRY
                       │
                       ▼
              APPLICABILITY ENGINE
                       │
                       ▼
               CONTROL REGISTRY
                       │
                       ▼
               EVIDENCE FABRIC
                       │
                       ▼
            COMPLIANCE EVALUATOR
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
       COMPLIANT             GAP/RISK
                                 │
                                 ▼
                           REMEDIATION
                                 │
                                 ▼
                            VERIFICATION
                                 │
                                 ▼
                           COMPLIANCE

96. Data Model Summary

Principais entidades:

Regulation
RegulatorySource
Requirement
ApplicabilityRule
Jurisdiction
Control
ControlObjective
Evidence
EvidenceChain
ComplianceEvaluation
ComplianceState
ComplianceGap
ComplianceRisk
RemediationTask
ComplianceException
CompensatingControl
ComplianceSnapshot

97. Versioning

O Compliance Snapshot deverá registrar:

interface ComplianceSnapshot {
  snapshotId: string;

  tenantId: string;

  evaluatedAt: string;

  regulationVersion: string;

  knowledgeVersion: string;

  policyVersion: string;

  organizationVersion: string;

  stateVersion: string;

  results: ComplianceEvaluation[];
}

98. Reproducibility

O sistema deverá conseguir reproduzir:

“Por que em 10/08/2026 o sistema classificou esse Work Permit como conforme?”

utilizando as versões históricas correspondentes.

99. Regulatory Drift

Detectar:

regulation changed
control unchanged

pode indicar:

COMPLIANCE_DRIFT

100. Control Drift

Também:

Requirement unchanged
Control implementation changed

poderá gerar:

CONTROL_DRIFT

101. Evidence Drift

Se uma fonte deixar de fornecer dados:

Evidence source unavailable

o sistema deverá sinalizar:

EVIDENCE_DRIFT

e não assumir conformidade.

102. Continuous Control Monitoring

Controles automatizados poderão ser avaliados continuamente.

Exemplo:

Every Work Permit
→ training validity
→ authorization
→ required approval
→ required inspection

103. Automated Controls

Um controle poderá executar uma Capability de leitura:

compliance.control.evaluateTraining

e produzir evidência.

104. Control Execution

CONTROL
 ↓
CAPABILITY
 ↓
BUSINESS API
 ↓
RESULT
 ↓
EVIDENCE
 ↓
COMPLIANCE EVALUATION

105. Autonomous Remediation Boundary

O Agent poderá automaticamente corrigir:

low-risk
reversible
authorized
well-defined

situações.

Para operações críticas:

REQUIRES_HUMAN_REVIEW

106. Regulatory AI Safety

O Agent não poderá:

inventar requisito
alterar requisito
remover controle
ignorar não conformidade
alterar autoridade
criar exceção

sem passar pelos mecanismos formais correspondentes.

107. Testing

Testes deverão incluir:

applicability
temporal rules
regulatory version
evidence freshness
conflicting sources
missing evidence
control failure
remediation
verification
exceptions
tenant isolation
authorization
historical evaluation

108. Regulatory Regression Tests

Cada alteração regulatória deverá possuir testes:

Requirement
→ expected applicability
→ expected control
→ expected compliance

109. Simulation

Antes de publicar uma mudança:

NEW REGULATION
 ↓
SIMULATION
 ↓
IMPACT ANALYSIS
 ↓
AFFECTED TENANTS
 ↓
AFFECTED CONTROLS
 ↓
AFFECTED WORKFLOWS

110. First Vertical Slice

Work Permit + Training Compliance

Objetivo:

Determinar continuamente se um Work Permit possui todos os requisitos de treinamento atendidos.

111. Scenario

Employee EMP-100
      │
      ▼
Training TR-200
      │
      ▼
Work Permit WP-1001

112. Requirement

Requirement:
Employee performing activity must possess
valid required training.

113. Control

Control:
Validate required training before Work Permit release.

114. Evidence

Fonte:

LMS

através do PRD-025.

115. Evaluation

Training valid?
        │
       YES
        ↓
COMPLIANT

ou:

Training expired
        ↓
NON_COMPLIANT

116. Event Scenario

LMS envia:

TrainingExpired

PRD-020 publica:

TrainingStatusUpdated

117. Reactive Compliance

Event
 ↓
State Fabric
 ↓
Compliance Evaluation
 ↓
NON_COMPLIANT

118. Impact Analysis

TrainingExpired
 ↓
Employee
 ↓
Work Permits
 ↓
23 affected permits

119. Proactive Response

PRD-021 identifica:

23 affected Work Permits

PRD-038 cria:

CRITICAL / ACTION_REQUIRED

conforme a política.

120. Responsibility Resolution

PRD-041 encontra:

Responsible:
Training Coordinator

Accountable:
Safety Manager

121. Remediation

O sistema cria:

RemediationTask

para renovação do treinamento.

122. Verification

Após atualização no LMS:

LMS
 ↓
TrainingStatusUpdated
 ↓
Compliance Evaluation
 ↓
COMPLIANT

123. State Synchronization

PRD-035 atualiza:

Training State
Work Permit State
Compliance State
Goal State
Attention State

124. Attention Resolution

A Attention original deverá ser reavaliada.

NON_COMPLIANT
 ↓
Training renewed
 ↓
COMPLIANT
 ↓
Attention RESOLVED

125. Acceptance Criteria

126. Resultado Arquitetural

Com o PRD-042, a arquitetura evolui para:

                    REGULATION
                         │
                         ▼
                    REQUIREMENT
                         │
                         ▼
                    APPLICABILITY
                         │
                         ▼
                       CONTROL
                         │
                         ▼
                      EVIDENCE
                         │
                         ▼
                  COMPLIANCE ENGINE
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
        COMPLIANT                 GAP/RISK
                                     │
                                     ▼
                               RESPONSIBILITY
                                     │
                                     ▼
                                REMEDIATION
                                     │
                                     ▼
                                 VERIFICATION
                                     │
                                     ▼
                                COMPLIANCE

E todo esse processo passa a ser integrado ao restante do Agentic Work:

REGULATION
    ↓
KNOWLEDGE
    ↓
APPLICABILITY
    ↓
COMPLIANCE
    ↓
RISK
    ↓
RESPONSIBILITY
    ↓
ATTENTION
    ↓
WORKFLOW
    ↓
COLLABORATION
    ↓
APPROVAL
    ↓
CAPABILITY
    ↓
EXECUTION
    ↓
VERIFICATION
    ↓
AUDIT

O ponto mais importante é que o sistema deixa de ser apenas um agente que consulta normas e passa a possuir uma arquitetura para monitorar conformidade continuamente e transformar uma obrigação regulatória em controles, evidências, responsabilidades e ações verificáveis.

127. Evidência de implementação (2026-09-04)

O contrato determinístico foi consolidado em packages/agentic/src/compliance/governance.ts. Ele mantém UNKNOWN, NOT_APPLICABLE, NON_COMPLIANT, COMPLIANT e COMPLIANT_WITH_EXCEPTION distintos, valida efetividade temporal, jurisdição, integridade/autoridade/freshness da evidência e produz gap, severity, risk score e reason codes sem conceder autoridade. Requisito crítico sugerido por LLM permanece DRAFT até certificação humana independente com reviews Legal, Safety e Compliance; resolução de conflito regulatório usa autoridade e freshness registradas e empata em REQUIRES_REVIEW.

A migration D1 0116_compliance_governance.sql estende o Requirement/Control/Evidence Registry e acrescenta source/Regulation version registry, bindings de entidade, exceções, controles compensatórios, gaps, riscos, remediações, eventos, verificações, snapshots e dispatches. O replay limpo terminou em 116/116, com 16 tabelas compliance_%, 24 triggers e 27 colunas de requisito. A aplicação remota executou 60 comandos e confirmou os mesmos totais. Source, Regulation, binding, exception, compensating control, gap, risk, remediation scope/events, verification, snapshot e dispatch possuem guards D1 contra tamper ou transição inválida.

A API autenticada expõe source/Regulation/Requirement versioning, entity binding, exception, deterministic evaluation, remediation lifecycle, verification, point-in-time history, bounded NL preview e métricas. Cada snapshot fixa versões Regulation, Knowledge, Policy, Organization e State, hash SHA-256, evidência usada e DETERMINISTIC_RULES; a avaliação registra 11 vínculos imutáveis para Responsibility, Policy, Workflow, Event, State, Proactive, Attention, Decision, Knowledge, External Gateway e Audit. O Control Registry passou a preservar Responsible/Accountable do PRD-041 e authority da evidência externa.

Validação local: 26 testes focados de compliance, 220 testes do gate de exceções, 297 do predeploy e 7.177 testes na regressão integral passaram, com 10 skips preexistentes. Os typechecks integrais passaram e o verificador de documentação confirmou 18.177/18.177 funções com JSDoc. O replay limpo e o D1 remoto ficaram em 116/116.

Produção: Worker ab4521a3-bf0c-4c32-bc1c-d460ced0eb68 respondeu /health com D1, Durable Objects, KV, R2, Vectorize e Queue ativos. O canário público final criou o tenant sintético 5b7c6aaf-b5f6-4d34-bfc6-9f585073f6bf, source governamental rank 100, Regulation nr10-84e486aeea5849f4@v2026, requisito crítico training-valid-84e486aeea5849f4, Control/Evidence LMS e Work Permit WORK_PERMIT:wp-84e486aeea5849f4. A sugestão LLM sem reviews foi negada; a versão certificada por humano foi aceita. Uma mudança de deadline foi classificada DEADLINE_CHANGED/CRITICAL, encontrou quatro impactos, exigiu revisão humana e chegou a ACTIVE v3.

A vertical produziu, em ordem, NON_COMPLIANT, COMPLIANT e COMPLIANT_WITH_EXCEPTION; abriu gap CRITICAL/risk 100, resolveu Responsible e Accountable humanos independentes no PRD-041, executou a remediação ASSIGNED → IN_PROGRESS → WAITING_VERIFICATION → VERIFIED → CLOSED, exigiu nova avaliação/evidência antes da verificação e registrou exceção explícita, autorizada, time-bound e vinculada a controle compensatório. Foram persistidos três snapshots reproduzíveis e 33 dispatches para 11 fabrics. Três ledgers rejeitaram tamper remoto, o tenant de isolamento não enxergou os dados, acesso anônimo foi negado, todas as respostas mantiveram authorizesExecution=false e o cleanup PostgreSQL terminou com zero linhas.

A referência pública foi publicada em https://32ae2499.elioria-sst-x-docs.pages.dev (alias da branch feat-agentic-prd-00-49). As páginas do route module e do engine retornaram HTTP 200 como text/html; o OpenAPI retornou HTTP 200 como application/json, 422.591 bytes, e listou os 12 endpoints de compliance governance.

Em 2026-09-06, a regressão atual de governança de compliance, avaliações, remediações e mudanças regulatórias passou com 28 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.

PRD-043 — Agentic Regulatory Change & Impact Management

O próximo PRD deverá aprofundar uma consequência natural do PRD-042:

O que acontece quando uma norma, requisito, procedimento ou obrigação muda?

O PRD-043 deverá criar o mecanismo para detectar mudanças regulatórias, comparar versões semanticamente e determinar automaticamente o impacto sobre:

REGULATION
 ↓
REQUIREMENT
 ↓
CONTROL
 ↓
POLICY
 ↓
CAPABILITY
 ↓
WORKFLOW
 ↓
RESPONSIBILITY
 ↓
GOAL
 ↓
COMPLIANCE
 ↓
TENANT

Incluindo Regulatory Diff, Semantic Diff, Change Classification, Impact Graph, Affected Controls, Affected Workflows, Affected Capabilities, Affected Responsibilities, Migration Planning, Transitional Compliance, Grace Periods, Regulatory Alerts, Human Review, Legal/Compliance Approval, Simulation, What-if Analysis, Automated Test Generation, Regression Testing, Release Management e Historical Reproducibility.

1. Objetivo​

2. Problema

3. Princípio Fundamental

4. Separação Fundamental

5. Regulation

6. Regulatory Source

7. Requirement

8. Requirement Types

9. Requirement ≠ Regulation

10. Applicability

11. Applicability Engine

12. UNKNOWN

13. Applicability Result

14. Jurisdiction

15. Jurisdiction Hierarchy

16. Regulatory Version

17. Temporal Compliance

18. Point-in-Time Compliance

19. Control

20. Control Types

21. Requirement → Control

22. Control → Requirement

23. Control Objective

24. Evidence

25. Evidence Types

26. Evidence Provenance

27. Evidence Authority

28. Evidence Freshness

29. Evidence ≠ Compliance

30. Compliance State

31. Compliance Evaluation

32. Deterministic First

33. Example

34. Non-Compliance

35. Compliance Gap

36. Gap Severity

37. Compliance Risk

38. Compliance Risk Score

39. Responsibility Binding

40. Compliance Accountability

41. Compliance Approval

42. Remediation

43. Remediation Lifecycle

44. Verification

45. Evidence After Remediation

46. Continuous Compliance

47. Event Integration

48. Proactive Compliance

49. Temporal Compliance

50. Example

51. Compliance Attention

52. Compliance Goal

53. Compliance Decision

54. Compliance ≠ Authorization

55. Regulatory Interpretation

56. LLM Role

57. Regulatory Certification

58. Human Review

59. Regulatory Change Detection

60. Regulatory Impact Analysis

61. Compliance Knowledge Graph

62. Semantic IDs

63. Entity Binding

64. Requirement-to-Entity

65. Compliance Query

66. Explainable Answer

67. Non-Compliance Answer

68. Evidence Chain

69. Trust Integration

70. Unknown Evidence

71. Conflict

72. Conflict Resolution

73. Regulatory Exception

74. Exception ≠ Ignoring Requirement

75. Compensating Control

76. Regulatory Deadline

77. Compliance Calendar

78. Compliance Dashboard

79. Compliance Score

80. Critical Requirement Override

1. Objetivo

Work Permit + Training Compliance