PRD-049 — Agentic Preventive Action & Safety Intervention Orchestration

1. Objetivo

O PRD-049 fecha o ciclo iniciado nos PRDs anteriores:

RISCO
  ↓
DECISÃO
  ↓
RECOMENDAÇÃO
  ↓
INTERVENÇÃO
  ↓
VERIFICAÇÃO
  ↓
REDUÇÃO DO RISCO

Até o PRD-048, o sistema consegue perceber a operação em tempo real e identificar situações de risco.

Agora ele deverá ser capaz de coordenar intervenções preventivas, envolvendo pessoas, Agents, workflows, capabilities, recursos, controles e sistemas externos.

2. Princípio Fundamental

Detectar um risco não basta. O sistema deverá ser capaz de coordenar, dentro dos limites de autoridade, a intervenção necessária e provar posteriormente que ela realmente reduziu o risco.

Portanto:

Risk Detection
      ↓
Decision
      ↓
Policy
      ↓
Intervention
      ↓
Execution
      ↓
Verification
      ↓
Risk Reassessment

3. Intervention ≠ Recommendation

Uma recomendação diz:

“É recomendável realizar uma inspeção.”

Uma intervenção representa:

“Uma inspeção foi autorizada, atribuída, executada e verificada.”

4. Intervention Model

interface SafetyIntervention {
  interventionId: string;

  tenantId: string;

  type: InterventionType;

  riskRefs: string[];

  situationRefs: string[];

  targetRefs: string[];

  objective: string;

  priority: InterventionPriority;

  status: InterventionStatus;

  authorizationRef?: string;

  decisionRef?: string;

  workflowRef?: string;

  planRef?: string;

  assignedResourceRefs: string[];

  createdAt: string;

  startedAt?: string;

  completedAt?: string;

  verifiedAt?: string;
}

5. Intervention Types

O Registry deverá suportar, inicialmente:

NOTIFY
REVIEW
INSPECT
RETRAIN
REASSIGN_RESOURCE
ACTIVATE_CONTROL
ADD_CONTROL
PAUSE_ACTIVITY
RESUME_ACTIVITY
REPLACE_EQUIPMENT
MAINTENANCE
RESTRICT_ACCESS
ESCALATE
EMERGENCY_STOP

A lista deverá ser extensível.

6. Intervention Lifecycle

PROPOSED
    ↓
EVALUATING
    ↓
AUTHORIZED
    ↓
PLANNED
    ↓
ASSIGNED
    ↓
READY
    ↓
EXECUTING
    ↓
VERIFYING
    ↓
COMPLETED

Estados alternativos:

REJECTED
CANCELLED
EXPIRED
FAILED
BLOCKED
PARTIAL
ESCALATED

7. Intervention Status

type InterventionStatus =
  | "PROPOSED"
  | "EVALUATING"
  | "AUTHORIZED"
  | "PLANNED"
  | "ASSIGNED"
  | "READY"
  | "EXECUTING"
  | "VERIFYING"
  | "COMPLETED"
  | "PARTIAL"
  | "BLOCKED"
  | "FAILED"
  | "REJECTED"
  | "CANCELLED"
  | "EXPIRED"
  | "ESCALATED";

8. Intervention Priority

LOW
NORMAL
HIGH
URGENT
CRITICAL
EMERGENCY

A prioridade não poderá ser determinada exclusivamente pelo LLM.

9. Intervention Objective

Toda intervenção deverá possuir um objetivo mensurável.

Exemplo:

Objective:
Restore training compliance
for workers assigned to WP-1001.

10. Intervention Scope

A intervenção deverá indicar:

what
where
when
who
why
how

11. Blast Radius

Antes de executar:

Affected entities
Affected people
Affected permits
Affected activities
Affected resources

deverão ser calculados.

12. Safety Intervention ≠ Business Action

Uma intervenção de segurança poderá afetar o negócio, mas seu objetivo primário deverá permanecer explícito:

Safety Objective

13. Intervention Authorization

Toda intervenção seguirá:

INTERVENTION
    ↓
POLICY
    ↓
AUTHORIZATION
    ↓
EXECUTION

14. Policy Boundary

O Agent poderá propor:

PAUSE_ACTIVITY

mas somente a Policy poderá determinar se ele possui autorização para executar essa ação.

15. Emergency Actions

A arquitetura deverá suportar ações emergenciais.

Exemplo:

EMERGENCY_STOP

Porém, mesmo ações emergenciais deverão possuir:

registered capability
authorization rule
scope
audit
verification

16. Autonomous Intervention Levels

LEVEL 0 — Observe
LEVEL 1 — Recommend
LEVEL 2 — Prepare
LEVEL 3 — Execute with confirmation
LEVEL 4 — Autonomous low-risk
LEVEL 5 — Emergency authorized automation

O nível máximo deverá ser definido por Policy.

17. Preventive Action

Uma ação preventiva poderá ser:

before incident

enquanto uma ação corretiva normalmente ocorre:

after failure/incident

18. Examples

Preventivas:

Renew training
Schedule inspection
Increase supervision
Replace degraded equipment
Add temporary control
Restrict activity

Corretivas:

Repair failed equipment
Correct failed control
Restore configuration

19. Intervention Planning

O PRD-032 será utilizado para determinar:

sequence
dependencies
resources
timing
parallelism
fallback

20. Intervention Plan

interface InterventionPlan {
  planId: string;

  interventionId: string;

  steps: InterventionStep[];

  dependencies: string[];

  risk: number;

  estimatedDuration?: number;

  requiredResources: string[];

  fallbackPlanId?: string;
}

21. Intervention Step

interface InterventionStep {
  stepId: string;

  capabilityId: string;

  input: unknown;

  dependencies: string[];

  preconditions: string[];

  postconditions: string[];

  verification: string[];

  status: string;
}

22. Intervention Preconditions

Exemplo:

Permit exists
+
Resource qualified
+
Authorization valid
+
Target state unchanged

23. Intervention Postconditions

Exemplo:

Training status = VALID

24. Safety Barrier

Uma intervenção poderá ativar ou restaurar uma barreira:

HAZARD
 ↓
SAFETY BARRIER
 ↓
RISK REDUCTION

25. Barrier Model

interface SafetyBarrier {
  barrierId: string;

  tenantId: string;

  name: string;

  type:
    | "PREVENTIVE"
    | "DETECTIVE"
    | "MITIGATING"
    | "RECOVERY";

  status:
    | "ACTIVE"
    | "FAILED"
    | "DEGRADED"
    | "UNKNOWN";

  controlRefs: string[];

  verificationRefs: string[];
}

26. Barrier Activation

Uma intervenção poderá:

activate barrier
restore barrier
strengthen barrier
replace barrier
verify barrier

27. Temporary Controls

Quando a solução definitiva não estiver disponível:

Permanent Control unavailable
        ↓
Temporary Control
        ↓
Risk reassessment

28. Temporary Control Expiration

Todo controle temporário deverá possuir:

createdAt
expiresAt
owner
reason
compensatingControl

29. No Permanent Silent Workaround

Um workaround temporário não poderá permanecer indefinidamente sem revisão.

30. Compensating Controls

PRD-042/044 poderá fornecer controles compensatórios.

Exemplo:

Primary control unavailable
+
Compensating control active

→ risco recalculado.

31. Intervention Resource Allocation

PRD-039 deverá localizar:

qualified person
available capacity
correct location
required authority

32. Resource Reservation

Antes da execução:

Resource
 ↓
RESERVE
 ↓
Intervention

33. Resource Failure

Se o recurso ficar indisponível:

Resource unavailable
 ↓
Reassignment

ou:

Human Review

34. Intervention Assignment

interface InterventionAssignment {
  assignmentId: string;

  interventionId: string;

  resourceId: string;

  role: string;

  status:
    | "PROPOSED"
    | "ASSIGNED"
    | "ACCEPTED"
    | "ACTIVE"
    | "COMPLETED"
    | "REJECTED";

  assignedAt: string;
}

35. Human Acceptance

Intervenções que exigem competência humana poderão exigir:

ASSIGN
 ↓
ACCEPT
 ↓
EXECUTE

36. Agent Assignment

Uma intervenção poderá ser atribuída a outro Agent.

Exemplo:

Safety Agent
 ↓
Training Agent
 ↓
Renewal Workflow

37. Multi-Agent Intervention

PRD-031 fornecerá:

REQUEST
HANDOFF
TASK
TASK_RESULT

38. Collaboration

PRD-040 poderá criar um workspace:

Intervention Workspace

quando houver múltiplos participantes.

39. Intervention Workspace

Deverá conter:

risk
decision
evidence
responsibility
assigned resources
actions
approvals
timeline
verification

40. Human Approval

Intervenções críticas poderão exigir:

Safety Review
+
Approval

antes da execução.

41. Approval Binding

A aprovação deverá estar vinculada a:

interventionId
targetVersion
riskVersion
policyVersion
contextVersion

42. Stale Approval

Se o estado mudar significativamente:

Approval
 ↓
STALE

e será necessária nova avaliação.

43. Intervention Execution

Execução sempre através de:

Capability Registry
 ↓
Policy
 ↓
Execution Runtime

44. No Arbitrary Commands

O Agent nunca poderá executar:

SQL arbitrário
HTTP arbitrário
device command arbitrário
shell command

como parte da intervenção.

45. Intervention Monitoring

Durante a execução:

State
Risk
Resource
Control
Time

serão monitorados.

46. Dynamic Intervention

Se as condições mudarem:

Intervention
 ↓
Risk Change
 ↓
Re-evaluate

47. Intervention Replanning

PRD-034 poderá adaptar:

batch size
concurrency
resource
retry
timeout

dentro do envelope autorizado.

48. Material Change

Se houver mudança material:

Pause
 ↓
Replan
 ↓
Policy
 ↓
Reapproval if required

49. Intervention Timeout

Toda intervenção deverá possuir:

deadline
timeout
escalation

quando aplicável.

50. Intervention Escalation

Assigned
 ↓
No response
 ↓
Supervisor
 ↓
Safety Manager
 ↓
Emergency escalation

51. Temporal Integration

PRD-037 definirá:

dueAt
deadline
business hours
grace period
escalation window

52. Attention Integration

PRD-038 criará:

ACTION_REQUIRED
APPROVAL_REQUIRED
ESCALATION
CRITICAL

conforme o caso.

53. Responsibility Integration

PRD-041 determinará:

Responsible
Accountable
Approver
Executor

54. Intervention Accountability

Deverá ser possível responder:

Quem autorizou a intervenção?

Quem executou?

Quem era responsável?

Quem verificou?

55. Intervention Evidence

Toda intervenção relevante deverá produzir evidências.

Before
 ↓
Action
 ↓
After

56. Before State

Registrar:

risk
controls
permit
resources
conditions

57. After State

Registrar:

risk
controls
permit
resources
conditions

58. Risk Reduction

O sistema deverá comparar:

Risk Before
vs
Risk After

59. Intervention Effectiveness

interface InterventionEffectiveness {
  interventionId: string;

  riskBefore: number;

  riskAfter: number;

  reduction: number;

  controlsRestored: string[];

  evidenceRefs: string[];

  verified: boolean;

  evaluatedAt: string;
}

60. Effectiveness ≠ Completion

Uma intervenção pode:

COMPLETED

mas:

NOT_EFFECTIVE

61. Example

Inspection completed
+
Risk remains HIGH

Resultado:

Intervention = COMPLETED
Effectiveness = INSUFFICIENT

62. Re-intervention

Nesse caso:

Risk still HIGH
 ↓
New Decision
 ↓
New Intervention

63. Intervention Verification

Verificação deverá utilizar:

Business State
Control State
Evidence
Risk
Operational State

64. Verification Capability

Capabilities:

intervention.verify
intervention.getEffectiveness
intervention.reassessRisk

65. Verification Failure

Se:

API success

mas:

postcondition false

a intervenção deverá ser:

FAILED_VERIFICATION

66. Partial Intervention

Exemplo:

workers
 ↓
retrained
pending

Resultado:

PARTIAL

67. Partial Risk

O risco deverá ser recalculado apenas para a população afetada quando possível.

68. Batch Intervention

Para operações em massa:

100 Work Permits

deverá existir:

blast radius
batch limit
progress
partial success
failure isolation

69. Batch Safety

Nunca executar:

1000 operations

sem respeitar limites definidos pela Policy.

70. Intervention Idempotency

Cada intervenção deverá possuir:

idempotencyKey

71. Duplicate Protection

Se a mesma intervenção for recebida novamente:

same intervention
+
same idempotencyKey

não deverá executar novamente indevidamente.

72. Retry

Retries apenas para falhas transitórias.

timeout
network
429
temporary dependency failure

73. No Retry

Não repetir automaticamente:

authorization denied
business rule violation
invalid input
unsafe state

74. Compensation

Quando configurado:

Action A
 ↓
Action B
 ↓
Action C fails
 ↓
Compensation

75. Irreversible Actions

Ações irreversíveis deverão possuir:

explicit capability
strong policy
appropriate authorization
confirmation/human review

76. Emergency Stop

Uma parada emergencial poderá interromper um workflow imediatamente, mas o sistema deverá registrar:

trigger
reason
actor
authorization
affected scope
state

77. Recovery

Após emergência:

STOPPED
 ↓
ASSESS
 ↓
REVIEW
 ↓
REAUTHORIZE
 ↓
RESUME

78. Intervention State Machine

PROPOSED
   │
   ▼
EVALUATING
   │
   ▼
AUTHORIZED
   │
   ▼
PLANNED
   │
   ▼
ASSIGNED
   │
   ▼
READY
   │
   ▼
EXECUTING
   │
   ▼
VERIFYING
   │
   ├──── success ────→ COMPLETED
   │
   ├──── partial ────→ PARTIAL
   │
   └──── failure ────→ FAILED

79. Intervention Events

InterventionProposed
InterventionAuthorized
InterventionAssigned
InterventionStarted
InterventionProgressed
InterventionBlocked
InterventionPaused
InterventionResumed
InterventionCompleted
InterventionPartiallyCompleted
InterventionFailed
InterventionVerified
InterventionEffectivenessEvaluated
InterventionEscalated

80. Intervention → Risk

Após conclusão:

InterventionCompleted
 ↓
Risk Reassessment

81. Closed-Loop Prevention

O objetivo final:

RISK
 ↓
ACTION
 ↓
RESULT
 ↓
RISK

Se o risco não cair:

REPLAN

82. Intervention Effectiveness Threshold

Uma intervenção poderá definir:

expectedRiskReduction

Exemplo:

Expected:
HIGH → MODERATE

83. Effectiveness Evaluation

Se resultado:

HIGH → LOW

→ efetividade superior ao esperado.

Se:

HIGH → HIGH

→ intervenção insuficiente.

84. Safety Barrier Verification

Após intervenção:

Barrier
 ↓
ACTIVE
 ↓
Evidence
 ↓
Verification

85. Control Verification

PRD-044 deverá confirmar:

Control = HEALTHY

86. Evidence Verification

PRD-045 deverá confirmar:

Evidence
Integrity
Freshness
Authority

87. Compliance Verification

PRD-042 deverá verificar:

Requirement
 ↓
Control
 ↓
Evidence
 ↓
COMPLIANT

88. Intervention Governance

Intervenções deverão possuir versões:

interventionDefinitionVersion
policyVersion
capabilityVersion
workflowVersion
riskModelVersion

89. Intervention Templates

Padrões reutilizáveis poderão ser definidos.

Exemplo:

Training Expiration Response

90. Template

interface InterventionTemplate {
  templateId: string;

  version: string;

  triggerConditions: string[];

  allowedActions: string[];

  requiredApprovals: string[];

  verificationRules: string[];

  escalationPolicyId?: string;
}

91. Templates Are Not Policies

Um template não poderá conceder autorização.

Template
 ≠
Policy

92. Natural Language

Usuário poderá dizer:

“Resolva esse risco.”

O Agent deverá interpretar:

Risk Reference
+
Desired Outcome

mas poderá precisar perguntar:

“Você quer que eu apenas prepare a intervenção ou autorize a execução?”

quando houver ambiguidade relevante.

93. Context Resolution

Utilizar:

explicit reference
>
selected entity
>
active risk
>
current activity
>
conversation context

94. Preventive Action from User Command

“Renove os treinamentos
dos trabalhadores desse permit.”

→

Intent
 ↓
Reference
 ↓
Risk/Compliance Context
 ↓
Intervention
 ↓
Policy
 ↓
Confirmation
 ↓
Execution

95. Safety Intervention UI

Semantic IDs:

intervention
intervention.details
intervention.risk
intervention.plan
intervention.resources
intervention.approval
intervention.progress
intervention.evidence
intervention.verification
intervention.timeline

96. Intervention Dashboard

Mostrar:

Active
Blocked
Critical
Waiting Approval
Executing
Failed
Pending Verification

97. Progress

Para intervenções longas:

32 / 100 completed

98. Live Progress

O frontend receberá eventos:

InterventionProgressed

via streaming.

99. User Cancellation

Uma intervenção poderá ser cancelada somente se:

policy allows cancellation

100. Cancellation Safety

Cancelar uma intervenção em andamento poderá ser mais perigoso que continuar.

Por isso:

Cancel
 ↓
Policy
 ↓
Evaluate current state

101. Intervention Conflict

Duas intervenções poderão entrar em conflito:

Intervention A
→ Resume Activity

Intervention B
→ Pause Activity

O sistema deverá detectar o conflito antes da execução.

102. Conflict Resolution

Utilizar:

Decision Intelligence
+
Policy
+
State Fabric

Não o Communication Fabric.

103. Intervention Priority

Em conflito:

EMERGENCY
>
CRITICAL
>
URGENT
>
HIGH
>
NORMAL
>
LOW

mas a Policy poderá definir regras específicas.

104. Operational Lock

Intervenções incompatíveis poderão adquirir lock lógico:

Permit WP-1001
Intervention Lock

105. Optimistic Concurrency

Antes de executar:

ExpectedVersion
=
CurrentVersion

Caso contrário:

STALE

106. Intervention Recovery

Em caso de falha:

Retry
Resume
Reassign
Compensate
Escalate
Abort

conforme o tipo da falha.

107. Incident Escalation

Se a intervenção falhar e o risco permanecer crítico:

Intervention Failed
 ↓
Risk Critical
 ↓
Incident
 ↓
Human Response

108. Incident Integration

PRD-024 receberá:

InterventionFailure
RiskCritical
SafetyBarrierFailure

109. Audit Integration

PRD-013 deverá registrar:

who requested
who authorized
who executed
what changed
what evidence was produced
what risk resulted

110. Learning Integration

PRD-012 deverá aprender com:

intervention
expected outcome
actual outcome
failure
effectiveness

111. Preventive Pattern Mining

Exemplo:

Training expiration
+
High workload
+
Repeated findings

frequentemente resulta em intervenção.

O sistema poderá sugerir um novo Intervention Pattern, mas não poderá publicá-lo automaticamente como comportamento autorizado.

112. Pattern Governance

Observed Pattern
 ↓
Human Review
 ↓
Evaluation
 ↓
Policy Review
 ↓
Release

113. Cost Optimization

Intervenções deverão evitar chamadas LLM desnecessárias.

Deterministic Intervention
→ no LLM

114. LLM Role

LLM poderá:

interpret request
summarize situation
suggest intervention
explain outcome

Não poderá:

authorize
bypass policy
invent evidence
execute arbitrary action

115. Intervention Explainability

O sistema deverá responder:

“Por que essa intervenção foi executada?”

Formato:

Trigger:
Equipment degraded

Risk:
HIGH

Decision:
Pause activity

Policy:
SAFETY-POLICY-17

Authorization:
Supervisor approval

Action:
permit.pause

Verification:
Permit state = PAUSED

116. Intervention Evidence Chain

Signal
 ↓
Risk
 ↓
Decision
 ↓
Policy
 ↓
Authorization
 ↓
Intervention
 ↓
Capability
 ↓
Evidence
 ↓
Verification

117. Historical Reconstruction

Deverá ser possível reconstruir:

“Por que o WP-1001 foi interrompido às 14:32?”

118. Point-in-Time

A resposta deverá usar:

Operational Snapshot
Risk Version
Policy Version
Capability Version
Evidence
Audit

daquele momento.

119. Intervention Metrics

intervention_success_rate
verification_success_rate
risk_reduction_rate
time_to_intervention
time_to_verification
human_approval_rate
automatic_intervention_rate
reassignment_rate
escalation_rate
failure_rate

120. Safety KPI

Indicadores importantes:

Mean Time to Detect
Mean Time to Intervene
Mean Time to Mitigate
Mean Time to Verify
Residual Critical Risk
Repeated Risk Rate

121. Intervention Quality

Uma intervenção rápida mas ineficaz não deve ser considerada sucesso.

Por isso:

Execution Success
+
Verification Success
+
Risk Reduction

definem efetividade.

122. Performance

Metas iniciais:

Intervention creation: &lt;100ms
Policy evaluation: &lt;30ms
Capability resolution: &lt;20ms
State verification: &lt;200ms

quando os dados estiverem disponíveis localmente/cacheados.

123. Security

Obrigatório:

tenant isolation
least privilege
delegation validation
authorization recheck
context freshness
idempotency
audit

124. Emergency Security

Ações emergenciais deverão ter:

strong authentication
restricted capability
explicit scope
full audit
post-action review

125. Safety Invariants

No intervention without authorization.

No critical intervention without required review.

No execution against stale critical state.

No unknown state treated as safe.

No arbitrary capability invocation.

No cross-tenant intervention.

No successful HTTP response treated as successful business result.

No intervention considered effective without verification.

126. First Vertical Slice

Training → Work Permit

Cenário:

TrainingExpired
      ↓
Affected Work Permits
      ↓
Risk HIGH
      ↓
Preventive Decision

127. Intervention Creation

O sistema cria:

Intervention:
Restore required training
for affected workers.

128. Resource Discovery

PRD-039 identifica:

Training Coordinator

129. Workflow

PRD-019 cria:

Training Renewal Workflow

130. Attention

PRD-038 notifica:

Responsible Supervisor

131. Execution

Training Agent utiliza:

training.external.getStatus
training.external.requestRenewal

através do External Gateway.

132. Evidence

LMS retorna:

Training renewed
validUntil = ...

133. Control

PRD-044 executa:

training.valid == true

134. Risk Reassessment

PRD-047:

HIGH
 ↓
MODERATE

135. Verification

State Fabric confirma:

Training = VALID
Work Permit = ELIGIBLE

136. Completion

Intervention:

COMPLETED

Effectiveness:

VERIFIED

137. Second Vertical Slice

Equipment Degradation

EquipmentDegraded
 ↓
Situation
 ↓
Risk HIGH
 ↓
Intervention
 ↓
Maintenance
 ↓
Verification
 ↓
Risk ↓

138. Third Vertical Slice

Critical Work Permit

Risk CRITICAL
 ↓
Pause Activity
 ↓
Human Review
 ↓
Inspection
 ↓
Control Restoration
 ↓
Risk Reassessment
 ↓
Resume

139. Acceptance Criteria

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

O módulo de intervenção e as rotas persistentes implementam templates, intervenções versionadas, precondições/pós-condições, autorização vinculada a Policy/approval, reserva de recursos, execução de capability, idempotência, timeout, escalonamento, replanejamento, recovery e emergency stop. As migrations 0028–0039 mantêm o estado tenant-scoped, guardas de concorrência e tabelas de execução, ordens de ação e provas de vertical slice. As rotas certificam, sem autorizar execução por si, Training→Work Permit, Equipment→Maintenance e Critical Risk→Pause→Review→Resume somente após ação concluída, redução de risco, controle PASS e evidência vinculada. A suíte focada passou com 39 testes em 9 arquivos em 2026-09-05.

Em 2026-09-05, o canário remoto canary:operational-awareness executou em elioria-agente o terceiro slice completo em tenant sintético isolado: risco crítico, pausa de emergência, avaliação pós-parada, revisão humana, reautorização com snapshot novo, nova reserva de capacidade e retomada controlada. A prova confirmou a recuperação persistida, a reserva original liberada, a nova reserva ativa e a cadeia de auditoria imutável; o Worker publicado foi b2dfc9e1-2842-44bb-ab62-c80a46409b39.

Em 2026-09-05, o canário remoto canary:external-lms executou o primeiro slice em tenant sintético isolado: solicitação de renovação, confirmação autenticada pelo LMS via binding privado, recibo e certificado do provedor, evidências ativas vinculadas ao Work Permit, controle determinístico PASS, previsões governadas de HIGH/.8 para LOW/.1, verificação de efetividade e manifesto TRAINING_WORK_PERMIT imutável. A limpeza confirmou remainingRows:0.

Em 2026-09-05, o mesmo canário remoto executou o segundo slice em tenant sintético isolado: degradação de equipamento, ordem de manutenção/calibração via binding privado, confirmação autenticada e certificado do provedor, evidências ativas vinculadas, controle determinístico PASS, previsões governadas de HIGH/.8 para LOW/.1, verificação de efetividade e manifesto EQUIPMENT_MAINTENANCE imutável. A limpeza confirmou remainingRows:0.

Ainda não há prova contra um provedor externo não sintético nem prova de compensação/failover sob falha de integração; esses limites não são inferidos a partir do canário LMS.

Em 2026-09-06, a regressão atual de escalonamento, execução, recovery, replanejamento, reservas, liberação terminal, vertical slices, intervenções e workflow passou com 103 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, sem transformar os limites de provedores externos e failover em prova já obtida.

140. Resultado Arquitetural

Com o PRD-049, o Agentic Work deixa de apenas detectar e recomendar prevenção e passa a possuir um mecanismo formal para executar e comprovar a eficácia das intervenções.

A arquitetura passa a fechar o ciclo:

                 REAL WORLD
                     │
                     ▼
              OPERATIONAL STATE
                     │
                     ▼
                  SIGNAL
                     │
                     ▼
                   RISK
                     │
                     ▼
                 DECISION
                     │
                     ▼
                  POLICY
                     │
                     ▼
               INTERVENTION
                     │
              ┌──────┴──────┐
              ▼             ▼
          RESOURCES      WORKFLOW
              │             │
              └──────┬──────┘
                     ▼
                 EXECUTION
                     │
                     ▼
                 EVIDENCE
                     │
                     ▼
                VERIFICATION
                     │
                     ▼
               RISK UPDATED
                     │
              ┌──────┴──────┐
              ▼             ▼
          EFFECTIVE       FAILED
              │             │
              ▼             ▼
           CLOSE         REPLAN

Isso é uma mudança importante de paradigma:

o Agent deixa de ser apenas um sistema que “entende o que fazer” e passa a ser um sistema capaz de coordenar uma intervenção completa, respeitando autoridade, segurança, responsabilidade, recursos e verificação.

PRD-050 — Agentic Safety Command Center & Operational Control Plane

O próximo PRD deverá subir mais um nível: em vez de tratar cada intervenção isoladamente, criar uma visão operacional centralizada de toda a organização, permitindo ao Agent coordenar simultaneamente:

RISK
├── Critical Activities
├── Work Permits
├── People
├── Equipment
├── Controls
├── Incidents
├── Interventions
├── Resources
├── Compliance
└── Regulatory Changes

O PRD-050 deverá abordar Safety Command Center, Operational Control Plane, Enterprise Safety State, Global Operational View, Multi-Site Operations, Cross-Department Coordination, Command Center Dashboard, Live Risk Map, Risk Portfolio, Safety KPIs, Operational Prioritization, Critical Situation Management, Intervention Portfolio, Resource Portfolio, Organization-Wide Risk Aggregation, Cross-Entity Correlation, Safety Objectives, Operational Health Score, Leading Indicators, Lagging Indicators, Safety Performance Trends, Executive Decision Support, Situation Room, Incident Room, Emergency Coordination, Multi-Agent Coordination, Human Command, Delegated Authority, Escalation Matrix, Command Policies, Operational Playbooks, Real-Time Simulation, What-If Analysis, Enterprise Digital Twin, Operational Replay, Cross-Tenant Boundaries, Data Aggregation Governance, Executive Audit, Strategic Risk Management e Safety Governance.

O princípio central será:

O sistema não deverá apenas saber o que está acontecendo em cada operação; deverá conseguir construir uma visão coerente de onde estão os maiores riscos, quais intervenções estão em andamento, quais recursos estão disponíveis e onde a organização precisa concentrar sua atenção agora.

1. Objetivo​

2. Princípio Fundamental

3. Intervention ≠ Recommendation

4. Intervention Model

5. Intervention Types

6. Intervention Lifecycle

7. Intervention Status

8. Intervention Priority

9. Intervention Objective

10. Intervention Scope

11. Blast Radius

12. Safety Intervention ≠ Business Action

13. Intervention Authorization

14. Policy Boundary

15. Emergency Actions

16. Autonomous Intervention Levels

17. Preventive Action

18. Examples

19. Intervention Planning

20. Intervention Plan

21. Intervention Step

22. Intervention Preconditions

23. Intervention Postconditions

24. Safety Barrier

25. Barrier Model

26. Barrier Activation

27. Temporary Controls

28. Temporary Control Expiration

29. No Permanent Silent Workaround

30. Compensating Controls

31. Intervention Resource Allocation

32. Resource Reservation

33. Resource Failure

34. Intervention Assignment

35. Human Acceptance

36. Agent Assignment

37. Multi-Agent Intervention

38. Collaboration

39. Intervention Workspace

40. Human Approval

41. Approval Binding

42. Stale Approval

43. Intervention Execution

44. No Arbitrary Commands

45. Intervention Monitoring

46. Dynamic Intervention

47. Intervention Replanning

48. Material Change

49. Intervention Timeout

50. Intervention Escalation

51. Temporal Integration

52. Attention Integration

53. Responsibility Integration

54. Intervention Accountability

55. Intervention Evidence

56. Before State

57. After State

58. Risk Reduction

59. Intervention Effectiveness

60. Effectiveness ≠ Completion

61. Example

62. Re-intervention

63. Intervention Verification

64. Verification Capability

65. Verification Failure

66. Partial Intervention

67. Partial Risk

68. Batch Intervention

69. Batch Safety

70. Intervention Idempotency

71. Duplicate Protection

72. Retry

73. No Retry

74. Compensation

75. Irreversible Actions

76. Emergency Stop

77. Recovery

78. Intervention State Machine

79. Intervention Events

80. Intervention → Risk

1. Objetivo

Training → Work Permit

Equipment Degradation

Critical Work Permit

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