PRD-047 — Agentic Risk, Safety & Predictive Prevention Fabric

1. Objetivo

O PRD-047 cria a camada de inteligência de risco e prevenção preditiva do Agentic Work.

Até o PRD-046, o sistema consegue:

REGULATION
    ↓
REQUIREMENT
    ↓
CONTROL
    ↓
EVIDENCE
    ↓
COMPLIANCE
    ↓
AUDIT
    ↓
FINDING
    ↓
REMEDIATION

Agora acrescentamos:

SIGNALS
   ↓
RISK DETECTION
   ↓
RISK ASSESSMENT
   ↓
RISK PREDICTION
   ↓
PREVENTIVE ACTION
   ↓
VERIFICATION

O objetivo não é substituir metodologias formais de avaliação de riscos, mas criar uma camada operacional capaz de identificar mudanças de risco, combinar sinais e antecipar situações que merecem intervenção humana ou automatizada.

2. Princípio Fundamental

O Agent não deve prever que um incidente ocorrerá como se fosse uma certeza. Ele deve identificar evidências de aumento de risco, quantificar incerteza e recomendar ou executar ações preventivas somente dentro da autoridade concedida.

Portanto:

RISK SCORE
≠
FACT

PREDICTION
≠
CERTAINTY

3. Risk vs Compliance

São conceitos diferentes.

Compliance

Pergunta:

“O requisito está sendo atendido?”

Requirement
 ↓
Control
 ↓
Evidence
 ↓
Compliance

Risk

Pergunta:

“Qual a possibilidade e o impacto de algo indesejado acontecer?”

Hazard
+
Exposure
+
Conditions
+
Controls
+
Historical Signals
 ↓
Risk

Um Work Permit pode estar:

COMPLIANT

e ainda assim apresentar:

HIGH_RISK

4. Risk Intelligence

O sistema deverá combinar:

Business State
Events
Controls
Compliance
Work Permits
Employees
Training
Incidents
Near Misses
Inspections
Historical Findings
Resources
Environmental Conditions
Temporal Patterns
Organizational Factors

5. Arquitetura

             KNOWLEDGE
                 │
EVENTS ──────────┤
                 │
CONTROLS ────────┤
                 ▼
          SIGNAL PROCESSOR
                 │
                 ▼
          EVIDENCE BUILDER
                 │
                 ▼
           RISK ENGINE
          ┌──────┴──────┐
          ▼             ▼
      CURRENT        FUTURE
        RISK         RISK
          │             │
          └──────┬──────┘
                 ▼
          DECISION ENGINE
                 │
                 ▼
              POLICY
                 │
        ┌────────┴────────┐
        ▼                 ▼
  RECOMMENDATION       ACTION
        │                 │
        └────────┬────────┘
                 ▼
             VERIFICATION

6. Risk Model

interface RiskAssessment {
  riskId: string;

  tenantId: string;

  subjectRefs: string[];

  hazardRefs: string[];

  riskScore: number;

  likelihood?: number;

  consequence?: number;

  exposure?: number;

  confidence: number;

  uncertainty: number;

  status: RiskStatus;

  evidenceRefs: string[];

  controlRefs: string[];

  assessedAt: string;

  validUntil?: string;

  modelVersion: string;
}

7. Risk Status

LOW
MODERATE
HIGH
CRITICAL
UNKNOWN

8. Risk Score

O score não deverá ser uma “verdade matemática” universal.

Ele será um instrumento de priorização.

Exemplo:

Likelihood = 4
Consequence = 5

Risk = 20

A metodologia deverá ser configurável por tenant/domínio quando necessário.

9. Risk Methodology

O sistema deverá suportar metodologias diferentes.

QUALITATIVE
SEMI_QUANTITATIVE
QUANTITATIVE
MATRIX
RULE_BASED
STATISTICAL
PREDICTIVE
HYBRID

10. Hard Safety Rules

Determinadas condições deverão produzir resultados determinísticos.

Exemplo:

Required training expired
+
Critical activity

poderá gerar:

CRITICAL RISK

independentemente de qualquer modelo estatístico.

11. Risk Factors

interface RiskFactor {
  factorId: string;

  name: string;

  type:
    | "HAZARD"
    | "EXPOSURE"
    | "CONTROL"
    | "HUMAN"
    | "ENVIRONMENT"
    | "TEMPORAL"
    | "ORGANIZATIONAL"
    | "HISTORICAL"
    | "RESOURCE";

  value: unknown;

  contribution?: number;

  evidenceRefs: string[];
}

12. Hazard

Um Hazard deverá ser explicitamente identificado.

FALL_FROM_HEIGHT
ELECTRICAL_ENERGY
CONFINED_SPACE
CHEMICAL_EXPOSURE
MOBILE_EQUIPMENT
FIRE
EXPLOSION
BIOLOGICAL_AGENT

O catálogo real deverá ser extensível.

13. Exposure

Risco não depende apenas da existência do perigo.

O sistema deverá considerar:

frequency
duration
population
proximity
intensity
exposure_window

14. Existing Controls

O Risk Engine deverá consultar o PRD-044.

Hazard
 ↓
Existing Controls
 ↓
Control Effectiveness

15. Control Effectiveness

Um controle:

DEFINED

não significa necessariamente:

EFFECTIVE

O risco deverá considerar:

control design
+
control operation
+
recent failures
+
evidence freshness

16. Residual Risk

O sistema deverá distinguir:

INHERENT RISK

de:

RESIDUAL RISK

Exemplo:

Inherent Risk = HIGH

Controls applied

Residual Risk = MODERATE

17. Risk Context

A mesma atividade poderá apresentar riscos diferentes dependendo de:

location
time
weather
team
equipment
training
workload
maintenance
previous incidents

18. Contextual Risk

O State Fabric fornece:

current business state
entity versions
workflow state
resource state

O Temporal Fabric fornece:

current time
calendar
deadline
season
shift

19. Dynamic Risk

O risco deverá ser recalculado quando ocorrerem mudanças relevantes.

TrainingExpired
      ↓
Risk Recalculation

20. Event-Driven Risk

Eventos relevantes:

WorkPermitCreated
WorkPermitUpdated
TrainingExpired
TrainingRenewed
IncidentCreated
NearMissReported
ControlFailed
EquipmentFailure
ResourceUnavailable
WeatherChanged
RegulatoryChangeDetected

21. Risk Signal

Um Signal é um indício de mudança.

interface RiskSignal {
  signalId: string;

  tenantId: string;

  type: string;

  subjectRefs: string[];

  observedAt: string;

  sourceRef: string;

  severity?: string;

  evidenceRefs: string[];

  confidence: number;
}

22. Signal ≠ Risk

Exemplo:

3 near misses

é um:

SIGNAL

não automaticamente:

HIGH RISK

O Risk Engine deve avaliar o conjunto.

23. Signal Aggregation

Near Miss
+
Training Expiration
+
Overtime
+
Control Failure

poderão produzir:

Risk Escalation

24. Signal Window

O sistema deverá permitir:

last 24 hours
last 7 days
last 30 days
last 90 days

para análise temporal.

25. Signal Frequency

Exemplo:

1 incident

é diferente de:

17 similar incidents
in 30 days

26. Recurrence

PRD-046 identifica Findings recorrentes.

O Risk Fabric deverá transformar recorrência em sinal:

Repeated Finding
 ↓
Risk Signal

27. Near Miss

Eventos de quase-acidente deverão possuir tratamento próprio.

NEAR_MISS

não significa:

INCIDENT

mas pode ser forte indicador de risco.

28. Incident Integration

PRD-024 fornece:

incident frequency
severity
root causes
affected entities

ao Risk Engine.

29. Risk Trend

O sistema deverá calcular tendências:

DECREASING
STABLE
INCREASING
VOLATILE
UNKNOWN

30. Risk Trend Example

June    32
July    38
August  51

poderá gerar:

RISK_TREND = INCREASING

31. Risk Velocity

Além do nível absoluto:

riskScore = 70

o sistema deverá observar:

Δrisk / Δtime

Um risco que aumentou rapidamente poderá merecer prioridade superior.

32. Risk Acceleration

Exemplo:

20 → 30 → 50 → 80

indica aceleração.

33. Predictive Risk

A camada preditiva poderá utilizar:

historical patterns
time series
statistical models
ML models

quando houver dados suficientes.

34. Model Output

Um modelo preditivo deverá retornar:

interface RiskPrediction {
  predictionId: string;

  subjectRefs: string[];

  predictedEvent: string;

  horizon: string;

  probability: number;

  confidence: number;

  uncertainty: number;

  contributingSignals: string[];

  modelVersion: string;

  generatedAt: string;
}

35. Probability

Exemplo:

Probability = 0.72

deverá ser interpretado como:

O modelo estima probabilidade de 72% sob as condições e população avaliadas.

Não:

“O acidente ocorrerá.”

36. Prediction Horizon

Suportar:

next 1 hour
next shift
next 24 hours
next 7 days
next 30 days

37. Prediction Confidence

O sistema deverá diferenciar:

probability
confidence
uncertainty

38. Insufficient Data

Se houver poucos dados:

PREDICTION = UNAVAILABLE

em vez de produzir uma falsa precisão.

39. Model Drift

O sistema deverá detectar:

prediction quality decreasing

ao longo do tempo.

40. Predictive Model Registry

interface RiskModel {
  modelId: string;

  version: string;

  domain: string;

  inputSchema: JSONSchema;

  outputSchema: JSONSchema;

  trainingPeriod?: string;

  evaluationMetrics: Record<string, number>;

  status:
    | "EXPERIMENTAL"
    | "VALIDATED"
    | "ACTIVE"
    | "DEPRECATED";
}

41. Model Governance

Nenhum modelo preditivo deverá ser colocado em produção sem:

evaluation
security review
bias analysis where applicable
performance validation
rollback
monitoring

42. LLM Role

LLM poderá interpretar:

inspection narrative
incident description
free-text observation
unstructured report

e extrair sinais.

43. LLM Extraction

Incident Report
 ↓
LLM
 ↓
Structured Signals
 ↓
Validation
 ↓
Risk Engine

44. LLM Boundary

O LLM não deverá:

invent hazard
invent incident
invent probability
override deterministic rule

45. Evidence Requirement

Toda avaliação deverá apontar:

evidenceRefs
signalRefs
controlRefs

quando disponíveis.

46. Risk Explanation

O Agent deverá responder:

“Por que este Work Permit está com risco alto?”

Formato:

Risk:
HIGH

Factors:
• Critical activity
• Required training expires today
• Control failed 2 times
• Similar incidents increased 40%

Evidence:
...

Confidence:
0.91

47. No Chain of Thought

A explicação será baseada em:

facts
signals
rules
evidence
model outputs

e não na cadeia interna de raciocínio do LLM.

48. Risk Attribution

Cada fator deverá indicar contribuição quando o método permitir.

Training validity      +25
Control failure        +20
Recent incidents       +15
Exposure                +10

49. Risk Thresholds

0–20     LOW
21–40    MODERATE
41–70    HIGH
71–100   CRITICAL

Os limites deverão ser configuráveis.

50. Critical Override

Uma condição crítica poderá forçar:

CRITICAL

sem depender de score agregado.

51. Risk Escalation

MODERATE
 ↓
HIGH
 ↓
CRITICAL

deverá gerar eventos.

52. Risk De-escalation

Quando controles forem restaurados:

CRITICAL
 ↓
HIGH
 ↓
MODERATE

também deverá ser registrado.

53. Risk Hysteresis

Para evitar oscilações:

HIGH → MODERATE

poderá exigir condições diferentes de:

MODERATE → HIGH

54. Risk Alert Fatigue

Não criar uma nova atenção a cada avaliação.

Utilizar:

deduplication
cooldown
aggregation
state change detection

do PRD-038.

55. Preventive Recommendation

Quando o risco aumentar:

Risk
 ↓
Recommendation

Exemplo:

“Revisar treinamento da equipe antes de liberar o Work Permit.”

56. Recommendation Model

interface PreventiveRecommendation {
  recommendationId: string;

  tenantId: string;

  riskRefs: string[];

  description: string;

  proposedActions: string[];

  expectedImpact: string;

  urgency: string;

  confidence: number;

  requiresHumanReview: boolean;
}

57. Recommendation ≠ Action

O Agent não deverá automaticamente transformar:

recommendation

em:

execution

58. Preventive Action

Quando autorizado:

Recommendation
 ↓
Policy
 ↓
Capability
 ↓
Execution
 ↓
Verification

59. Preventive Action Examples

Baixo risco:

Send reminder
Create review task
Refresh evidence
Schedule inspection

Alto risco:

Suspend release
Stop operation
Change authorization

deverá obedecer a políticas específicas e possivelmente exigir aprovação humana.

60. Risk-Based Attention

PRD-038 poderá receber:

riskScore
severity
urgency
affectedPopulation

61. Risk-Based Resource Allocation

PRD-039 poderá utilizar risco para priorizar:

inspectors
reviewers
maintenance
training

62. Risk-Based Audit

PRD-046 poderá utilizar risco para selecionar:

audit samples

63. Risk-Based Goals

PRD-036 poderá criar:

Goal:
Reduce high-risk Work Permits by 50%

64. Risk-Based Workflow

Risk CRITICAL
 ↓
Workflow
 ↓
Human Review
 ↓
Corrective Action
 ↓
Verification

65. Risk-Based Planning

PRD-032 poderá considerar:

risk
latency
cost
resource availability

ao montar planos.

66. Risk-Based Runtime

PRD-034 poderá ajustar:

priority
concurrency
resource selection

dentro dos limites autorizados.

67. Risk and Responsibility

PRD-041 identifica:

Responsible
Accountable

para o risco.

68. Risk and Compliance

PRD-042 fornece:

compliance status
control status

como fatores de risco.

69. Risk and Evidence

PRD-045 fornece:

evidence freshness
evidence quality
evidence conflicts

70. Risk and Regulatory Change

PRD-043 poderá aumentar o risco quando:

requirement changed
+
controls not yet updated

71. Regulatory Transition Risk

Durante uma transição:

Old Control
+
New Requirement
+
Migration Pending

poderá gerar:

REGULATORY_TRANSITION_RISK

72. Risk Graph

Employee
   │
   ▼
Training
   │
   ▼
Work Permit
   │
   ├── Hazard
   ├── Controls
   ├── Incidents
   ├── Findings
   └── Evidence

73. Risk Propagation

Uma mudança em:

Training

poderá afetar:

Employee
 ↓
Work Permit
 ↓
Activity
 ↓
Risk

74. Risk Dependency Graph

O sistema deverá manter relações:

CAUSES
CONTRIBUTES_TO
MITIGATED_BY
AFFECTS
DEPENDS_ON
CORRELATED_WITH
INDICATES

75. Risk Correlation

Dois sinais relacionados poderão ser agrupados.

Exemplo:

equipment failures
+
maintenance overdue

→ possível risco de equipamento.

76. Correlation ≠ Causation

O sistema deverá preservar a distinção:

CORRELATED

não significa:

CAUSED_BY

77. Causal Analysis

Quando existir evidência suficiente, Decision Intelligence poderá avaliar:

potential causes

e registrar:

SUSPECTED
CONFIRMED
REJECTED

78. Scenario Simulation

O usuário poderá perguntar:

“O que acontece com o risco se esse treinamento não for renovado?”

O sistema deverá executar um:

WHAT_IF

79. What-If Architecture

Current State
 ↓
Hypothetical Change
 ↓
Risk Engine
 ↓
Control Impact
 ↓
Compliance Impact
 ↓
Risk Result

Sem alterar dados reais.

80. Preventive Simulation

Também:

“E se adicionarmos uma inspeção adicional?”

Current Risk
 ↓
Add Control
 ↓
Simulate
 ↓
Estimated Residual Risk

81. Simulation Boundary

Simulações nunca deverão:

execute real capability
modify business state
modify compliance state

82. Risk Scenarios

interface RiskScenario {
  scenarioId: string;

  baseSnapshotId: string;

  hypotheticalChanges: ScenarioChange[];

  predictedRisk: RiskAssessment;

  affectedEntities: string[];

  createdAt: string;
}

83. Risk Appetite

Cada tenant poderá definir:

acceptable risk
tolerable risk
unacceptable risk

84. Risk Appetite Model

interface RiskAppetite {
  domain: string;

  maximumRisk: number;

  criticalConditions: string[];

  escalationPolicyId: string;
}

85. Risk Acceptance

Aceitação de risco deverá ser uma decisão formal.

Risk
 ↓
Decision
 ↓
Authorized Person
 ↓
Acceptance

O Agent não poderá aceitar risco crítico autonomamente.

86. Risk Exception

Uma exceção deverá possuir:

scope
reason
approver
effectiveFrom
effectiveUntil
compensatingControls

87. Risk Expiration

Ao expirar:

Risk Acceptance
 ↓
EXPIRED
 ↓
Risk Reassessment

88. Autonomous Risk Actions

Autonomia deverá ser limitada:

OBSERVE
RECOMMEND
PREPARE
EXECUTE_WITH_CONFIRMATION
AUTONOMOUS_LOW_RISK

89. Critical Risk

Para:

CRITICAL

o padrão deverá ser:

HUMAN_REVIEW

salvo política explicitamente aprovada.

90. Kill Switch

O sistema deverá suportar:

GLOBAL
TENANT
AGENT
RISK_MODEL
CAPABILITY
DOMAIN

para interromper ações automáticas.

91. Risk Model Failure

Se o modelo estiver indisponível:

Predictive Risk
= UNKNOWN

mas controles determinísticos continuarão funcionando.

92. Fail-Safe

Para controles críticos:

Predictive model unavailable

não deverá automaticamente significar:

SAFE

93. Model Fallback

Predictive Model
 ↓ unavailable
Deterministic Rules
 ↓ unavailable
Human Review

94. Risk Data Quality

O sistema deverá detectar:

missing data
stale data
inconsistent data
duplicate events
source outage
entity ambiguity

95. Data Quality Impact

Se a qualidade dos dados cair:

Risk Confidence
 ↓
LOWER

Uncertainty
 ↓
HIGHER

96. Risk Uncertainty

Exemplo:

Risk Score: 78
Confidence: 0.52
Uncertainty: HIGH

Isso deverá ser tratado diferentemente de:

Risk Score: 78
Confidence: 0.97
Uncertainty: LOW

97. Risk Explanation API

GET /risk/:id
GET /risk/:id/factors
GET /risk/:id/evidence
GET /risk/:id/history
GET /risk/:id/scenarios
GET /risk/:id/recommendations

As APIs reais deverão ser expostas através do Capability Registry.

98. Capabilities

Novas capabilities:

risk.get
risk.assess
risk.assessBatch
risk.explain
risk.history
risk.simulate
risk.listHighRisk
risk.createRecommendation
risk.createPreventiveTask

99. No Direct API Access

O Agent continuará sem acesso direto aos endpoints.

Agent
 ↓
Capability Registry
 ↓
Policy
 ↓
Execution

100. Events

Novos eventos:

RiskAssessmentCreated
RiskIncreased
RiskDecreased
RiskBecameHigh
RiskBecameCritical
RiskPredictionCreated
RiskModelUnavailable
RiskModelDriftDetected
RiskRecommendationCreated
RiskAccepted
RiskAcceptanceExpired

101. Semantic UI

Novos IDs:

risk.dashboard
risk.assessment
risk.factors
risk.evidence
risk.history
risk.prediction
risk.recommendation
risk.scenario
risk.action

102. Risk Dashboard

Visualização:

Critical
High
Moderate
Low
Unknown

com filtros:

facility
department
activity
employee
Work Permit
hazard
time

103. Risk Heatmap

Poderá mostrar:

Likelihood × Consequence

sem substituir a metodologia formal do domínio.

104. Risk Timeline

00 Moderate
15 High
30 Control Failed
32 Critical
10 Remediation
30 Moderate

105. First Vertical Slice

Work Permit Risk

Exemplo:

WP-1001

atividade crítica.

106. Signals

Training expires today
+
Previous control failure
+
Similar incident in same area

107. Risk Engine

Calcula:

Inherent Risk = HIGH
Residual Risk = CRITICAL
Confidence = HIGH

108. Recommendation

Do not release until
training validity is verified.

109. Policy

PRD-008 determina:

CRITICAL RISK
+
RELEASE
=
HUMAN REVIEW

110. Attention

PRD-038 cria:

CRITICAL ACTION_REQUIRED

para o responsável.

111. Responsibility

PRD-041 resolve:

Responsible = Supervisor
Accountable = Area Manager
Reviewer = Safety Professional

112. Preventive Workflow

Risk Critical
 ↓
Review
 ↓
Training Renewal
 ↓
Evidence
 ↓
Control
 ↓
Risk Reassessment

113. Verification

Depois da correção:

Training Valid
Control PASS
Risk ↓

e somente então a operação poderá prosseguir, se autorizado pela Policy.

114. Predictive Example

O sistema identifica:

Last 30 days:

Near misses: +42%
Control failures: +18%
Overtime: +21%
Training expirations: +15%

e produz:

RISK TREND = INCREASING

115. Preventive Recommendation

Increase inspection coverage
for this activity during the
next 7 days.

116. Resource Allocation

PRD-039 poderá então encontrar:

Qualified Inspector
+
Available Capacity
+
Correct Location

117. Goal

PRD-036 poderá criar:

Goal:
Reduce risk to acceptable level
within 7 days.

118. Continuous Loop

SIGNAL
 ↓
RISK
 ↓
RECOMMENDATION
 ↓
ACTION
 ↓
CONTROL
 ↓
EVIDENCE
 ↓
RISK REASSESSMENT

Esse loop é fundamental.

119. Learning

PRD-012 deverá registrar:

Risk prediction
Actual outcome
Recommendation
Action
Result

para avaliar posteriormente se a previsão foi útil.

120. Prediction Evaluation

Métricas:

Precision
Recall
False Positive Rate
False Negative Rate
Calibration
Lead Time
Prediction Stability

121. Safety Metric

Para riscos críticos:

Unsafe Autonomous Action Rate

deverá ser:

0%

122. Risk Model Governance

Modelos deverão passar por:

DRAFT
 ↓
VALIDATION
 ↓
SHADOW
 ↓
CANARY
 ↓
ACTIVE
 ↓
MONITORED
 ↓
DEPRECATED

integrado ao PRD-016.

123. Shadow Mode

O modelo poderá operar:

REAL DATA
+
NO ACTION

para comparar previsão com resultado real.

124. Canary

Novo modelo:

Model v2
 ↓
5%
 ↓
25%
 ↓
50%
 ↓
100%

125. Rollback

Se ocorrer:

false positives ↑
false negatives ↑
latency ↑
unsafe recommendation

o modelo poderá ser revertido.

126. Auditability

Cada previsão deverá registrar:

modelId
modelVersion
inputSnapshot
signalRefs
output
confidence
generatedAt

127. Reproducibility

Deverá ser possível reconstruir:

What data did the model see?
What model version was used?
What risk was produced?
What action followed?

128. Privacy

Risk models não deverão utilizar dados pessoais além do necessário.

O sistema deverá aplicar:

data minimization
purpose limitation
tenant isolation
access control
retention

129. Security

O Risk Engine não poderá alterar:

authorization
policy
tenant
regulatory requirement

130. Performance

Para avaliação determinística:

P50 < 100ms
P95 < 300ms

quando os dados estiverem indexados/localmente disponíveis.

Modelos mais pesados deverão ser assíncronos quando necessário.

131. Cost Optimization

Prioridade:

Event
 ↓
Existing Risk State
 ↓
Deterministic Rules
 ↓
Cached Model
 ↓
Statistical Model
 ↓
LLM

132. Acceptance Criteria

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

O slice de Work Permit agora possui motor determinístico de risco inerente/residual, UNKNOWN fail-closed quando falta evidência, regra dura TRAINING_EXPIRED_CRITICAL_ACTIVITY, confiança/incerteza separadas e authorizesExecution:false. As migrations D1 0123 e 0124 persistem sinais, avaliações, eventos e aceitações com snapshots de 64 caracteres e ledgers append-only.

O Worker 1b3bc66e-aa77-4fe8-ab6e-82b5e196a64e foi publicado após os gates; o canário autenticado registrou primeiro Evidence Fabric ACTIVE ligada ao mesmo Work Permit, sinal, avaliação CRITICAL e aceitação temporal. Um fixture sintético, tenant-bound e autoritativo de control_governed_evaluations em PASS, ligado ao mesmo Work Permit por evaluationId, reduziu deterministicamente o residual de 20 para 15; a API rejeita uma avaliação de controle ausente ou ligada a outro sujeito. Confirmou 1/1/1 no D1, isolamento tenant, negação anônima e rejeição de alteração imutável. O Pages af7d8c82 publicou /riscos e seu chunk JavaScript com HTTP 200 e MIME correto. Estes fatos não comprovam ainda os critérios de integrações amplas restantes.

Em 2026-09-05, a migration remota 0128_risk_registry.sql e o Worker acf92d95-7113-4d5d-a781-51b516825eae adicionaram registry append-only de riscos tenant-scoped. O registry exige hazard IDs extensíveis, exposição estruturada (frequency, duration, population, proximity, intensity, janela), fatores tipados e evidência ativa vinculada ao sujeito. O canário autenticado comprovou 1 registry, sinal, avaliação e aceitação no mesmo tenant, isolamento, negação anônima, cleanup e authorizesExecution:false; updates diretos no registry foram rejeitados por RISK_REGISTRY_IMMUTABLE.

Em 2026-09-05, a migration remota 0129_risk_hazards.sql e o Worker 58b60925-603c-468a-bf74-acf165277f46 acrescentaram catálogo de hazards ativo, append-only e tenant-scoped. O registry só aceita IDs presentes nesse catálogo; o canário autenticado comprovou 1 hazard → 1 registry → 1 sinal → 1 avaliação → 1 aceitação, isolamento, cleanup e authorizesExecution:false.

Em 2026-09-05, o Worker abcb9128-e2bd-473d-bf5e-bd1a703e8b3d adicionou agregação de sinais por Work Permit nas janelas fechadas de 1, 7, 30 e 90 dias. A projeção calcula tipos/criticidade de sinais, tendência DECREASING/STABLE/INCREASING/VOLATILE/UNKNOWN e velocidade residual por hora a partir de avaliações imutáveis. O canário autenticado comprovou duas avaliações com residual crescente, exigiu tendência INCREASING, velocidade positiva e recomendação sem autoridade de execução.

Em 2026-09-05, o Worker 7c6e63c7-c6cb-48f4-af42-c8432d5fedc7 passou a projetar uma previsão crítica ou em revisão para um item humano deduplicado no Attention Center. O canário autenticado confirmou 1 Attention de origem RISK_PREDICTION, isolamento, cleanup e authorizesExecution:false; essa projeção não aprova, executa nem fecha uma intervenção.

Em 2026-09-05, o Worker e62a5825-57ea-4df9-a9b3-1121d54924ae passou a projetar uma previsão de risco CRITICAL, HUMAN_REVIEW ou MODEL_REVIEW para um Decision Record imutável tenant-scoped, deduplicado pela chave risk:<predictionId>. O input inclui o hash do snapshot como fato auditável; a restrição dura human-review-required rejeita continue-with-monitoring e seleciona somente pause-and-review. O canário autenticado confirmou 1 decisão no D1 juntamente com hazard, registry, sinal, duas avaliações, aceitação e Attention, mais isolamento, cleanup e negação anônima. A projeção é uma recomendação persistida e replayável, nunca uma aprovação, autorização ou execução (authorizesExecution:false).

Em 2026-09-05, o fluxo preventivo comprovado conectou previsão crítica à recomendação REVIEW_REQUIRED e a uma intervenção tenant-scoped AWAITING_AUTHORIZATION, usando um template ativo que exige aprovação humana. O canário autenticado criou o template, planejou exatamente 1 intervenção a partir de recommendation:<predictionId>, confirmou a presença no D1, isolamento, cleanup e authorizesExecution:false; nenhuma capability foi executada nessa transição.

Em 2026-09-05, o gate verify:risk-prevention-governance passou com 26 testes em 9 arquivos e o canário remoto correspondente confirmou, em tenant sintético isolado, 1 hazard, 1 risk registry, 1 signal, 2 assessments, 1 acceptance temporal, 1 Attention, 1 Decision e 1 intervenção preventiva somente planejada. A rota anônima foi negada, o isolamento foi confirmado e nenhuma dessas projeções concedeu autoridade de execução.

Em 2026-09-05, os contratos avançados de inteligência de risco passaram com 20 testes em 8 arquivos: metodologia RULE_BASED, previsão com confiança, incerteza e evidência obrigatória, registry/versionamento/governança de modelo, monitoramento de drift fail-closed, outcomes imutáveis, calibração, cenário What-if sem escrita/autoridade e rollout CANARY com rollback versionado. A governança de evidência e controle valida escopo e recusa referências inválidas antes da avaliação.

Em 2026-09-06, a migration D1 0146_incident_risk_subjects.sql adicionou vínculo imutável e tenant-scoped entre um incidente e seu Work Permit, com código de causa-raiz. POST /exceptions aceita esse vínculo somente quando a exceção correlaciona um incidente de risco alto; POST /risk/governance/incidents/:incidentId/signal lê exclusivamente incidente e vínculo do tenant autenticado e deriva o sinal idempotente incident:<incidentId>. Incidentes sem vínculo são recusados com INCIDENT_RISK_SUBJECT_UNAVAILABLE, sem inferir sujeito. A versão 8202aee6-51e7-464e-b579-d2bcb5ea8f55 foi publicada em 100% após 53 arquivos e 448 testes. O canário autenticado confirmou no D1 1 vínculo e 1 sinal INCIDENT para o Work Permit sintético, além de hazard, registry, avaliações, acceptance, Attention, Decision e intervenção somente planejada; confirmou isolamento, 401 anônimo, cleanup PostgreSQL zero e authorizesExecution:false em todo o fluxo. Não foram criadas avaliação, aprovação ou execução pela projeção do incidente.

No mesmo Worker, o guard persistente de emergência já protege todas as rotas mutáveis /risk/* antes dos handlers e suporta níveis GLOBAL, TENANT, AGENT, CAPABILITY, DOMAIN, RESOURCE e EXECUTION. O canário de 2026-09-06 inseriu um controle DOMAIN=risk exclusivamente no tenant sintético, recebeu 423 AGENT_EXECUTION_DISABLED na tentativa de criar uma previsão e conferiu o ID, nível e alvo do controle; ele o removeu antes de continuar. O restante do canário permaneceu verde, com isolamento e zero autoridade de execução. Isso certifica o kill switch de risco, não substitui o enforcement declarativo de policy ainda pendente.

Também em 2026-09-06, uma avaliação governada NON_COMPLIANT passou a inserir, no mesmo batch D1 do gap e do risco de compliance, o sinal imutável COMPLIANCE_GAP para o Risk Fabric. O identificador é determinístico por avaliação (compliance:<evaluationId>), a entidade já declarada no contexto é preservada, as evidências originais são apenas referenciadas e MEDIUM é normalizado para MODERATE; avaliações conformes, desconhecidas ou não aplicáveis não criam sinal. A versão bfef2773-0975-42c0-86fe-529b249c3cdd foi publicada a 100% após 53 arquivos e 448 testes. A consulta D1 remota confirmou o sinal sintético compliance:eval-fail-66c99de636714dfc como COMPLIANCE_ENTITY/WORK_PERMIT:wp-66c99de636714dfc, CRITICAL, confidence 1 e snapshot hash de 64 caracteres. A integração não cria assessment, recomendação, plano, aprovação ou execução.

Também em 2026-09-06, a aprovação humana de uma mudança regulatória passou a derivar, no mesmo batch D1, um sinal imutável REGULATORY_CHANGE para cada impacto HIGH ou CRITICAL. O ID é determinístico por mudança e alvo (regulatory:<changeId>:<targetType>:<targetId>); o snapshot fixa impacto, relação, hashes de diff e fonte, versão recém-aprovada e somente referências à decisão humana. A inserção é condicionada à mudança na versão exata APPROVED, portanto aprovação stale não emite sinal. A versão 136be6a9-3578-457d-a365-48a6225941de foi publicada em 100% após 53 arquivos e 448 testes. O D1 remoto primário confirmou regulatory:change-b7b015b759bc4d78:CONTROL:control-b7b015b759bc4d78 como CONTROL, REGULATORY_CHANGE, CRITICAL, confidence 1 e hash de 64 caracteres. A integração não cria assessment, recomendação, plano, aprovação adicional ou execução.

Também em 2026-09-06, uma avaliação governada de risco passou a poder fixar o RACI vigente quando recebe action e escopo explícitos. No instante assessedAt, ela exige ao menos um RESPONSIBLE ativo e exatamente um ACCOUNTABLE humano no mesmo tenant/escopo; ausência, duplicidade ou accountable não humano são recusados antes de persistir. O snapshot imutável conserva somente assignments, tipos/IDs dos principals, versões e organization version, e essa resolução não cria atribuição nem concede autoridade. A versão 0cc5e644-d9bd-4c34-b3cd-9c48f929e5c0 foi publicada em 100% após 53 arquivos e 448 testes. O canário autenticado confirmou supervisor e gestor humano distintos, isolamento e 401 anônimo; D1 remoto primário confirmou risk.review, accountable HUMAN, ambos os IDs RACI e hash de 64 caracteres.

Também em 2026-09-06, o Risk Fabric passou a derivar RESOURCE_CAPACITY somente de recurso tenant-scoped em estado adverso: DEGRADED vira HIGH, e SATURATED ou UNAVAILABLE viram CRITICAL. A leitura fixa tipo, status efetivo, concorrência máxima e unidades reservadas no instante explícito; recurso AVAILABLE é recusado sem sinal. A versão 561dd3f3-c492-4297-81f8-e871947e36a5 foi publicada em 100% após 53 arquivos e 448 testes. O canário registrou um recurso API, saturou-o pela API normal de reserva e confirmou que a reserva seguiu ACTIVE depois do sinal; D1 remoto primário confirmou sujeito RESOURCE, tipo RESOURCE_CAPACITY, severidade CRITICAL, confidence 1 e hash de 64 caracteres. O endpoint não reserva, libera, enfileira ou despacha recurso.

Também em 2026-09-06, metas gerenciadas AT_RISK e BLOCKED passaram a derivar sinais imutáveis GOAL_STATE, respectivamente HIGH e CRITICAL. O ID é idempotente por meta+versão (goal:<goalId>:<version>), e o snapshot fixa status, health, risco, progresso, motivo e instante da projeção; metas em estado saudável/ativo são recusadas sem sinal. A versão 32b62b38-c4bc-4d00-a657-7eda210c6b90 foi publicada em 100% após 53 arquivos e 448 testes. O canário de metas executou a lifecycle normal até AT_RISK; D1 remoto primário confirmou goal:goal-58e4da828699440e:3 como sujeito GOAL, GOAL_STATE, HIGH, confidence 1 e hash de 64 caracteres. A rota não avalia, replaneja, altera tarefas ou muda a meta.

Também em 2026-09-06, o enforcement de policy foi certificado na fronteira que realmente executa intervenção: antes de criar Workflow, /interventions/:id/executions revalida capability/version/binding/lifecycle, reserva ativa, snapshot aprovado, permissões do ator e approval humana; falhas de permissão ou approval retornam INTERVENTION_POLICY_DENIED sem recibo, execução ou Workflow. O cliente não escolhe a decisão: referências forjadas são descartadas e um recibo server-issued, hash de input e validade limitada são vinculados atomicamente à execução. Os 86 testes focados de receipt/execução passaram. No Worker 32b62b38-c4bc-4d00-a657-7eda210c6b90, o canário externo completou as capabilities training.external.requestRenewal@1 e equipment.maintenance.request@1; D1 remoto primário confirmou POLICY_ALLOW, safety-intervention, approval humana, input hash de 64 caracteres e execução SUCCEEDED para ambas. Isso não permite ao Risk Engine alterar policy ou autorizar uma intervenção por si só.

Em 2026-09-06, a regressão atual de atenção, calibração, inteligência, monitoramento, outcomes, prevenção, recomendações, registry, rollouts e cenários de risco 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 pelos canários remotos registrados.

133. Resultado Arquitetural

Com o PRD-047, o Agentic Work passa a operar um ciclo de prevenção contínua:

                 ┌───────────────┐
                 │    SIGNALS    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │  RISK ENGINE  │
                 └───────┬───────┘
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
        CURRENT RISK          PREDICTIVE RISK
              │                     │
              └──────────┬──────────┘
                         ↓
                 ┌───────────────┐
                 │    DECISION   │
                 └───────┬───────┘
                         ↓
                    ┌────────┐
                    │ POLICY │
                    └────┬───┘
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
        RECOMMENDATION             ACTION
              │                     │
              └──────────┬──────────┘
                         ↓
                    VERIFICATION
                         ↓
                   RISK UPDATED

O Agentic Work agora não apenas pergunta:

“Estamos conformes?”

nem somente:

“O que aconteceu?”

Ele passa a responder:

“O que está aumentando nosso risco?”

“O que provavelmente poderá acontecer se nada for feito?”

“Qual evidência sustenta essa avaliação?”

“Qual ação preventiva é apropriada?”

“Quem deve agir?”

“A intervenção reduziu efetivamente o risco?”

Isso cria a camada de Predictive Safety & Prevention sobre toda a infraestrutura construída até aqui.

PRD-048 — Agentic Safety Operations & Real-Time Operational Awareness

O próximo passo será levar a inteligência de risco para o tempo real da operação.

O PRD-048 deverá conectar:

REAL-TIME EVENTS
       +
WORK PERMITS
       +
PEOPLE
       +
RESOURCES
       +
EQUIPMENT
       +
LOCATION
       +
ENVIRONMENT
       +
WORKFLOW STATE
       +
RISK
       +
CONTROLS
       +
INCIDENTS
       ↓
OPERATIONAL AWARENESS
       ↓
REAL-TIME RISK STATE
       ↓
DETECTION
       ↓
DECISION
       ↓
INTERVENTION
       ↓
VERIFICATION

A ideia será criar uma espécie de “sistema nervoso operacional” do SST: o Agent não precisará esperar o usuário perguntar o que está acontecendo; poderá perceber mudanças relevantes no estado operacional e, respeitando as políticas de autonomia, alertar, recomendar, solicitar intervenção ou iniciar respostas previamente autorizadas.

Isso incluirá Real-Time Safety State, Operational Digital Twin, Activity Awareness, Worker Awareness, Equipment Awareness, Location/Geofencing, Environmental Signals, Real-Time Hazard Detection, Dynamic Risk State, Safety Events, Situation Detection, Event Correlation, Anomaly Detection, Operational Context, Safety Zones, Exposure Monitoring, Permit-State Correlation, Worker-to-Activity Mapping, Resource State, Real-Time Control Monitoring, Safety Interventions, Emergency Escalation, Dynamic Work Permit Blocking, Safety Watchdogs, Incident Early Detection, Operational Timeline, Real-Time Attention, Streaming Architecture, Edge/Event Processing e integração com dispositivos e sistemas externos, mantendo a mesma regra central: percepção em tempo real pode ser automática; autoridade para ações críticas continua sendo governada por Policy, Capability, Identity e Human-in-the-Loop.

1. Objetivo​

2. Princípio Fundamental

3. Risk vs Compliance

Compliance​

Risk​

4. Risk Intelligence

5. Arquitetura

6. Risk Model

7. Risk Status

8. Risk Score

9. Risk Methodology

10. Hard Safety Rules

11. Risk Factors

12. Hazard

13. Exposure

14. Existing Controls

15. Control Effectiveness

16. Residual Risk

17. Risk Context

18. Contextual Risk

19. Dynamic Risk

20. Event-Driven Risk

21. Risk Signal

22. Signal ≠ Risk

23. Signal Aggregation

24. Signal Window

25. Signal Frequency

26. Recurrence

27. Near Miss

28. Incident Integration

29. Risk Trend

30. Risk Trend Example

31. Risk Velocity

32. Risk Acceleration

33. Predictive Risk

34. Model Output

35. Probability

36. Prediction Horizon

37. Prediction Confidence

38. Insufficient Data

39. Model Drift

40. Predictive Model Registry

41. Model Governance

42. LLM Role

43. LLM Extraction

44. LLM Boundary

45. Evidence Requirement

46. Risk Explanation

47. No Chain of Thought

48. Risk Attribution

49. Risk Thresholds

50. Critical Override

51. Risk Escalation

52. Risk De-escalation

53. Risk Hysteresis

54. Risk Alert Fatigue

55. Preventive Recommendation

56. Recommendation Model

57. Recommendation ≠ Action

58. Preventive Action

59. Preventive Action Examples

60. Risk-Based Attention

61. Risk-Based Resource Allocation

62. Risk-Based Audit

63. Risk-Based Goals

64. Risk-Based Workflow

65. Risk-Based Planning

66. Risk-Based Runtime

67. Risk and Responsibility

68. Risk and Compliance

69. Risk and Evidence

70. Risk and Regulatory Change

71. Regulatory Transition Risk

72. Risk Graph

73. Risk Propagation

74. Risk Dependency Graph

75. Risk Correlation

76. Correlation ≠ Causation

77. Causal Analysis

78. Scenario Simulation

1. Objetivo

Compliance

Risk

Work Permit Risk

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