PRD-037 — Agentic Temporal Intelligence & Scheduling Fabric

1. Objetivo

O PRD-037 cria a camada responsável por fazer o Agentic Work compreender e operar corretamente sobre tempo, prazos, janelas temporais, calendários, SLAs, recorrências e agendamentos.

A partir dos PRDs anteriores, já temos:

Goal
 ↓
Task
 ↓
Plan
 ↓
Policy
 ↓
Capability
 ↓
Execution
 ↓
Verification

Agora introduzimos a dimensão temporal:

Goal
 ↓
Temporal Constraints
 ↓
Schedule
 ↓
Task
 ↓
Execution Window
 ↓
Deadline
 ↓
Verification

O objetivo não é apenas saber que algo precisa ser feito.

É saber:

quando deve ser feito, quando pode ser feito, quando não pode ser feito e o que acontece se o prazo for perdido.

2. Problema

Considere:

“Renove o treinamento antes de ele vencer.”

Isso envolve várias perguntas:

Quando o treinamento vence?
Qual timezone?
O prazo é o instante exato ou o final daquele dia?
Pode renovar 30 dias antes?
Existe uma janela mínima?
Finais de semana contam?
Feriados contam?
Existe SLA?
O responsável está disponível?
O LMS está disponível?
O que acontece se o prazo cair durante uma indisponibilidade?
Quem deve ser escalado?
Qual horário deve ser usado para uma empresa com operações em vários países?

Uma simples comparação:

expiration < now

é insuficiente para uma plataforma empresarial.

3. Princípio Fundamental

O sistema deverá separar:

Instant
Local Time
Timezone
Calendar Date
Business Time
Duration
Deadline
Window
Schedule
Recurrence

4. Instant vs Local Time

Um Instant representa um ponto absoluto no tempo.

Exemplo:

2026-09-01T15:00:00Z

Já:

2026-09-01 12:00

é incompleto sem timezone.

O sistema não deverá assumir timezone implicitamente.

5. Timezone

Todo horário relevante deverá possuir timezone explícito quando representar horário local.

Exemplo:

interface ZonedDateTime {
  instant: string;

  timeZone: string;

  localDate: string;

  localTime: string;
}

Exemplo:

{
  "instant": "2026-09-01T15:00:00Z",
  "timeZone": "America/Sao_Paulo",
  "localDate": "2026-09-01",
  "localTime": "12:00:00"
}

6. Regra: Persistência

Instantes deverão ser persistidos em formato inequívoco.

Preferencialmente:

UTC instant
+
timezone original quando semanticamente relevante

Não utilizar:

"01/09/2026 12:00"

como representação persistente de um instante.

7. Timezone ≠ Locale

O sistema deverá separar:

timezone
locale
language
calendar

Exemplo:

locale = pt-BR
timezone = America/Sao_Paulo
language = pt-BR

8. Tenant Timezone

Cada tenant poderá possuir:

defaultTimeZone

mas isso não deverá substituir o timezone explicitamente associado ao usuário, recurso, local ou operação quando este for semanticamente necessário.

9. User Timezone

Um usuário poderá possuir:

preferredTimeZone

Exemplo:

America/Sao_Paulo

Isso deverá afetar a apresentação de horários, mas não alterar silenciosamente o instante armazenado.

10. Resource Timezone

Recursos físicos também poderão possuir timezone.

Exemplo:

Plant A → America/Sao_Paulo
Plant B → America/New_York

Uma operação relacionada ao Plant B deverá respeitar o timezone operacional daquele local quando a regra assim determinar.

11. Temporal Context

O Agent Context deverá incluir:

interface TemporalContext {
  now: string;

  userTimeZone: string;

  tenantTimeZone: string;

  locale: string;

  businessCalendarId?: string;

  currentBusinessDate?: string;

  currentBusinessTime?: string;
}

12. "Hoje"

A palavra:

“hoje”

não deverá ser interpretada pelo servidor apenas usando UTC.

Deverá utilizar o timezone semântico aplicável.

13. "Amanhã"

Da mesma forma:

“amanhã às 9h”

deverá ser transformado em:

localDate = tomorrow
localTime = 09:00
timeZone = resolved timezone

e somente então convertido para um Instant.

14. Ambiguous Timezone

Se o usuário disser:

“Agende para amanhã às 9h.”

e houver múltiplos timezones relevantes:

User = São Paulo
Resource = New York
Tenant = São Paulo

o sistema deverá determinar o timezone pela regra de prioridade configurada ou pedir esclarecimento.

Nunca escolher silenciosamente um timezone arbitrário em operações críticas.

15. Temporal Reference Resolution

O Intent Engine deverá reconhecer expressões:

hoje
amanhã
ontem
segunda-feira
próxima semana
em 3 dias
daqui a duas horas
até sexta
antes de vencer
30 dias antes
no próximo mês

16. Relative Time

Exemplo:

“Faça isso daqui a 2 horas.”

deverá resultar em:

{
  "type": "DELAY",
  "duration": "PT2H"
}

17. Absolute Time

Exemplo:

“Faça às 14h do dia 10.”

deverá resultar em uma representação temporal absoluta após resolução de:

data;
timezone;
calendário;
contexto.

18. Duration

Duração deverá ser diferente de horário.

2 horas

é:

Duration

enquanto:

14:00

é:

Local Time

19. Calendar Date

2026-09-10

pode representar apenas uma data, sem horário.

Isso é importante para:

aniversários;
vencimentos diários;
feriados;
validade por dia;
datas de competência.

20. Business Calendar

Cada tenant ou unidade poderá possuir um calendário empresarial.

interface BusinessCalendar {
  calendarId: string;

  tenantId: string;

  timeZone: string;

  workingDays: number[];

  workingHours: WorkingHourRule[];

  holidays: Holiday[];

  exceptions: CalendarException[];

  version: string;
}

21. Working Days

Exemplo:

Monday
Tuesday
Wednesday
Thursday
Friday

22. Working Hours

Exemplo:

08:00–12:00
13:00–17:00

23. Holidays

O calendário deverá permitir:

National Holiday
Regional Holiday
Municipal Holiday
Company Holiday
Plant Shutdown

24. Calendar Exceptions

Uma sexta-feira normalmente útil pode ser declarada:

NON_WORKING

e um sábado excepcionalmente trabalhado:

WORKING

25. Calendar Versioning

Alterações no calendário deverão gerar:

calendarVersion

Isso permite reproduzir decisões históricas.

26. SLA

O sistema deverá representar SLAs formalmente.

interface SLA {
  slaId: string;

  name: string;

  duration: string;

  calendarId: string;

  startCondition: string;

  pauseConditions?: string[];

  breachCondition: string;

  escalationPolicyId?: string;

  version: string;
}

27. SLA Clock

O SLA deverá possuir:

STARTED
PAUSED
RUNNING
BREACHED
COMPLETED
CANCELLED

28. SLA Pause

Alguns processos poderão pausar o relógio.

Exemplo:

Waiting for customer information

O sistema deverá registrar:

SLA_PAUSED
reason = WAITING_CUSTOMER

29. SLA Resume

Quando a condição terminar:

SLA_RESUMED

e o tempo restante será recalculado.

30. Deadline

Deadline representa o instante limite para concluir uma operação.

interface Deadline {
  deadlineId: string;

  dueAt: string;

  timeZone?: string;

  calendarId?: string;

  gracePeriod?: string;

  escalationPolicyId?: string;
}

31. Due Date vs Deadline

Uma data:

2026-09-10

não necessariamente significa:

2026-09-10T00:00:00Z

A semântica deverá ser definida pelo domínio.

32. Temporal Window

Uma janela temporal:

interface TemporalWindow {
  earliestStart?: string;

  latestStart?: string;

  earliestFinish?: string;

  deadline?: string;
}

33. Example

Uma inspeção poderá ocorrer:

não antes de 08:00
não depois de 16:00

Isso representa uma janela:

08:00 ≤ start ≤ 16:00

34. Grace Period

Alguns deadlines poderão possuir tolerância:

deadline = 17:00
gracePeriod = 30m

Mas:

Grace period não significa que a operação continua formalmente dentro do SLA.

O sistema deverá distinguir:

ON_TIME
GRACE_PERIOD
BREACHED

35. Temporal Constraint

O Planner do PRD-032 poderá receber restrições:

interface TemporalConstraint {
  type:
    | "BEFORE"
    | "AFTER"
    | "BETWEEN"
    | "WITHIN"
    | "DURING"
    | "DEADLINE"
    | "DURATION"
    | "RECURRENCE";

  target: string;

  value: string;
}

36. Temporal Dependency

Exemplo:

Training validation
        ↓
must finish before
        ↓
Work Permit release

37. Critical Path

Se:

A → B → C

A = 2h
B = 4h
C = 1h

o caminho crítico é:

7h

O Scheduler deverá utilizar essa informação para avaliar risco de deadline.

38. Schedule

interface Schedule {
  scheduleId: string;

  tenantId: string;

  triggerType:
    | "ONCE"
    | "RECURRING"
    | "EVENT"
    | "CONDITION";

  timeZone: string;

  startAt?: string;

  endAt?: string;

  recurrence?: RecurrenceRule;

  status: ScheduleStatus;
}

39. One-Time Schedule

Exemplo:

Execute amanhã às 09:00.

40. Recurring Schedule

Exemplo:

Verifique diariamente às 02:00.

41. Recurrence

A recorrência deverá possuir semântica explícita.

Exemplo:

FREQ=DAILY
BYHOUR=2
BYMINUTE=0

42. Monthly Recurrence

Exemplo:

Todo primeiro dia útil do mês.

Isso não deverá ser reduzido a:

day = 1

porque o primeiro dia pode ser feriado.

43. Business Recurrence

O Scheduler deverá permitir regras como:

firstBusinessDay
lastBusinessDay
everyBusinessDay
everyNthBusinessDay

44. DST

O sistema deverá suportar mudanças de horário de verão em timezones que as utilizem.

Não deverá assumir:

timezone = fixed UTC offset

45. Brazil Timezones

O sistema deverá utilizar identificadores IANA, por exemplo:

America/Sao_Paulo
America/Fortaleza
America/Recife
America/Manaus

e não simplesmente:

GMT-3

como identidade temporal.

46. Temporal Semantics

Um comando:

“Faça às 9 da manhã no local do funcionário.”

deverá resolver:

Employee
 ↓
Location
 ↓
Timezone
 ↓
Local Date
 ↓
Local Time
 ↓
Instant

47. Scheduling Pipeline

Natural Language
       ↓
Temporal Parser
       ↓
Temporal Context
       ↓
Timezone Resolution
       ↓
Calendar Resolution
       ↓
Constraint Evaluation
       ↓
Schedule
       ↓
Trigger
       ↓
Task / Workflow

48. Deterministic First

Expressões temporais comuns deverão ser resolvidas deterministicamente.

Exemplos:

tomorrow
in 2 hours
next Monday
before expiration
30 days before

49. LLM Temporal Parsing

O LLM poderá ajudar em expressões ambíguas:

“Faça no começo da próxima semana.”

Mas deverá produzir:

{
  "temporalExpression": "...",
  "interpretation": "...",
  "confidence": 0.91
}

e não executar diretamente.

50. Temporal Clarification

Se:

“Na próxima segunda.”

for ambíguo entre dois calendários ou timezones relevantes, perguntar:

Você quer segunda-feira às 9h no horário de São Paulo ou no horário do local da operação?

51. Missed Schedule

Se um Worker estiver indisponível no horário:

scheduled = 02:00
system recovered = 03:15

o Scheduler deverá ter política explícita:

SKIP
RUN_IMMEDIATELY
RUN_NEXT_OCCURRENCE
REQUIRES_REVIEW

52. No Blind Catch-Up

Uma tarefa vencida não deverá automaticamente ser executada se isso puder produzir uma operação perigosa.

53. Persistent Timers

Timers deverão sobreviver à reinicialização de Workers.

Não depender de:

setTimeout(...)

como mecanismo de persistência empresarial.

54. Timer Abstraction

interface TemporalScheduler {
  schedule(
    request: ScheduleRequest
  ): Promise<ScheduleHandle>;

  cancel(
    scheduleId: string
  ): Promise<void>;

  pause(
    scheduleId: string
  ): Promise<void>;

  resume(
    scheduleId: string
  ): Promise<void>;
}

55. Cloudflare Compatibility

A implementação deverá abstrair o mecanismo de persistência/agendamento.

Poderá utilizar, conforme o caso:

Workers
Durable Objects
Workflows
Queues
D1
KV

sem acoplar a lógica de negócio diretamente a um mecanismo específico.

56. Temporal Event

Eventos:

ScheduleCreated
ScheduleTriggered
ScheduleSkipped
ScheduleDelayed
DeadlineApproaching
DeadlineReached
SLABreached
TemporalConstraintViolated
ScheduleCancelled

57. Deadline Monitoring

O sistema deverá detectar:

deadline > 24h
deadline < 24h
deadline < 1h
deadline breached

com thresholds configuráveis.

58. Proactive Escalation

Exemplo:

Training expires in 3 days

poderá produzir:

DeadlineApproaching
 ↓
Proactive Intelligence
 ↓
Goal
 ↓
Task

59. Temporal Risk

O Decision Engine poderá utilizar:

timeRemaining
estimatedDuration
resourceAvailability
dependencyStatus

para produzir:

deadlineRisk

60. Deadline Prediction

Exemplo:

Remaining:
8h

Estimated execution:
11h

Risk:
HIGH

O sistema poderá criar uma recomendação:

O prazo provavelmente não será cumprido com os recursos atuais.

61. Schedule Optimization

O Planner poderá comparar:

Plan A
start now
cost = 100
risk = low

Plan B
start in 2h
cost = 60
risk = medium

e selecionar o melhor plano dentro das restrições.

62. Resource Calendar

Recursos poderão possuir disponibilidade:

Employee
Machine
Team
External API
Agent

Exemplo:

LMS API
maintenance:
02:00–03:00

63. Agent Availability

Agentes poderão possuir:

availability
capacity
maintenance window

Embora o Agent possa ser virtual, sua capacidade computacional também deverá ser tratada pelo PRD-033.

64. Temporal Resource Conflict

Exemplo:

Task A:
09:00–11:00

Task B:
10:00–12:00

Resource:
Inspector #10

Conflito:

RESOURCE_TIME_CONFLICT

65. Temporal Dependency Graph

O Scheduler poderá representar:

A ──2h──> B ──4h──> C
│
└──────────────> D

permitindo calcular:

earliest start;
latest start;
slack;
critical path.

66. Slack

Se uma Task puder atrasar 3 horas sem afetar o deadline:

slack = 3h

Tasks com:

slack = 0

são críticas.

67. Temporal Replanning

Se:

Task A

atrasar 4 horas:

State Change
 ↓
Temporal Engine
 ↓
Recalculate Critical Path
 ↓
Planner
 ↓
Replan

68. Integration with Adaptive Runtime

O PRD-034 poderá receber:

deadline pressure

e adaptar:

concorrência;
batching;
resource selection;
retry;
prioridade.

Sem violar Policy.

69. Temporal Policy

Policies poderão especificar:

operation must occur during business hours
operation cannot occur during maintenance
approval must happen before deadline

70. Policy Example

id: workPermit.release.temporal
rules:
  - when: operation == "RELEASE"
    require:
      businessHours: true
      trainingStatus: "VALID"

71. Temporal Security

Horários também podem ter implicações de segurança.

Exemplo:

Não permitir determinada operação fora do horário autorizado.

Isso deverá ser Policy.

72. Human Approval Window

Uma aprovação poderá possuir:

validFrom
expiresAt

Se a aprovação expirar:

APPROVAL_EXPIRED

e uma nova aprovação poderá ser necessária.

73. Confirmation Expiration

Isso também se aplica às confirmações do PRD-010.

confirmation
 ↓
TTL
 ↓
expired

A confirmação antiga não poderá ser reutilizada.

74. Delegation Expiration

Integração com PRD-027:

delegation.expiresAt

Quando expirar:

Agent authority = invalid

mesmo que uma Task ainda esteja pendente.

75. Credential Expiration

Credenciais externas também possuem temporalidade:

OAuth token
API credential
certificate

O Gateway deverá impedir utilização após expiração.

76. Goal Temporal State

Goals poderão possuir:

startAt
deadline
expiresAt
evaluationFrequency

77. Goal Deadline

Exemplo:

Goal:
100% compliance

deadline:
September 30, 23:59

O Goal Manager deverá acompanhar continuamente o risco temporal.

78. Goal Deadline Risk

progress = 70%
remaining = 2 days
estimated = 4 days

Resultado:

AT_RISK

79. Temporal Context in Conversation

Usuário:

“Faça isso amanhã.”

O Conversation Runtime deverá preservar:

resolvedDate
resolvedTimezone
temporalIntent

80. Follow-Up

Usuário:

“E se não der certo?”

O sistema deverá manter o contexto temporal da operação anterior quando aplicável.

81. Natural Language Examples

O sistema deverá suportar:

“Avise o responsável 7 dias antes.”

“Se não houver aprovação até amanhã, escale.”

“Execute no próximo dia útil.”

“Não faça isso durante a manutenção.”

“Renove todos os treinamentos que vencem nos próximos 15 dias.”

“Faça isso toda segunda-feira às 8h.”

82. Temporal Query

O agente deverá responder:

“Quais Work Permits vencem nos próximos 7 dias?”

utilizando:

now
+
timezone
+
validUntil

corretamente.

83. Temporal Range Query

A busca deverá gerar:

from
to
timezone
calendar semantics

e não apenas strings textuais.

84. Historical Query

Pergunta:

“Quais treinamentos estavam vencidos no dia 15?”

deverá usar:

historical state
+
temporal validity
+
knowledge version

conforme PRD-035.

85. Temporal Provenance

Cada decisão temporal relevante deverá registrar:

timezone
calendar
calendarVersion
evaluationTime
sourceStateVersion

86. Audit

Registrar:

TEMPORAL_CONTEXT_RESOLVED
SCHEDULE_CREATED
SCHEDULE_TRIGGERED
DEADLINE_CALCULATED
DEADLINE_CHANGED
SLA_STARTED
SLA_PAUSED
SLA_RESUMED
SLA_BREACHED
TEMPORAL_CONSTRAINT_FAILED
TIMEZONE_RESOLVED
CALENDAR_CHANGED

87. Observability

Métricas:

scheduled_tasks
trigger_latency
missed_schedules
deadline_breaches
sla_breaches
schedule_failures
temporal_conflicts
timezone_resolution_errors
calendar_resolution_errors
late_execution_rate

88. Scheduler Latency

Medir:

scheduledAt
triggeredAt
startedAt
completedAt

para detectar atraso do próprio sistema.

89. Scheduler Reliability

O objetivo é garantir:

At-least-once trigger
+
idempotent execution

Não depender de exatamente uma entrega.

90. Duplicate Trigger Protection

Cada trigger deverá possuir:

interface TemporalTrigger {
  triggerId: string;

  scheduleId: string;

  occurrenceId: string;

  scheduledAt: string;

  triggeredAt?: string;
}

occurrenceId funcionará como chave de idempotência.

91. Temporal Failure Recovery

Se o scheduler falhar:

Scheduler outage
 ↓
Recovery
 ↓
inspect missed occurrences
 ↓
apply missed-trigger policy
 ↓
resume

92. Clock Integrity

O sistema deverá usar uma fonte temporal consistente para:

deadlines;
TTLs;
expiration;
authorization;
scheduling.

Não confiar no relógio fornecido pelo cliente.

93. Client Time Is Untrusted

O browser poderá informar:

local timezone

mas o servidor deverá validar/normalizar o contexto.

O cliente não poderá alterar:

server now
deadline
authorization expiration

94. Temporal Simulation

Antes de executar:

“O que aconteceria se o prazo fosse amanhã?”

O sistema poderá simular:

current state
+
temporal constraints
+
resources
+
tasks

sem mutations reais.

95. What-If

Exemplo:

Deadline:
Friday

Scenario:
LMS unavailable for 6h

Result:
deadline risk → HIGH

96. Testing

Testes obrigatórios:

Timezone

São Paulo;
New York;
London;
UTC;
timezone do recurso diferente do usuário.

Calendar

feriado;
fim de semana;
exceção de calendário;
mudança de expediente.

Deadline

exatamente no limite;
antes;
depois;
grace period.

Recurrence

daily;
weekly;
monthly;
business day.

DST

transição de horário;
horário inexistente;
horário duplicado.

97. Failure Injection

Simular:

scheduler unavailable
storage unavailable
event delayed
worker restarted
duplicate trigger
late trigger
clock drift
calendar update
timezone change

98. Tenant Isolation

Cada tenant deverá possuir:

calendars
schedules
SLAs
timezone policies
holidays
temporal rules

isolados.

99. Shared Global Calendars

Calendários globais poderão existir:

Global Holiday Calendar

mas o tenant poderá complementá-los:

Global
 +
Tenant
 +
Unit

100. Calendar Precedence

Exemplo:

GLOBAL
   ↓
TENANT
   ↓
BUSINESS_UNIT
   ↓
LOCATION
   ↓
RESOURCE

A regra de precedência deverá ser explícita.

101. Temporal Configuration

Configurações deverão ser versionadas:

TemporalConfig v1
TemporalConfig v2

102. No Retroactive Mutation

Uma alteração de calendário não deverá modificar silenciosamente decisões históricas.

Exemplo:

Decision made with Calendar v4

deverá continuar reproduzível mesmo após:

Calendar v5

103. Integration Matrix

Componente	Integração
PRD-005 Intent	interpretação temporal
PRD-010 Conversation	contexto temporal
PRD-019 Workflow	timers/deadlines
PRD-020 Event Fabric	temporal events
PRD-021 Proactive	upcoming deadlines
PRD-023 Decision	temporal risk
PRD-024 Exception	missed deadlines
PRD-027 Identity	delegation expiration
PRD-028 Knowledge	temporal facts
PRD-029 Governance	temporal provenance
PRD-031 Communication	message expiration
PRD-032 Planning	temporal constraints
PRD-033 Resources	resource availability
PRD-034 Runtime	deadline adaptation
PRD-035 State	historical/current state
PRD-036 Goals	goal deadlines

104. First Vertical Slice

O primeiro caso será:

Work Permit + Training Expiration + Goal + Proactive Monitoring

105. Cenário

Training:

expiresAt =
2026-09-15T23:59:59
America/Sao_Paulo

Goal:

Maintain Work Permit Compliance

Regra:

start remediation
30 days before expiration

106. Temporal Trigger

TrainingExpiration
       ↓
30 days before
       ↓
Temporal Scheduler
       ↓
Goal Evaluation

107. Task

Criar:

Renew Training

com:

deadline = expiration
priority = calculated

108. Escalation

Se:

deadline - now < 3 days

task != completed

então:

Goal
 ↓
AT_RISK
 ↓
Attention Center
 ↓
Escalation

109. Deadline Breach

Se ultrapassar:

expiration

sem renovação:

SLA_BREACHED

ou:

TRAINING_EXPIRED

conforme a semântica de domínio.

110. State Synchronization

O PRD-035 atualizará:

Training State
Work Permit State
Goal State
Task State

e invalidará contextos afetados.

111. Verification

Após renovação:

LMS
 ↓
TrainingStatusUpdated
 ↓
State Fabric
 ↓
Goal Evaluation

O Goal só poderá avançar após confirmação do estado real.

112. Acceptance Criteria

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

O scheduler temporal persiste schedules, ocorrências e dispatches idempotentes por tenant, com políticas de misfire, recorrência, calendário de negócio versionado e DST preservando horário local. As APIs suportam timezone IANA, resolução de referência relativa, SLA pause/resume, predição de deadline, critical path, simulação e monitores de Work Permit. O cron reprocessa somente dispatches pendentes e mantém causação auditável.

Em 2026-09-05, o gate temporal passou com 77 testes em 6 arquivos. O canário remoto executou, em tenant sintético isolado, calendário versionado, SLA/clock com término, meta atingida, monitor com três schedules, timer durável concluído, referência temporal resolvida, proteção contra ambiguidade, caminho crítico de 25200 segundos, simulação BREACHED, fila durável vazia, isolamento e cleanup PostgreSQL (remainingRows:0), sempre sem autoridade de execução. A prova de fontes externas reais e recuperação multi-região continua fora do escopo desse canário sintético.

Em 2026-09-06, a regressão atual de rotas temporais, tempo útil/calendário e runtime de schedules passou com 43 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A classificação PROVEN_CLOUDFLARE permanece sustentada pelo canário remoto registrado; fontes externas reais e recuperação multi-região continuam fora daquele recorte.

113. Resultado Arquitetural

O Agentic Work passa a possuir uma verdadeira dimensão temporal:

                         GOAL
                           │
                           ▼
                  TEMPORAL INTELLIGENCE
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
          CALENDAR       SLA         DEADLINE
              │            │            │
              └────────────┼────────────┘
                           ▼
                       SCHEDULE
                           │
                           ▼
                        TASK
                           │
                           ▼
                         PLAN
                           │
                           ▼
                        POLICY
                           │
                           ▼
                     EXECUTION
                           │
                           ▼
                       VERIFY
                           │
                           ▼
                     STATE FABRIC
                           │
                           ▼
                    GOAL RE-EVALUATION

O sistema passa a compreender que:

“o que fazer” e “quando fazer” são dimensões diferentes da mesma operação.

E, principalmente, o tempo deixa de ser uma propriedade incidental de uma função JavaScript e passa a ser um recurso semântico de primeira classe da arquitetura.

PRD-038 — Agentic Attention, Notification & Escalation Orchestration

Com os PRDs anteriores, o sistema já consegue:

detectar
→ compreender
→ decidir
→ planejar
→ executar
→ monitorar
→ manter objetivos

Mas surge outro problema:

Como fazer a informação certa chegar à pessoa certa, pelo canal certo, no momento certo?

Não basta detectar:

Training expires in 3 days

É necessário determinar:

quem precisa saber?
quando?
com qual prioridade?
por qual canal?
precisa de ação?
precisa de aprovação?
já foi notificado?
há escalonamento?
a pessoa recebeu?
a pessoa respondeu?

O PRD-038 deverá portanto criar uma camada formal de:

SIGNAL
  ↓
ATTENTION ITEM
  ↓
PRIORITY
  ↓
AUDIENCE
  ↓
CHANNEL
  ↓
NOTIFICATION
  ↓
ACKNOWLEDGEMENT
  ↓
ESCALATION
  ↓
RESOLUTION

Ela deverá integrar diretamente:

PRD-021 Proactive Intelligence;
PRD-022 Attention Center;
PRD-024 Exception Management;
PRD-036 Goals;
PRD-037 Temporal Intelligence;
Workflow;
Event Fabric;
Policy;
Identity/Delegation;
UI;
canais externos.

O objetivo será evitar que o Agentic Work se transforme em um sistema que detecta tudo, mas sobrecarrega os humanos com alertas.

A camada deverá ser capaz de distinguir:

INFORMATION
NOTICE
REMINDER
WARNING
ACTION_REQUIRED
APPROVAL_REQUIRED
ESCALATION
CRITICAL_INCIDENT

e determinar a atenção humana mínima necessária para manter o sistema seguro e operacional.

1. Objetivo​

2. Problema

3. Princípio Fundamental

4. Instant vs Local Time

5. Timezone

6. Regra: Persistência

7. Timezone ≠ Locale

8. Tenant Timezone

9. User Timezone

10. Resource Timezone

11. Temporal Context

12. "Hoje"

13. "Amanhã"

14. Ambiguous Timezone

15. Temporal Reference Resolution

16. Relative Time

17. Absolute Time

18. Duration

19. Calendar Date

20. Business Calendar

21. Working Days

22. Working Hours

23. Holidays

24. Calendar Exceptions

25. Calendar Versioning

26. SLA

27. SLA Clock

28. SLA Pause

29. SLA Resume

30. Deadline

31. Due Date vs Deadline

32. Temporal Window

33. Example

34. Grace Period

35. Temporal Constraint

36. Temporal Dependency

37. Critical Path

38. Schedule

39. One-Time Schedule

40. Recurring Schedule

41. Recurrence

42. Monthly Recurrence

43. Business Recurrence

44. DST

45. Brazil Timezones

46. Temporal Semantics

47. Scheduling Pipeline

48. Deterministic First

49. LLM Temporal Parsing

50. Temporal Clarification

51. Missed Schedule

52. No Blind Catch-Up

53. Persistent Timers

54. Timer Abstraction

55. Cloudflare Compatibility

56. Temporal Event

57. Deadline Monitoring

58. Proactive Escalation

59. Temporal Risk

60. Deadline Prediction

61. Schedule Optimization

62. Resource Calendar

63. Agent Availability

64. Temporal Resource Conflict

65. Temporal Dependency Graph

66. Slack

67. Temporal Replanning

68. Integration with Adaptive Runtime

69. Temporal Policy

70. Policy Example

71. Temporal Security

72. Human Approval Window

73. Confirmation Expiration

74. Delegation Expiration

75. Credential Expiration

76. Goal Temporal State

77. Goal Deadline

78. Goal Deadline Risk

79. Temporal Context in Conversation

80. Follow-Up

1. Objetivo

Timezone

Calendar

Deadline

Recurrence

DST

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