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

1. Objetivo

O PRD-048 transforma o Agentic Work de um sistema predominantemente orientado a solicitações, eventos e avaliações em um sistema capaz de manter uma visão contínua do estado operacional de segurança.

Até aqui, construímos:

Conhecimento
     ↓
Compliance
     ↓
Controles
     ↓
Evidências
     ↓
Auditoria
     ↓
Risco
     ↓
Prevenção

Agora acrescentamos:

ESTADO OPERACIONAL EM TEMPO REAL
              ↓
      SITUAÇÃO OPERACIONAL
              ↓
       RISCO DINÂMICO
              ↓
        INTERVENÇÃO

O sistema deverá conseguir perceber que:

uma atividade começou;
determinado Work Permit entrou em execução;
uma pessoa está associada à atividade;
um recurso deixou de estar disponível;
uma qualificação expirou;
uma condição operacional mudou;
um controle deixou de estar efetivo;
uma combinação de sinais criou uma situação de risco;
uma operação está se desviando do estado esperado.

2. Princípio Fundamental

O Agent deve conhecer o estado operacional atual antes de decidir sobre qualquer ação operacional.

Portanto:

PERCEPTION
    ↓
CONTEXT
    ↓
STATE
    ↓
RISK
    ↓
DECISION
    ↓
ACTION

Nunca:

EVENT
 ↓
LLM
 ↓
ACTION

3. Operational Awareness

Operational Awareness representa a capacidade do sistema de responder:

“O que está acontecendo agora?”

e não apenas:

“O que aconteceu?”

Exemplo:

WP-1001
    │
    ├── Activity: Maintenance
    ├── Status: IN_PROGRESS
    ├── Team: Team-A
    ├── Supervisor: EMP-20
    ├── Inspector: EMP-35
    ├── Equipment: EQ-10
    ├── Training: VALID
    ├── Controls: ACTIVE
    └── Risk: HIGH

4. Arquitetura

             REAL-TIME SOURCES
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
     EVENTS       SENSORS      APIs
       │            │            │
       └────────────┼────────────┘
                    ↓
             EVENT PROCESSOR
                    ↓
            STATE SYNCHRONIZER
                    ↓
          OPERATIONAL STATE FABRIC
                    ↓
          SITUATION DETECTION
                    ↓
             RISK ENGINE
                    ↓
           DECISION INTELLIGENCE
                    ↓
                POLICY
                    ↓
        ┌───────────┴───────────┐
        ↓                       ↓
    ATTENTION               INTERVENTION
        │                       │
        └───────────┬───────────┘
                    ↓
               VERIFICATION

5. Operational State

O sistema deverá manter uma projeção operacional atualizada.

interface OperationalState {
  tenantId: string;

  entityType: string;
  entityId: string;

  status: string;

  version: number;

  activeActivities: string[];

  peopleRefs: string[];

  resourceRefs: string[];

  permitRefs: string[];

  hazardRefs: string[];

  controlRefs: string[];

  riskRefs: string[];

  location?: LocationContext;

  temporalContext: TemporalContext;

  observedAt: string;

  sourceVersions: Record<string, string>;
}

6. State Ownership

O Operational Awareness não será a fonte primária dos dados transacionais.

Por exemplo:

Work Permit status
       ↓
Business API
       ↓
Canonical Business State
       ↓
Operational Projection

O sistema operacional poderá manter uma projeção rápida, mas o sistema transacional continua sendo a autoridade.

7. Real-Time Sources

Fontes possíveis:

Business APIs
Event Fabric
Workflow
Execution Runtime
Resource Registry
Training/LMS
Inspection System
Incident System
Access Control
IoT
Sensors
Mobile Devices
GPS
External APIs
Environmental Systems
User Actions

8. Event Fabric Integration

PRD-020 será a principal fonte de eventos.

Exemplo:

WorkPermitStarted
TrainingExpired
WorkerAssigned
EquipmentUnavailable
ControlFailed
IncidentReported

Cada evento poderá provocar atualização da situação operacional.

9. Sensor Integration

Sensores poderão produzir:

temperature
pressure
gas
noise
motion
location
equipment_state
machine_state
environmental_condition

O Agent não deverá consumir diretamente protocolos arbitrários.

Tudo deverá passar por um Sensor/Device Gateway.

10. Device Gateway

DEVICE
  ↓
DEVICE GATEWAY
  ↓
VALIDATION
  ↓
NORMALIZATION
  ↓
EVENT FABRIC
  ↓
OPERATIONAL STATE

11. Sensor Data ≠ Evidence

Uma leitura de sensor não é automaticamente evidência regulatória.

Deverá existir:

RAW_SIGNAL
     ↓
VALIDATED_OBSERVATION
     ↓
EVIDENCE

quando os requisitos de evidência forem satisfeitos.

12. Observation

interface OperationalObservation {
  observationId: string;

  tenantId: string;

  sourceId: string;

  subjectRefs: string[];

  type: string;

  value: unknown;

  unit?: string;

  observedAt: string;

  receivedAt: string;

  quality: number;

  status:
    | "VALID"
    | "INVALID"
    | "SUSPECT"
    | "STALE"
    | "UNKNOWN";
}

13. Data Quality

Cada observação deverá possuir qualidade.

Exemplo:

Sensor:
Temperature = 87°C

Quality = 0.98

versus:

Sensor:
Temperature = 87°C

Quality = 0.21

O segundo caso não deverá ser tratado da mesma forma.

14. Device Health

O sistema deverá monitorar:

ONLINE
DEGRADED
OFFLINE
UNKNOWN
MAINTENANCE

15. Sensor Failure

Se um sensor crítico desaparecer:

SensorOffline
      ↓
Operational Risk
      ↓
Policy Evaluation

A ausência de dados não significa condição segura.

16. Real-Time Context

O contexto operacional deverá incluir:

who
what
where
when
why
with_what
under_which_permit
under_which_controls
under_which_conditions

17. Activity Awareness

O sistema deverá identificar atividades em andamento.

Exemplo:

WP-1001
Activity = Electrical Maintenance
State = IN_PROGRESS

18. Activity Lifecycle

PLANNED
AUTHORIZED
STARTING
IN_PROGRESS
PAUSED
COMPLETING
COMPLETED
CANCELLED

19. Permit Correlation

O Work Permit deverá ser correlacionado com:

activity
workers
supervisor
location
equipment
hazards
controls
workflow
risk

20. Permit Runtime State

interface PermitOperationalState {
  permitId: string;

  status: string;

  activityStatus: string;

  assignedWorkers: string[];

  activeControls: string[];

  activeHazards: string[];

  currentRisk: string;

  location?: LocationContext;

  startedAt?: string;

  lastObservedAt: string;
}

21. Worker Awareness

O sistema deverá saber, dentro dos limites legais e de privacidade:

worker
assignment
qualification
training
current activity
current permit
role
responsibility

22. Worker Location

Se localização for utilizada, ela deverá ser:

purpose-bound
authorized
tenant-scoped
minimized
time-bounded

Não deverá existir rastreamento indiscriminado apenas porque a plataforma possui capacidade técnica.

23. Qualification Awareness

O sistema deverá verificar:

Worker
+
Activity
+
Required Qualification
+
Validity

24. Real-Time Qualification Violation

Exemplo:

Worker assigned
      ↓
Qualification expired
      ↓
Operational Situation
      ↓
Risk ↑

25. Resource Awareness

PRD-039 fornece:

resource availability
capacity
qualification
health
assignment

26. Equipment Awareness

Equipamentos deverão possuir estado:

AVAILABLE
IN_USE
DEGRADED
FAILED
MAINTENANCE
LOCKED
UNKNOWN

27. Equipment Risk

Exemplo:

Critical Activity
+
Required Equipment
+
Equipment = DEGRADED

→ situação potencialmente insegura.

28. Location Awareness

O sistema poderá utilizar zonas sem depender necessariamente de GPS de alta precisão.

Exemplo:

ZONE-A
ZONE-B
RESTRICTED-ZONE
HIGH-RISK-ZONE
EMERGENCY-ZONE

29. Safety Zones

Cada zona poderá definir:

hazards
required_controls
required_roles
restricted_activities
required_qualifications

30. Geofencing

Eventos:

WorkerEnteredZone
WorkerExitedZone
EquipmentEnteredZone
PermitStartedInZone
UnauthorizedActivityInZone

31. Geofence Security

Geofence não deverá sozinho determinar autorização.

Location
 ≠
Authorization

A Policy Engine continua sendo autoridade.

32. Situation Detection

O sistema deverá detectar combinações significativas.

Exemplo:

Activity = Confined Space
+
Worker = Qualified
+
Gas Sensor = Normal
+
Control = Active

→ situação normal.

Mas:

Activity = Confined Space
+
Gas Sensor = Critical

→ situação crítica.

33. Situation Model

interface OperationalSituation {
  situationId: string;

  tenantId: string;

  type: string;

  status:
    | "NORMAL"
    | "DEGRADED"
    | "WARNING"
    | "CRITICAL"
    | "UNKNOWN";

  entityRefs: string[];

  evidenceRefs: string[];

  signalRefs: string[];

  riskRefs: string[];

  detectedAt: string;

  lastUpdatedAt: string;
}

34. Situation Rules

Regras deverão ser declarativas.

Exemplo:

IF
  permit.activity = CONFINED_SPACE
AND
  gas.co = CRITICAL

THEN
  situation = CRITICAL

35. Complex Event Processing

Deverá existir suporte para padrões:

A followed by B
A and B within 5 minutes
A repeated 5 times
A without B
A and B in same zone
A + B + C

36. Temporal Correlation

Exemplo:

ControlFailed
+
IncidentReported
within 10 minutes

poderá criar uma situação operacional especial.

37. Spatial Correlation

EquipmentFailure
+
WorkerPresence
+
SameZone

poderá gerar risco aumentado.

38. Entity Correlation

Worker
+
Permit
+
Equipment
+
Location
+
Hazard

deverão ser correlacionados pelo Knowledge/State Graph.

39. Situation Confidence

Uma situação poderá ter:

confidence
uncertainty
dataQuality

40. Unknown Situation

Se os dados necessários não estiverem disponíveis:

Situation = UNKNOWN

Não:

Situation = SAFE

41. Dynamic Risk

O PRD-047 deverá ser executado continuamente.

Operational Event
       ↓
Situation Update
       ↓
Risk Recalculation

42. Risk Escalation

Exemplo:

00 LOW
05 MODERATE
07 HIGH
08 CRITICAL

Cada transição deverá ser registrada.

43. Risk Decay

Quando a condição desaparecer:

Hazard removed
+
Control restored
+
Evidence validated

o risco poderá diminuir.

44. Real-Time Control Monitoring

PRD-044 deverá informar:

Control HEALTHY
Control FAILED
Control UNKNOWN

45. Safety Watchdog

O sistema deverá possuir watchdogs para situações críticas.

Exemplo:

Permit IN_PROGRESS
+
Required Control
+
No heartbeat

→ gerar:

CONTROL_STATUS_UNKNOWN

46. Heartbeat

Atividades críticas poderão exigir:

heartbeat

com intervalo configurável.

47. Heartbeat Failure

Heartbeat missing
 ↓
Grace Period
 ↓
Recheck
 ↓
Attention
 ↓
Policy Action

48. Dynamic Permit State

Um Work Permit poderá passar:

ACTIVE
 ↓
AT_RISK
 ↓
PAUSED

sem necessariamente ser cancelado.

49. Permit Blocking

Determinadas condições poderão impedir:

START
RESUME
RELEASE

de uma atividade.

50. Policy Boundary

O Real-Time Awareness detecta.

O Policy Engine decide se pode bloquear.

O Capability Runtime executa.

Detection
 ↓
Risk
 ↓
Policy
 ↓
Capability

51. Emergency Intervention

Intervenções críticas deverão ter capabilities explicitamente registradas.

Exemplos:

permit.pause
permit.requestEmergencyReview
equipment.shutdown
activity.stop

52. Emergency Autonomy

Por padrão:

CRITICAL
 ↓
Human Attention

A execução automática só poderá ocorrer quando uma política de segurança explicitamente autorizá-la.

53. Human Override

O operador autorizado poderá:

ACKNOWLEDGE
PAUSE
STOP
RESUME
ESCALATE
REQUEST_REVIEW

conforme suas permissões.

54. Override Audit

Todo override deverá registrar:

who
what
when
why
previousState
newState
policy
authorization

55. Operational Timeline

O sistema deverá reconstruir:

00 Permit Started
03 Worker Entered Zone
05 Equipment Degraded
06 Risk Increased
07 Alert Sent
08 Supervisor Acknowledged
10 Activity Paused
20 Equipment Restored
22 Risk Reassessed
25 Activity Resumed

56. Timeline ≠ Audit

A timeline é uma visão operacional.

O Audit Fabric continua sendo a fonte formal de auditoria.

57. Real-Time Attention

PRD-038 receberá:

situation
risk
urgency
responsibility
location
affectedActivity

58. Attention Routing

PRD-041 + PRD-039 poderão determinar:

Who should receive this?

considerando:

responsibility
qualification
availability
location
priority

59. Incident Early Detection

Se ocorrer:

multiple abnormal signals
+
rapid risk increase

o sistema poderá criar:

PotentialIncident

60. Potential Incident ≠ Incident

O sistema deverá manter:

OBSERVATION
SIGNAL
SITUATION
POTENTIAL_INCIDENT
INCIDENT

como entidades diferentes.

61. Incident Confirmation

Um Potential Incident deverá ser confirmado por:

human
deterministic rule
validated evidence
external system

dependendo da política.

62. Operational Digital Twin

O sistema deverá construir uma representação semântica do ambiente operacional.

FACILITY
 ├── ZONE-A
 │    ├── WORKER-1
 │    ├── EQUIPMENT-2
 │    └── WP-1001
 │
 └── ZONE-B
      └── EQUIPMENT-5

63. Digital Twin Principle

O Digital Twin é uma projeção operacional.

Não deverá substituir:

ERP
SST Database
LMS
HR
Equipment System

64. Twin State

Cada objeto deverá ter:

currentState
version
observedAt
source
confidence

65. Twin Synchronization

PRD-035 será responsável por evitar:

Twin says ACTIVE
Business says COMPLETED

66. State Conflict

Em conflito:

UNKNOWN / CONFLICTED

até resolução.

67. Real-Time Knowledge

Eventos operacionais poderão atualizar o Knowledge Fabric:

Operational Observation
 ↓
Validated Fact
 ↓
Knowledge Record

quando apropriado.

68. No Automatic Fact Promotion

Uma observação ou inferência não deverá automaticamente virar conhecimento permanente.

Deverá passar por:

validation
provenance
authority

quando necessário.

69. Agent Queries

O usuário poderá perguntar:

“O que está acontecendo agora na área de manutenção?”

O Agent deverá responder a partir do:

Operational State
+
Current Events
+
Risk
+
Attention

70. Natural Language Situation Query

Exemplos:

“Tem alguma atividade crítica em risco agora?”

“Qual Work Permit está bloqueado?”

“Por que o WP-1001 foi pausado?”

“Quem está responsável por essa atividade?”

71. Real-Time Explanation

A resposta deverá apontar:

Current State
Evidence
Risk
Policy
Action

72. Streaming

O frontend poderá receber:

SITUATION_UPDATED
RISK_CHANGED
ATTENTION_CREATED
PERMIT_PAUSED
CONTROL_FAILED

em streaming.

73. UI Semantic Integration

Novos IDs:

operations.dashboard
operations.live-map
operations.activity
operations.situation
operations.risk
operations.alert
operations.timeline
operations.zone
operations.resource

74. Live Operations Dashboard

O dashboard deverá mostrar:

Active Activities
Critical Situations
High Risks
Blocked Permits
Offline Controls
Resource Issues
Pending Interventions

75. Live Map

Quando aplicável:

Zones
Activities
Resources
Equipment
Risk Areas

deverão ser semanticamente identificáveis.

76. Map Interaction

O usuário poderá selecionar:

ZONE-A

e perguntar:

“O que está acontecendo aqui?”

O contexto semântico deverá incluir a zona selecionada.

77. No Arbitrary Map Coordinates

O Agent deverá operar através de:

zoneId
entityId
semanticId

e não através de coordenadas ou elementos DOM.

78. Operational Context Snapshot

interface OperationalContextSnapshot {
  snapshotId: string;

  tenantId: string;

  entityRefs: string[];

  stateVersions: Record<string, number>;

  activeSituations: string[];

  activeRisks: string[];

  activeControls: string[];

  currentTime: string;

  locationContext?: string;

  createdAt: string;
}

79. Snapshot Pinning

Uma decisão crítica deverá referenciar o snapshot utilizado.

Isso permite:

What did the Agent know at that moment?

80. Stale Context

Se:

snapshot.version != current.version

a decisão poderá precisar ser reavaliada.

81. Real-Time Decision

Situation
 ↓
Risk
 ↓
Decision
 ↓
Policy
 ↓
Action

82. Decision Freshness

Decisões críticas deverão possuir:

validFor
expiresAt
requiredRevalidation

83. Real-Time Revalidation

Antes da execução:

Current State
vs
Decision Snapshot

Se houver alteração material:

REVALIDATE

84. Operational Safety Boundary

Nenhuma alteração de estado operacional deverá conceder autoridade adicional.

Real-Time Awareness
≠
Authorization

85. Security

O sistema deverá impedir:

cross-tenant visibility
unauthorized location access
unauthorized worker tracking
unauthorized sensor data
unauthorized emergency action

86. Data Minimization

O Agent deverá receber apenas:

data necessary for current task

e não todo o Digital Twin.

87. Tenant Isolation

Todo:

event
observation
state
situation
risk
device
zone
location

deverá ser tenant-scoped.

88. External Device Security

Dispositivos deverão possuir:

device identity
credential
tenant binding
status
revocation

89. Device Command Boundary

O Agent não poderá enviar comandos arbitrários a dispositivos.

Deverá usar:

Capability Registry
+
Policy
+
Device Gateway

90. Example

Não:

LLM → MQTT

Mas:

Agent
 ↓
equipment.shutdown
 ↓
Policy
 ↓
Device Capability
 ↓
Device Gateway
 ↓
Equipment
 ↓
Verification

91. Offline Mode

O sistema deverá suportar conectividade intermitente.

DEVICE
 ↓
LOCAL BUFFER
 ↓
GATEWAY
 ↓
EVENT FABRIC

92. Event Ordering

Cada evento deverá possuir:

eventId
sequence
occurredAt
receivedAt

93. Late Events

Eventos atrasados deverão ser tratados sem corromper o estado atual.

94. Duplicate Events

Consumidores deverão ser idempotentes.

eventId
+
consumerId

poderão formar a chave de deduplicação.

95. Event Storm Protection

O sistema deverá suportar:

debounce
aggregation
sampling
throttling
backpressure

96. Critical Event Priority

Eventos de segurança crítica terão prioridade sobre eventos informativos.

97. Operational State Store

Deverá existir uma abstração:

interface OperationalStateStore {
  get(
    tenantId: string,
    entityType: string,
    entityId: string
  ): Promise<OperationalState | null>;

  compareAndSet(
    key: string,
    expectedVersion: number,
    state: OperationalState
  ): Promise<boolean>;
}

98. Cloudflare Compatibility

A implementação não deverá depender de memória local do Worker.

Deverá utilizar abstrações compatíveis com:

D1
KV
Durable Objects
Queues
Workflows
R2
Vectorize

conforme o caso de uso.

99. Hot State

Estado operacional frequentemente consultado poderá utilizar:

KV / Durable Object / cache

conforme requisitos de consistência.

100. Historical State

Estados históricos deverão permanecer disponíveis para:

audit
investigation
incident reconstruction
decision replay
risk analysis

101. Operational Replay

Será possível reconstruir:

What happened?
When?
Which state changed?
Which risk changed?
Which action occurred?

102. Replay Modes

OBSERVE
SIMULATION
DRY_RUN

Nunca replay produtivo deverá alterar o ambiente sem autorização explícita.

103. Operational Simulation

Poderá responder:

“O que aconteceria se esse equipamento fosse indisponibilizado?”

Current State
 ↓
Hypothetical Event
 ↓
Situation Detection
 ↓
Risk
 ↓
Resource Impact
 ↓
Decision

104. Capacity Integration

Se houver:

Critical Activity
+
Inspector unavailable

PRD-039 poderá buscar substituto.

105. Temporal Integration

PRD-037 poderá detectar:

permit expiration
shift end
SLA breach
inspection window

106. Workflow Integration

PRD-019 poderá reagir:

Critical Situation
 ↓
Workflow Paused
 ↓
Human Review

107. Exception Integration

PRD-024 tratará:

sensor outage
state conflict
unknown location
control failure
gateway failure

108. Communication Integration

PRD-031 poderá comunicar:

Safety Agent
 ↓
Risk Agent
 ↓
Supervisor Agent

109. Collaboration Integration

PRD-040 poderá abrir:

Safety Review Workspace

quando intervenção humana for necessária.

110. Accountability Integration

PRD-041 determinará:

Who should act?
Who is accountable?
Who can authorize?

111. Compliance Integration

PRD-044 poderá avaliar controles em tempo real.

112. Audit Integration

PRD-045 registrará evidências relevantes.

PRD-046 poderá posteriormente reconstruir o evento.

113. Incident Integration

PRD-024 receberá:

PotentialIncident

quando os critérios forem atingidos.

114. Proactive Integration

PRD-021 poderá utilizar:

real-time risk
+
historical risk

para gerar prevenção.

115. Attention Integration

PRD-038 poderá gerar:

CRITICAL
ACTION_REQUIRED

e encaminhar ao responsável correto.

116. Example — Critical Equipment Failure

Equipment EQ-10
     ↓
EquipmentFailure
     ↓
Event Fabric
     ↓
Operational State
     ↓
WP-1001 affected
     ↓
Risk Recalculation
     ↓
CRITICAL
     ↓
Policy
     ↓
Attention
     ↓
Supervisor

117. Optional Automated Intervention

Se existir capability autorizada:

permit.pause

o sistema poderá:

Policy
 ↓
Capability
 ↓
Pause Permit
 ↓
Verify

118. Verification

Não basta:

API returned 200

O sistema deverá verificar:

Permit state = PAUSED

através do Business State.

119. False Positive Protection

Antes de intervenção crítica:

Signal
 ↓
Validation
 ↓
Correlation
 ↓
Risk
 ↓
Policy

evitando ação baseada em um único sinal defeituoso quando a política exigir confirmação.

120. False Negative Protection

Para condições críticas, ausência de dados deverá elevar:

uncertainty

e poderá exigir:

human verification

121. Safety Invariants

O sistema deverá manter invariantes como:

Expired mandatory qualification
→ cannot be treated as valid.

Critical control unavailable
→ cannot be treated as healthy.

Unknown sensor
→ cannot automatically mean safe.

Unauthorized user
→ cannot execute intervention.

Cross-tenant entity
→ cannot enter operational context.

122. Performance

Objetivos iniciais:

Event ingestion: &lt;100ms target
State projection: &lt;200ms target
Situation detection: &lt;300ms target
Risk recalculation: &lt;500ms target

Para caminhos críticos, os valores finais deverão ser validados em ambiente real.

123. LLM Usage

O caminho normal deverá ser:

EVENT
 ↓
RULE
 ↓
STATE
 ↓
RISK
 ↓
POLICY

O LLM será utilizado apenas quando necessário para:

unstructured interpretation
incident narratives
operator messages
complex explanation

124. Cost Control

Evitar:

Event → LLM

para milhares de eventos.

Preferir:

Event → deterministic processor

e chamar LLM somente quando houver valor semântico adicional.

125. Observability

Cada situação deverá possuir:

traceId
situationId
eventRefs
riskRefs
policyRefs
actionRefs

126. Metrics

Principais métricas:

event_processing_latency
state_projection_latency
situation_detection_latency
risk_update_latency
false_positive_rate
false_negative_rate
unknown_rate
intervention_rate
verification_failure_rate
sensor_failure_rate

127. Safety Metrics

Especialmente:

critical_detection_recall
critical_false_negative_rate
unsafe_intervention_rate
missed_intervention_rate

128. Testing

Deverão existir testes para:

event ordering
duplicate events
late events
sensor outage
state conflicts
risk escalation
risk de-escalation
geofence
qualification expiration
equipment failure
network outage
gateway failure

129. Chaos Testing

Simular:

50% sensors offline
event storm
network latency
duplicate events
out-of-order events
database degradation
external gateway unavailable

130. Security Testing

Testes obrigatórios:

tenant isolation
unauthorized location access
privilege escalation
device impersonation
fake sensor
event injection
replay attack
duplicate command
emergency capability abuse

131. Device Event Authenticity

Eventos externos deverão possuir:

deviceId
credential
signature where required
timestamp
nonce/replay protection

132. Event Injection

Um usuário ou sistema externo não autorizado não poderá fabricar:

EquipmentHealthy
ControlPassed
WorkerQualified
PermitSafe

133. Audit

Para cada intervenção:

Detection
 ↓
Situation
 ↓
Risk
 ↓
Policy
 ↓
Authorization
 ↓
Capability
 ↓
Execution
 ↓
Verification

deverá existir rastreabilidade.

134. First Vertical Slice

Work Permit em tempo real

Cenário:

WP-1001
Activity = Electrical Maintenance
Status = IN_PROGRESS

135. Initial State

Workers = Qualified
Equipment = Healthy
Controls = Active
Risk = MODERATE

136. Event

O sistema recebe:

EquipmentDegraded(EQ-10)

137. Situation Detection

O sistema identifica:

Critical Activity
+
Equipment Degraded
+
Affected Permit

138. Risk

PRD-047 recalcula:

Risk = HIGH

139. Policy

Policy verifica:

HIGH risk
+
critical equipment
+
active permit

140. Attention

PRD-038 gera:

HIGH
ACTION_REQUIRED

para o responsável.

141. Human Review

Supervisor recebe:

“O equipamento EQ-10 associado ao WP-1001 entrou em estado degradado. O risco da atividade foi elevado para HIGH.”

142. Intervention

O supervisor poderá selecionar:

PAUSE PERMIT
REQUEST INSPECTION
REPLACE EQUIPMENT
CONTINUE WITH CONTROL

conforme permissões.

143. Reassessment

Depois:

Equipment = Healthy
Control = Verified

Risk Engine executa novamente.

144. Resume

Se Policy permitir:

Risk ↓
+
Controls PASS
+
Equipment Healthy

o Workflow poderá solicitar:

RESUME

145. Verification

Business API deverá confirmar:

WP-1001.status = IN_PROGRESS

após a retomada.

146. Complete Timeline

O sistema deverá produzir:

WP Started
    ↓
Equipment Degraded
    ↓
Situation Detected
    ↓
Risk Increased
    ↓
Attention Created
    ↓
Supervisor Notified
    ↓
Permit Paused
    ↓
Equipment Repaired
    ↓
Control Verified
    ↓
Risk Reassessed
    ↓
Permit Resumed

147. Acceptance Criteria

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

O slice de Work Permit possui fontes operacionais tenant-safe com identidade por hash, allowlist de zonas, limite por minuto e heartbeat opcional; eventos são deduplicados por versão, preservam ordenação por observedAt e projetam uma situação determinística com snapshot SHA-256. Qualidade insuficiente, sensor indisponível e heartbeat vencido resultam em UNKNOWN, nunca em estado seguro; correlação de falha de equipamento com pessoas presentes produz CRITICAL. A projeção para Attention é deduplicada e somente cria um item humano OPEN, sem autorizar intervenção ou execução.

O Worker 5c7e1222-c047-47a4-97b8-e0093cc2672d foi publicado após os gates. O canário sintético autenticado comprovou CRITICAL → UNKNOWN por watchdog vencido → NORMAL, uma source, três eventos, uma situação e uma Attention no D1, isolamento entre tenants, negação anônima e authorizesExecution:false; o cleanup PostgreSQL foi concluído. Isso não comprova device gateway real, digital twin, nem as integrações operacionais amplas restantes.

Em 2026-09-05, a migration remota 0127_operational_geofence_policies.sql e o Worker 5d1f6bb0-af4a-4ada-a9e5-2aa8bd206339 adicionaram políticas de geofence tenant-scoped e versionadas. Uma fonte precisa estar vinculada a uma política ACTIVE; a ingestão falha fechada para vínculo, política ou JSON ausentes/ inválidos e rejeita zona fora da política antes da projeção. A suíte operacional passou com 11 testes, a tabela remota foi consultada com sucesso e o endpoint recusa chamada anônima (401). O canário autenticado criou a política, vinculou a fonte e comprovou 1 política, 1 fonte, 3 eventos, 1 situação e 1 Attention, além de isolamento, cleanup e authorizesExecution:false.

Em 2026-09-05, o Worker d9012691-8daa-4060-a7b2-5a3c0c14e0c9 passou a projetar situação operacional CRITICAL para um Decision Record imutável tenant-scoped, deduplicado por operational:<situationId>. O hash do snapshot operacional é um fato auditável e a restrição dura human-review-required rejeita continue-operation, selecionando somente pause-and-review. O canário autenticado confirmou 1 decisão, 1 Attention, três eventos e a transição CRITICAL → UNKNOWN → NORMAL, com isolamento, cleanup e authorizesExecution:false; a projeção não pausa, autoriza ou executa intervenção.

Em 2026-09-05, o Worker 411cf1e2-4a1f-48b7-9d54-deeb71e4474e passou a converter apenas uma situação CRITICAL em plano de intervenção tenant-scoped AWAITING_AUTHORIZATION. O fluxo exige template ACTIVE com aprovação humana e persiste a intervenção e seu evento, sem iniciar capability ou mudar o estado operacional. O canário autenticado confirmou 1 intervenção juntamente com decisão, Attention, três eventos e a transição watchdog, mais isolamento, cleanup e authorizesExecution:false.

Em 2026-09-05, o Worker f8ab8837-14fa-4ff4-91be-6b8b461fe51b passou a correlacionar somente situação operacional CRITICAL em agent_exceptions e agent_incidents tenant-scoped. A projeção mantém requiresHumanReview:true, preserva o incidente OPEN para triagem e não inicia capability, não altera a situação e não autoriza execução. O canário autenticado confirmou uma exceção e um incidente, juntamente com decisão, Attention, intervenção AWAITING_AUTHORIZATION, isolamento entre tenants, negação anônima, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, a migration remota 0130_operational_responsibility_routes.sql e o Worker 9d6f8bc6-f202-46b9-9b88-cfe1f11e9333 passaram a resolver uma situação CRITICAL contra o registry PRD-041 somente quando há exatamente um assignment HUMAN ativo na ação, escopo e papel RACI solicitados. A projeção append-only fixa assignment, principal, instante e hashes do contexto e snapshot; lacuna, conflito ou principal não humano falham fechados. O canário autenticado criou o assignment humano sintético e comprovou uma rota de responsabilidade junto com Attention, decisão, intervenção, exceção e incidente, além da transição CRITICAL → UNKNOWN → NORMAL, isolamento, negação anônima, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, o Worker 7da78a78-d772-4834-b285-ddde9ebabec8 passou a abrir um Collaboration Workspace ACTIVE somente para o humano resolvido pela rota operacional de responsabilidade. A criação atômica fixa o contexto com o hash do snapshot da situação, a rota e o assignment, cria o participante OWNER e registra a atividade; não cria approval request, não altera Attention, não muda a situação e não autoriza execução. O canário autenticado comprovou um workspace para o revisor humano, juntamente com rota de responsabilidade, Attention, decisão, intervenção, exceção/incidente, transição watchdog, isolamento, negação anônima, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, a suíte operacional passou a cobrir explicitamente replay e ordenação temporal. O Worker 7da78a78-d772-4834-b285-ddde9ebabec8 retorna o fato já persistido para a mesma combinação eventId/eventVersion, sem nova projeção, e aceita um evento atrasado no inbox sem permitir que ele substitua a situação com observedAt mais recente. O canário remoto comprovou ambos antes das transições watchdog, preservando uma situação, quatro eventos (incluindo o atrasado e excluindo o replay), isolamento, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, o canário remoto também comprovou backpressure da fonte: com máximo de um evento por minuto, um segundo evento normal foi rejeitado com 429, enquanto um evento CRITICAL posterior usou o bypass de prioridade e foi persistido. A via de prioridade não autoriza intervenção; a evidência preserva dois eventos na fonte limitada, mais o fluxo Work Permit, isolamento, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, o Worker 627fe21b-a988-4b72-a2ca-cbe4af04dd90 passou a expor a timeline read-only de uma situação operacional. A rota lê no máximo 200 fatos do inbox tenant-scoped na ordem (observedAt,eventId,eventVersion), exige que a situação exista no tenant e retorna somente fatos imutáveis, sem replay, mutação ou authority. O canário autenticado leu os quatro fatos do Work Permit (inclusive o atrasado), além dos controles de backpressure, watchdog, integração humana, isolamento, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, a migration remota 0131_operational_resource_routes.sql e o Worker 712996ee-693a-41ce-ac04-fc65755c6e27 passaram a vincular situação CRITICAL a uma decisão de discovery PRD-039 somente quando ela seleciona um workforce_profile ainda AVAILABLE. A projeção append-only fixa decisão, recurso, policy, versão e hashes do contexto, mas não cria reservation, allocation, assignment ou capability invocation. O canário autenticado criou Resource/Profile/Policy/Authorization e uma decisão determinística de Workforce para um humano elegível, confirmou uma rota de recurso no D1, e preservou timeline, watchdog, integração humana, isolamento, cleanup PostgreSQL e authorizesExecution:false.

Auditoria de aceitação em 2026-09-05: a implementação publicada já mantém operational_situations versionadas e snapshotadas a partir do inbox tenant-scoped; fontes aceitam o tipo DEVICE_GATEWAY, com identidade SHA-256 e zonas permitidas. A ingestão falha fechada para fonte/identidade/zona inválidas, converte baixa qualidade, SENSOR_OFFLINE e heartbeat vencido em UNKNOWN, e correlaciona EQUIPMENT_FAILURE ou GAS_CRITICAL com peoplePresent como CRITICAL. O CEP determinístico conserva observedAt, zona e sujeito, rejeita replay, não deixa evento atrasado substituir estado mais novo e aplica geofence como correlação espacial. Esses fatos são cobertos pela suíte operacional e pelo canário publicado; eles não provam gateway de device externo ou as integrações amplas restantes.

O fluxo de Exception Management já projeta uma situação crítica como agent_exceptions e agent_incidents com severidade CRITICAL, incidente OPEN e revisão humana obrigatória, sem assumir causa, resolução ou execução; isso constitui o Potential Incident do slice atual. A suíte crítica publicada cobre fonte ausente/inativa, identidade ou zona negadas, geofence indisponível, baixa qualidade e sensor indisponível como UNKNOWN, heartbeat obrigatório/vencido, deduplicação, ordenação temporal, backpressure com bypass crítico, isolamento e anonimato. O canário remoto confirmou esses limites junto às projeções de atenção, decisão, workflow, exceção/incidente, responsabilidade, colaboração e recurso, sempre com authorizesExecution:false.

Em 2026-09-05, a migration remota 0134_operational_audit_ledger.sql e o Worker 371cebd4-993c-4899-ab2c-eb36e4ac35a8 passaram a persistir cada observação operacional aceita em operational_audit_facts, tenant-scoped, correlacionada ao evento, com hashes de estado/evidência e triggers que rejeitam UPDATE e DELETE. A rota read-only /operations/situations/:id/audit retorna somente esses fatos imutáveis. O canário autenticado de produção comprovou quatro fatos para o Work Permit sintético, incluindo a observação crítica, junto com isolamento, negação anônima, cleanup e authorizesExecution:false. Isto ainda não fecha o Audit Fabric completo: a cadeia integral de intervenção (policy, authorization, capability, execution e verification) continua distribuída entre seus registros próprios e deverá ser consolidada antes de marcar a aceitação de auditoria como concluída.

Em 2026-09-05, o Worker e8482079-31ef-4684-a942-920c3ffed7aa passou a enriquecer o replay OBSERVE read-only com as mudanças de risco correlacionadas e as intervenções cujo risk_ref aponta para a situação. O canário de produção comprovou a observação CRITICAL, o ASSESSMENT_RECORDED e a intervenção STOPPED do mesmo Work Permit, sem qualquer escrita pelo replay e com authorizesExecution:false. Isto avança a reconstrução de “o que/quando/risco/ação”, mas ainda não preserva uma sequência explícita de snapshots de transição de estado; portanto, Operational replay implementado permanece aberto.

Em 2026-09-05, a migration remota 0135_operational_state_history.sql e o Worker d677cc34-387f-42ca-91ef-6b5f43495768 passaram a registrar toda projeção efetiva em operational_situation_state_events, com versão, hash, evento de origem e triggers de imutabilidade. O OBSERVE agora devolve essa sequência; o canário de produção comprovou exatamente CRITICAL@1 → UNKNOWN@2 → NORMAL@3, excluindo o evento atrasado, e confirmou o gateway externo processado, quatro fatos auditáveis, isolamento, negação anônima e cleanup. A primeira publicação desta mudança tinha uma aridade SQL inválida que deixou o receipt da fila em QUEUED; ela foi diagnosticada no D1, protegida por teste e corrigida antes deste canário. Naquele ponto, a aceitação de replay ainda aguardava o modo read-only DRY_RUN.

Em 2026-09-05, o Worker 7a97348e-f0bf-42c4-8b24-acb08ad6019e adicionou DRY_RUN à rota de replay. Ele reconstrói os mesmos fatos, transições, risco e intervenções tenant-scoped, mas sempre responde dryRun:true, writesState:false e authorizesExecution:false. O canário de produção confirmou OBSERVE, a simulação hipotética e DRY_RUN, além da cadeia histórica sem mutação. Assim, o requisito de Operational Replay foi aceito; isso não amplia qualquer autorização operacional.

Em 2026-09-05, a migration remota 0136_intervention_event_immutability.sql e o Worker dca3bcf7-f6a6-4d93-a5c7-11ed775ebb7f passaram a consolidar na rota read-only /operations/situations/:id/audit os fatos de observação, as avaliações de risco e os eventos de intervenção relacionados, retornando somente hashes de evidência. Eventos de intervenção agora também rejeitam UPDATE e DELETE. O canário de produção confirmou a observação crítica, RISK_ASSESSMENT_RECORDED e INTERVENTION_AUTHORIZED no mesmo trail, com isolamento, gateway processado e cleanup; uma chamada D1 do primeiro canário recebeu 7403 transitório, mas a mesma consulta confirmou o receipt PROCESSED e a repetição integral passou. Naquele ponto, a aceitação de Audit completo aguardava a consolidação de policy, capability, execução e verification.

Em 2026-09-06, o canário operacional completo confirmou o trail consolidado: geofence, quatro eventos, CRITICAL → UNKNOWN → NORMAL, quatro fatos auditáveis, risco, Attention, Decision, intervenção/recovery, exceção/incidente, responsabilidade, workspace e recurso; todos os contadores D1 esperados foram 1 (ou 4 eventos/fatos e 3 transições), com isolamento e anonimato negado. A asserção de audit passou a exigir uma decisão de policy UUID emitida pelo servidor, em vez de confiar no valor submetido pelo cliente; o canário renova uma sessão sintética apenas após 401 e repete a requisição. O fluxo não concede autoridade implícita (authorizesExecution:false).

Em 2026-09-05, o Worker a59e4ed3-4a83-4d6a-a75e-26dfc2ee2bda passou a incluir no trail as referências de policy, approval e capability de cada evento de intervenção e a consolidar intervenções do mesmo Work Permit, incluindo INTERVENTION_VERIFIED. O canário de produção confirmou no mesmo audit trail a detecção, risco, INTERVENTION_AUTHORIZED com policy/approval, capability operations.pause, início de execução e verification, sempre com fatos imutáveis, hashes de evidência, isolamento e cleanup. Assim, Audit completo foi aceito; o trail permanece estritamente read-only e não concede execução.

Em 2026-09-05, o Worker a735f409-6173-4887-9c93-865a6b68b0f4 tornou a source authority do State Fabric idempotente quando sua configuração já está ativa, eliminando a recriação concorrente exposta pelo canário de caos. A suíte cobre storage D1 degradado com 503 fail-closed e sem autoridade, Queue externa indisponível com receipt FAILED, sensor offline, storm/debounce, duplicação e ordenação tardia. O canário de produção comprovou quatro sensores concorrentes com 50% offline (UNKNOWN), latência de rede, storm, eventos duplicados e fora de ordem, sem autoridade de intervenção, além de isolamento e cleanup. Assim, Chaos tests foram aceitos.

Em 2026-09-05, o Worker e8cf6b03-494f-493e-9b00-869aaa25c61c passou a impor privacidade de localização na fronteira de ingestão: latitude, longitude, accuracyMeters ou objeto location recebem 422 OPERATIONAL_PRECISE_LOCATION_FORBIDDEN antes de lookup de fonte ou escrita. Apenas zoneId tenant-governado e validado por geofence atravessa o fluxo para correlação espacial. O canário remoto comprovou a negação de coordenadas e preservou o fluxo de zona, isolamento, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, o Worker ba090c76-f40b-49dc-96df-3fe7c05f2103 passou a tornar imutável a identidade SHA-256 de uma fonte já registrada. Um re-registro da mesma sourceId com hash diferente recebe 409 OPERATIONAL_SOURCE_IDENTITY_IMMUTABLE antes do upsert; metadata de uma identidade igual ainda pode ser atualizada sob autenticação. O canário remoto confirmou a negação, preservou a ingestão com a identidade original, isolamento, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, uma situação operacional CRITICAL de WORK_PERMIT passou a recalcular risco no mesmo batch D1 da ingestão: registra risk_signal, risk_assessment e risk_assessment_event append-only, com IDs determinísticos do evento, método RULE_BASED, risco inerente/residual 100, evidência do evento e do snapshot da situação. Eventos não críticos ou sujeitos fora de Work Permit não produzem essa avaliação; a projeção não autoriza intervenção. O canário remoto publicado confirmou exatamente um Signal, um Assessment CRITICAL e um evento de Assessment, além de isolamento entre tenants, negação anônima, cleanup PostgreSQL e authorizesExecution:false.

Em 2026-09-05, GET /operations/situations/:id/control-monitoring integrou a situação de Work Permit ao último control_governed_evaluation e ao continuous_control_monitor do PRD-044. A leitura é tenant-safe, inclui resultado, health, reason codes, hash, effectiveness, drift e circuit state; quando a avaliação não existe, responde UNKNOWN com CONTROL_EVALUATION_UNAVAILABLE, nunca saudável. A rota não avalia, altera ou executa controles. A suíte cobre projeção FAILING e o canário remoto confirmou o caminho fail-closed publicado, isolamento, cleanup e authorizesExecution:false.

Em 2026-09-05, a projeção de evento passou a manter operational_permit_runtime_states para Work Permit: situação CRITICAL ou UNKNOWN produz AT_RISK; condição normal recupera ACTIVE. O estado é derivado no mesmo batch de ingestão, mantém ordenação por observedAt e fixa authorizes_blocking=0; ele não pausa, bloqueia, libera nem executa uma atividade. O canário remoto comprovou a transição crítica, recuperação ACTIVE, uma linha de runtime tenant-safe, isolamento, cleanup e ausência de autoridade automática.

Em 2026-09-05, GET /operations/workers/:id/context passou a oferecer contexto operacional minimizado de recurso humano: disponibilidade, skills e qualificações tenant-safe avaliadas em um instante explícito. Qualificação expirada ou ainda não válida resulta em AT_RISK; ausência de qualificação resulta em UNKNOWN; a rota não expõe localização, não designa trabalhador e não autoriza atividade. A suíte cobre expiração e o canário remoto confirmou um perfil humano READY com qualificação válida, isolamento, cleanup e authorizesExecution:false.

Em 2026-09-05, a ingestão adicionou proteção de storm por situação: após dez observações não críticas na janela móvel de 60 segundos, a próxima recebe 202 com debounced:true, sem escrita nem alteração da projeção. Backpressure e prioridade crítica por fonte continuam independentes; evento CRITICAL nunca é suprimido por esse debounce. A suíte cobre o limite e o canário remoto publicou dez eventos informativos e confirmou a décima primeira observação debounced, preservando isolamento, cleanup e ausência de authority.

Em 2026-09-05, GET /operations/twin/zones/:id passou a expor o Digital Twin operacional como projeção read-only das situações atuais da zona. Cada objeto preserva entidade, currentState, versão, instante observado, fonte OPERATIONAL_STATE_FABRIC, confiança e hash do snapshot; a rota é tenant-safe e declara authorizesExecution:false, sem substituir sistemas de origem ou criar autoridade. A suíte cobre a projeção de Work Permit e o canário remoto confirmou o objeto crítico da zona zone-canary publicado.

Em 2026-09-05, o canário remoto comprovou controle de intervenção emergencial no slice operacional: uma intervenção planejada foi autorizada com decisão de policy, aprovação humana e snapshot exato; o start exigiu reserva de capacidade ativa e vinculada ao mesmo recurso/operação. A capability intervention.emergency-stop, limitada por policy a ZONE, interrompeu a intervenção crítica com forte autenticação sintética e evidência; o estado final STOPPED exigiu revisão pós-ação e o trigger terminal liberou a reserva. O fluxo permaneceu tenant-safe e não acionou sistema físico externo.

Em 2026-09-05, o canário remoto também comprovou verificação obrigatória em uma intervenção operacional sintética independente: após planejamento, autorização, snapshot aprovado e reserva de capacidade, a intervenção ACTIVE só alcançou EFFECTIVE com risco posterior menor, evidência pós-condição, stateVerified:true e controlVerified:true. A resposta registrou redução de risco de 0.3, não autorizou nova execução e preservou o fluxo tenant-safe.

Em 2026-09-05, GET /operations/situations/:id/replay?mode=OBSERVE passou a reconstruir uma situação a partir de seus fatos imutáveis ordenados e da projeção atual, retornando estado, versão, instante e hash do snapshot. O modo é estritamente observacional: não reinsere evento, não altera estado e não autoriza execução. A suíte cobre o contrato e o canário remoto confirmou o Work Permit crítico e o fato de falha correspondente.

Em 2026-09-05, POST /operations/situations/:id/simulate passou a avaliar uma observação hipotética com schema limitado, usando a projeção atual apenas como contexto. A resposta informa o estado previsto e declara writesState:false e authorizesExecution:false; ela não persiste evento, não muda situação e não controla equipamento. A suíte e o canário remoto confirmaram a previsão CRITICAL para falha de equipamento com pessoas presentes.

Em 2026-09-05, o External Device Gateway foi integrado em POST /device-gateway/:tenantId/:sourceId. A borda pública exige credencial de dispositivo cujo SHA-256 é vinculado à fonte tenant-scoped, timestamp curto e nonce; aceita somente observações normalizadas e sem localização precisa, registra recibo durável anti-replay e publica agentic.operational-observation na Queue. O consumidor reinsere o evento apenas na projeção operacional já governada, marca o recibo PROCESSED somente após a persistência e jamais concede autoridade de execução. A migration 0133_operational_device_gateway.sql, as suítes de rota/Queue e o canário remoto exercitaram o fluxo público, a fila e o recibo processado em D1 com tenant sintético e cleanup.

Em 2026-09-05, cada projeção operacional passou a publicar uma entidade canônica OPERATIONAL_SITUATION no State & Context Synchronization Fabric do PRD-035. A fonte interna operational-state-fabric é declarada pelo próprio Fabric; a primeira observação cria o estado, e as seguintes sincronizam por versão, preservando histórico, conflitos, invalidação de contexto e assinaturas. O canário remoto confirmou no D1 uma situação operacional canônica tenant-scoped com essa fonte, além de isolamento e cleanup.

Em 2026-09-06, a versão corrente 32b62b38-c4bc-4d00-a657-7eda210c6b90 foi novamente exercitada pelo canário operacional ponta a ponta. Os 32 testes específicos de State Fabric/Operational Awareness passaram; no D1 primário, o gateway externo terminou PROCESSED, nove situações foram projetadas e sincronizadas como entidades canônicas, e a situação crítica completou as rotas de recurso e responsabilidade, workspace humano e duas intervenções sintéticas sem transferir autoridade ao State Fabric. Assim, a integração de sincronização PRD-035 permanece comprovada no runtime atual; o canário também confirmou isolamento, negação anônima e o encadeamento auditável do slice.

Em 2026-09-06, a regressão atual de Operational Awareness e sincronização operacional de State Fabric passou com 27 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.

148. Resultado Arquitetural

Com o PRD-048, a arquitetura passa a possuir uma percepção operacional contínua:

                    ┌───────────────┐
                    │ REAL WORLD    │
                    └───────┬───────┘
                            ↓
              ┌────────────────────────┐
              │ EVENTS / DEVICES / API │
              └───────────┬────────────┘
                          ↓
                ┌───────────────────┐
                │ OPERATIONAL STATE │
                └─────────┬─────────┘
                          ↓
                ┌───────────────────┐
                │ SITUATION ENGINE  │
                └─────────┬─────────┘
                          ↓
                   ┌────────────┐
                   │ RISK ENGINE│
                   └─────┬──────┘
                         ↓
                  ┌─────────────┐
                  │   DECISION  │
                  └──────┬──────┘
                         ↓
                     ┌───────┐
                     │POLICY │
                     └───┬───┘
                         ↓
                ┌─────────────────┐
                │ INTERVENTION    │
                └────────┬────────┘
                         ↓
                    VERIFICATION
                         ↓
                  UPDATED STATE

O Agentic Work deixa de ser apenas um assistente inteligente e passa a funcionar como uma camada de consciência operacional contínua, capaz de correlacionar pessoas, atividades, equipamentos, permissões, controles, riscos, eventos e condições operacionais.

A partir daqui, a próxima evolução natural é fechar o ciclo entre risco detectado → intervenção preventiva → execução coordenada → confirmação de resultado, transformando prevenção em uma operação executável e mensurável.

PRD-049 — Agentic Preventive Action & Safety Intervention Orchestration

O PRD-049 deverá formalizar a camada responsável por transformar uma situação de risco ou uma recomendação preventiva em uma intervenção operacional coordenada, incluindo:

RISK
 ↓
PREVENTIVE DECISION
 ↓
INTERVENTION PLAN
 ↓
RESOURCE ALLOCATION
 ↓
HUMAN/AGENT COLLABORATION
 ↓
CAPABILITY EXECUTION
 ↓
REAL-TIME MONITORING
 ↓
VERIFICATION
 ↓
RISK REDUCTION

Ele deverá abordar Safety Intervention, Preventive Action, Intervention Planning, Intervention Types, Intervention Priority, Intervention Authorization, Intervention Scope, Human Approval, Emergency Intervention, Automated Intervention, Intervention Preconditions, Intervention Postconditions, Safety Barriers, Control Activation, Temporary Controls, Compensating Controls, Work Permit Intervention, Resource Dispatch, Inspector Dispatch, Maintenance Intervention, Training Intervention, Operational Pause, Controlled Shutdown, Intervention Escalation, Intervention Timeout, Intervention Failure, Intervention Compensation, Intervention Verification, Intervention Effectiveness, Risk Reduction Measurement, Before/After Risk, Safety Barrier Verification, Intervention Evidence, Intervention Accountability, Intervention Timeline, Intervention Audit, Intervention Simulation, Intervention Replay, Intervention Learning, Intervention Templates e Intervention Governance.

O princípio central será:

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.

1. Objetivo​

2. Princípio Fundamental

3. Operational Awareness

4. Arquitetura

5. Operational State

6. State Ownership

7. Real-Time Sources

8. Event Fabric Integration

9. Sensor Integration

10. Device Gateway

11. Sensor Data ≠ Evidence

12. Observation

13. Data Quality

14. Device Health

15. Sensor Failure

16. Real-Time Context

17. Activity Awareness

18. Activity Lifecycle

19. Permit Correlation

20. Permit Runtime State

21. Worker Awareness

22. Worker Location

23. Qualification Awareness

24. Real-Time Qualification Violation

25. Resource Awareness

26. Equipment Awareness

27. Equipment Risk

28. Location Awareness

29. Safety Zones

30. Geofencing

31. Geofence Security

32. Situation Detection

33. Situation Model

34. Situation Rules

35. Complex Event Processing

36. Temporal Correlation

37. Spatial Correlation

38. Entity Correlation

39. Situation Confidence

40. Unknown Situation

41. Dynamic Risk

42. Risk Escalation

43. Risk Decay

44. Real-Time Control Monitoring

45. Safety Watchdog

46. Heartbeat

47. Heartbeat Failure

48. Dynamic Permit State

49. Permit Blocking

50. Policy Boundary

51. Emergency Intervention

52. Emergency Autonomy

53. Human Override

54. Override Audit

55. Operational Timeline

56. Timeline ≠ Audit

57. Real-Time Attention

58. Attention Routing

59. Incident Early Detection

60. Potential Incident ≠ Incident

61. Incident Confirmation

62. Operational Digital Twin

63. Digital Twin Principle

64. Twin State

65. Twin Synchronization

66. State Conflict

67. Real-Time Knowledge

68. No Automatic Fact Promotion

69. Agent Queries

70. Natural Language Situation Query

71. Real-Time Explanation

72. Streaming

73. UI Semantic Integration

74. Live Operations Dashboard

75. Live Map

76. Map Interaction

77. No Arbitrary Map Coordinates

78. Operational Context Snapshot

79. Snapshot Pinning

80. Stale Context

1. Objetivo

Work Permit em tempo real

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