PRD-040 — Agentic Collaboration, Handoff & Approval Workspace

1. Objetivo

O PRD-040 cria a camada de colaboração operacional entre humanos, agentes e sistemas, permitindo que uma tarefa seja transferida, revisada, discutida, aprovada, rejeitada ou retomada sem perda de contexto, evidência ou responsabilidade.

A arquitetura passa de:

TASK
 ↓
RESOURCE
 ↓
ASSIGNMENT
 ↓
EXECUTION

para:

TASK
 ↓
ASSIGNMENT
 ↓
COLLABORATION
 ├── HUMAN
 ├── AGENT
 └── SYSTEM
 ↓
HANDOFF / REVIEW / APPROVAL
 ↓
EXECUTION
 ↓
VERIFICATION

O princípio fundamental é:

O contexto operacional deve acompanhar o trabalho, mas a autoridade deve continuar vinculada ao principal autorizado.

2. Problema

Uma operação real frequentemente não pode ser executada por um único ator.

Exemplo:

Agent Training
      ↓
detecta problema
      ↓
Risk Agent
      ↓
analisa impacto
      ↓
Human Safety Analyst
      ↓
revisa evidências
      ↓
Manager
      ↓
aprova
      ↓
Execution Agent
      ↓
executa

Sem uma camada de colaboração, cada transferência pode perder:

contexto;
evidências;
histórico;
responsabilidade;
decisão anterior;
justificativa;
estado;
autorização.

O PRD-040 resolve essa lacuna.

3. Princípios

3.1 Contexto acompanha a tarefa

O próximo participante deve receber referências estruturadas para:

intent
task
goal
entity
state
evidence
decision
policy
previous actions
pending actions

3.2 Autoridade não acompanha automaticamente o contexto

Receber contexto não significa receber autorização.

Context
  ≠
Authority

3.3 Handoff não é delegação

Handoff:

transferência operacional de responsabilidade por uma tarefa.

Delegação:

transferência formal de autoridade.

PRD-027 continua sendo responsável pela delegação.

3.4 Aprovação não é execução

APPROVED

não significa:

EXECUTED

A execução ainda deverá passar pelo Capability Registry + Policy Engine.

4. Collaboration Workspace

O Workspace será a representação persistente do trabalho colaborativo.

interface CollaborationWorkspace {
  workspaceId: string;

  tenantId: string;

  taskId?: string;

  workflowId?: string;

  goalId?: string;

  participants: Participant[];

  currentOwner?: PrincipalRef;

  status: CollaborationStatus;

  contextVersion: number;

  evidenceRefs: EvidenceRef[];

  decisions: DecisionRef[];

  approvals: ApprovalRef[];

  handoffs: HandoffRef[];

  activities: ActivityRef[];

  createdAt: string;

  updatedAt: string;
}

5. Collaboration Status

OPEN
ACTIVE
WAITING_HUMAN
WAITING_AGENT
WAITING_APPROVAL
BLOCKED
HANDOFF_PENDING
COMPLETED
CLOSED
CANCELLED

6. Participant

interface Participant {
  participantId: string;

  principalId: string;

  principalType: "HUMAN" | "AGENT" | "SYSTEM";

  role: CollaborationRole;

  joinedAt: string;

  leftAt?: string;

  status: "ACTIVE" | "INACTIVE";
}

7. Collaboration Roles

OWNER
ASSIGNEE
REVIEWER
APPROVER
OBSERVER
ADVISOR
EXECUTOR
COORDINATOR

8. Owner

Toda tarefa colaborativa deverá possuir um responsável operacional claramente definido.

Task
 ↓
Owner

O Owner poderá ser:

HUMAN
TEAM
AGENT

9. Co-Ownership

Algumas operações poderão permitir múltiplos responsáveis.

Exemplo:

Safety + Operations

Entretanto, co-ownership deverá ser explicitamente permitido.

Não deverá criar ambiguidade sobre:

quem precisa agir agora.

10. Current Actor

O sistema deverá distinguir:

Owner
Assigned Resource
Current Actor
Approver
Delegator

Exemplo:

Owner = Safety Team
Assigned = Maria
Current Actor = training-agent
Approver = João

11. Handoff

Handoff transfere a responsabilidade operacional.

interface Handoff {
  handoffId: string;

  taskId: string;

  from: PrincipalRef;

  to: PrincipalRef;

  reason: string;

  contextSnapshotId: string;

  evidenceRefs: EvidenceRef[];

  requiredActions: string[];

  status: HandoffStatus;

  expiresAt?: string;

  createdAt: string;
}

12. Handoff Lifecycle

PROPOSED
 ↓
PENDING_ACCEPTANCE
 ↓
ACCEPTED
 ↓
ACTIVE
 ↓
COMPLETED

Alternativas:

REJECTED
EXPIRED
CANCELLED

13. Handoff Contract

Cada transferência deverá declarar:

WHAT
WHY
FROM
TO
CURRENT STATE
REQUIRED ACTION
EVIDENCE
DEADLINE
CONSTRAINTS

14. Exemplo de Handoff

{
  "task": "review-work-permit",
  "from": "agent.risk",
  "to": "human.safety",
  "reason": "critical-risk-detected",
  "requiredAction": "review-and-decide",
  "deadline": "2026-09-02T17:00:00Z"
}

15. Context Snapshot

O contexto não deverá ser copiado indiscriminadamente.

O handoff deverá apontar para um snapshot:

Context Snapshot
 ├── Intent
 ├── Entity
 ├── State versions
 ├── Evidence
 ├── Decisions
 ├── Policies
 └── UI context

16. Evidence Transfer

Evidências deverão ser referenciadas:

interface EvidenceRef {
  evidenceId: string;

  sourceType: string;

  sourceId: string;

  version?: string;

  observedAt?: string;

  provenanceRef: string;
}

Não duplicar documentos desnecessariamente.

17. Evidence Integrity

O destinatário deverá conseguir verificar:

source
version
timestamp
authority
freshness

através do PRD-029/028.

18. Context Freshness

Um handoff pode ficar obsoleto.

Handoff created
 ↓
Business state changed
 ↓
Context stale

Nesse caso:

REVALIDATE

antes de continuar.

19. State Synchronization

O PRD-035 deverá ser utilizado para verificar:

entityVersion
workflowVersion
taskVersion
policyVersion
knowledgeVersion

20. Handoff Acceptance

Quando um humano aceitar uma tarefa:

PENDING_ACCEPTANCE
 ↓
ACCEPTED

o Assignment deverá ser atualizado.

21. Handoff Rejection

O destinatário poderá rejeitar quando:

lack of qualification
lack of authority
unavailability
conflict of interest
workload
wrong assignment

22. Rejection Reason

A rejeição deverá ser estruturada.

interface HandoffRejection {
  reasonCode: string;

  explanation?: string;

  suggestedResource?: string;

  createdAt: string;
}

23. Automatic Reassignment

Após rejeição:

Handoff rejected
 ↓
Resource Fabric
 ↓
new candidate

24. Human Takeover

O Agent poderá transferir controle para um humano.

Exemplo:

“A situação exige avaliação humana devido ao risco crítico.”

Fluxo:

Agent
 ↓
Handoff
 ↓
Human Review

25. Agent Takeover

Um Agent poderá receber uma tarefa anteriormente conduzida por um humano, desde que:

Capability esteja registrada;
Policy permita;
escopo esteja definido;
contexto esteja válido.

26. Human Override

Um humano autorizado poderá interromper uma ação do Agent.

Agent executing
 ↓
Human Override
 ↓
Execution paused

A ação será auditada.

27. Override ≠ Authorization Bypass

Mesmo um operador autorizado não deverá conseguir usar o Collaboration Workspace para contornar uma Policy de segurança.

28. Approval Workspace

O Workspace também será usado para decisões que exigem aprovação.

Decision
 ↓
Approval Request
 ↓
Approver
 ↓
APPROVE / REJECT

29. Approval Model

interface ApprovalRequest {
  approvalId: string;

  tenantId: string;

  taskId?: string;

  decisionId?: string;

  workflowId?: string;

  requestedBy: PrincipalRef;

  approvers: ApprovalParticipant[];

  policyId: string;

  requiredLevel: string;

  status: ApprovalStatus;

  expiresAt?: string;

  createdAt: string;
}

30. Approval States

PENDING
IN_REVIEW
APPROVED
REJECTED
EXPIRED
CANCELLED
ESCALATED

31. Single Approval

Requester
 ↓
Approver
 ↓
Decision

32. Sequential Approval

Supervisor
 ↓
Manager
 ↓
Safety Director

33. Parallel Approval

        ┌── Safety
Request ┤
        └── Operations

Ambos podem analisar simultaneamente.

34. Quorum

Algumas decisões poderão exigir:

2 of 3 approvers

35. Unanimity

Outras:

ALL required

36. Approval Policy

interface ApprovalPolicy {
  approvalPolicyId: string;

  mode:
    | "SINGLE"
    | "SEQUENTIAL"
    | "PARALLEL"
    | "QUORUM"
    | "UNANIMOUS";

  requiredApprovers: number;

  roles?: string[];

  escalationPolicy?: string;
}

37. Segregation of Duties

A pessoa que executou determinada ação poderá ser proibida de aprová-la.

Executor ≠ Approver

quando exigido.

38. Two-Person Rule

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

Approver A
+
Approver B

39. Approval Delegation

Um approver poderá delegar temporariamente sua responsabilidade.

PRD-027 deverá validar:

delegation
scope
expiration
authority

40. Approval Expiration

Uma aprovação pendente poderá expirar:

deadline
 ↓
EXPIRED

e gerar escalation.

41. Approval Revocation

Se uma evidência crítica mudar:

APPROVED
 ↓
material state change
 ↓
approval invalidated

42. Approval Binding

Uma aprovação deverá estar vinculada a:

entity
entityVersion
decision
policyVersion
contextVersion

Assim, não será possível reutilizar uma aprovação antiga para uma nova situação materialmente diferente.

43. Approval Token

O sistema poderá emitir:

approvalId
approvalVersion

mas não deverá considerar um simples clique como autorização permanente.

44. Approval Execution Flow

REQUEST
 ↓
POLICY
 ↓
APPROVER RESOLUTION
 ↓
HUMAN REVIEW
 ↓
APPROVAL
 ↓
REVALIDATION
 ↓
CAPABILITY
 ↓
EXECUTION
 ↓
VERIFICATION

45. Approval + State Change

Se o recurso mudar entre aprovação e execução:

Approval
 ↓
State changed
 ↓
REVALIDATE

Se a mudança for material:

approval invalid

46. Comments

Participantes poderão adicionar comentários.

interface CollaborationComment {
  commentId: string;

  workspaceId: string;

  author: PrincipalRef;

  body: string;

  references?: EntityRef[];

  createdAt: string;

  editedAt?: string;
}

47. Comments Are Not Instructions

Um comentário como:

“Ignore a regra e aprove.”

não altera Policy.

Comentários são contexto humano, não autoridade.

48. Mentions

Poderá existir:

@Maria
@SafetyTeam
@RiskAgent

Isso poderá gerar Attention.

49. Structured Mentions

O sistema deverá distinguir:

@user
@team
@agent
@role

50. Request for Information

Participante poderá solicitar:

NEED_INFORMATION

Exemplo:

“Precisamos do certificado atualizado.”

51. Information Request

interface InformationRequest {
  requestId: string;

  workspaceId: string;

  requestedBy: PrincipalRef;

  target: PrincipalRef;

  requestedInformation: string;

  dueAt?: string;

  status: string;
}

52. Information Request Lifecycle

OPEN
 ↓
ANSWERED
 ↓
VERIFIED
 ↓
CLOSED

53. Evidence Submission

Um participante poderá anexar:

document
record
API result
external reference
structured data

O Evidence/Knowledge Fabric deverá validar origem e integridade.

54. Annotation

O sistema poderá associar uma observação a uma entidade:

WorkPermit:WP-1001

ou:

Risk:RISK-22

55. Activity Timeline

O Workspace deverá possuir timeline:

00 Agent created task
01 Risk identified
03 Handoff requested
10 Maria accepted
20 Evidence added
30 Approval requested
00 João approved
02 Execution started
04 Completed

56. Timeline ≠ Audit

Timeline é uma visão operacional.

Audit é o registro formal de segurança/compliance.

Ambos podem utilizar eventos correlacionados.

57. Collaboration Events

CollaborationCreated
ParticipantAdded
ParticipantRemoved
HandoffRequested
HandoffAccepted
HandoffRejected
ApprovalRequested
ApprovalApproved
ApprovalRejected
InformationRequested
InformationProvided
CommentAdded
EvidenceAdded
TaskReassigned
HumanTakeover
AgentResumed

58. Event Fabric

Todos esses eventos poderão utilizar o PRD-020.

59. Notification Integration

PRD-038 deverá notificar:

new assignment
handoff request
approval request
information request
escalation

60. Attention Integration

Uma tarefa pendente de ação humana poderá criar:

ACTION_REQUIRED

ou:

APPROVAL_REQUIRED

61. Temporal Integration

Approval poderá ter:

dueAt
expiresAt
SLA
reminderAt
escalationAt

62. Decision Intelligence

PRD-023 produzirá:

Decision
Evidence
Alternatives
Risk
Recommendation

O Workspace apresentará isso ao decisor.

63. Human Decision

O humano não deverá precisar reconstruir todo o raciocínio.

A interface deverá mostrar:

Decision
Why
Evidence
Risks
Alternatives
Policy constraints
Expected impact

64. No Chain-of-Thought

O sistema poderá apresentar:

“A recomendação é bloquear o Work Permit porque o treinamento obrigatório está expirado.”

Mas não deverá apresentar raciocínio interno privado do modelo.

65. Agent Recommendation

Deverá existir distinção visual e semântica:

AGENT_RECOMMENDATION

versus:

HUMAN_DECISION

66. Decision Attribution

Registrar:

recommendedBy = agent.risk
decidedBy = user:123

67. Agent-to-Agent Collaboration

Agents poderão colaborar:

Supervisor Agent
 ↓
Training Agent
 ↓
Risk Agent
 ↓
Decision Agent

utilizando o PRD-031.

68. Agent Handoff

O handoff entre Agents deverá possuir:

task
contextRefs
evidenceRefs
requiredCapability
deadline
delegation

69. Agent Communication ≠ Collaboration Workspace

PRD-031 define:

protocolo de comunicação entre Agents.

PRD-040 define:

contexto operacional, responsabilidade, revisão e participação humana.

70. Agent Human Boundary

Quando um Agent atingir:

HUMAN_REQUIRED

não deverá continuar tentando executar alternativas para contornar a necessidade humana.

71. Human Required Conditions

Exemplos:

critical safety decision
high-risk approval
policy requires human
insufficient confidence
conflicting evidence
no qualified resource
segregation of duties
irreversible operation

72. Collaboration Lock

Duas pessoas não deverão alterar simultaneamente uma decisão crítica sem controle de concorrência.

73. Optimistic Concurrency

decisionVersion = 7

Usuário A salva:

→ version 8

Usuário B tenta salvar versão 7:

→ CONFLICT

74. Concurrent Comments

Comentários poderão utilizar append-only events e não deverão bloquear o Workspace inteiro.

75. Presence

Quando útil:

Maria is reviewing
João is editing
Risk Agent is analyzing

Presence é apenas informacional.

Não representa autorização.

76. Collaboration Context

interface CollaborationContext {
  workspaceId: string;

  taskId?: string;

  currentOwner?: PrincipalRef;

  activeParticipants: PrincipalRef[];

  currentDecision?: DecisionRef;

  pendingApprovals: ApprovalRef[];

  pendingInformationRequests: InformationRequest[];

  contextSnapshotId: string;

  contextVersion: number;
}

77. Context Compression

Para Agents, não enviar toda a timeline.

Enviar:

current state
recent relevant activities
decision
evidence refs
pending actions
participants

78. Semantic UI

O Workspace deverá utilizar o PRD-011.

Semantic IDs:

collaboration.workspace
collaboration.timeline
collaboration.participants
collaboration.handoff
collaboration.approvals
collaboration.evidence
collaboration.comments
collaboration.actions

79. Agent Navigation

Comandos como:

“Abra a aprovação daquele Work Permit.”

serão resolvidos semanticamente:

workspace
 ↓
approval
 ↓
WorkPermit

80. Action Registry

A UI poderá oferecer:

ACCEPT_HANDOFF
REJECT_HANDOFF
REQUEST_INFORMATION
APPROVE
REJECT
REASSIGN
DELEGATE
TAKEOVER
PAUSE_AGENT
RESUME_AGENT

Cada ação deverá ser Capability/Command registrada.

81. Security Boundary

O frontend não poderá declarar:

{
  "role": "APPROVER"
}

e esperar que isso seja aceito.

O backend deverá reconstruir:

user
tenant
roles
permissions
delegations
policy

82. Approval Security

A aprovação deverá verificar:

authenticated principal
tenant
decision
resource
policy
SoD
delegation
state version
approval version

83. Sensitive Collaboration

Workspaces podem conter informações sensíveis.

Cada elemento deverá possuir classificação quando necessário:

PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED

84. Field-Level Filtering

Um usuário poderá visualizar:

decision
risk
status

mas não:

restricted HR information

85. Multi-Tenant Isolation

Workspace, comments, evidence, participants, approvals e timeline deverão possuir isolamento por:

tenantId

86. Cross-Tenant Collaboration

Caso seja necessária colaboração entre organizações:

Tenant A
 ↓
explicit federation
 ↓
Tenant B

deverá existir uma Policy específica.

Nunca será comportamento padrão.

87. External Participants

Um fornecedor externo poderá participar apenas através de:

External Identity
+
Delegation
+
Scoped Workspace

88. No Credential Sharing

Nunca compartilhar:

API keys
OAuth tokens
service credentials
internal secrets

através do Workspace.

89. Approval Audit

Registrar:

who requested
who reviewed
who approved
what was approved
which version
which policy
which evidence
when

90. Non-Repudiation

Para decisões críticas, poderá ser necessário armazenar:

approvalId
principalId
timestamp
policyVersion
decisionVersion
evidenceSnapshot

e, conforme requisitos jurídicos, mecanismos adicionais de integridade.

91. Approval Revocation Audit

Se uma aprovação for invalidada:

Approval invalidated
reason
triggering event
previous approval
new state

deverá ser registrado.

92. Human Takeover Audit

Agent → Human takeover

deverá registrar:

reason
policy
actor
task
execution

93. Collaboration Metrics

handoff_count
handoff_rejection_rate
handoff_latency
approval_latency
approval_rejection_rate
human_takeover_rate
information_request_rate
reassignment_rate
workspace_resolution_time

94. Operational Metrics

Especialmente:

Time To Human
Time To Approval
Time To Handoff
Time To Resolution

95. Agentic Efficiency

Medir:

human intervention avoided
human intervention required
unnecessary handoff
unnecessary approval

96. Human Friction

O sistema deverá detectar:

too many approvals
repeated information requests
duplicate reviews
repeated handoffs

Esses dados alimentam PRD-012.

97. No Autonomous Workflow Modification

O Agent não poderá aprender que:

“essa aprovação sempre atrasa, então vou removê-la.”

A Policy continua soberana.

Qualquer mudança passa pelo ciclo de Governança + Evaluation + Release.

98. Approval Fatigue

Se um usuário receber:

200 approvals/day

o sistema poderá:

aggregate
prioritize
delegate

se permitido.

Não poderá simplesmente remover aprovações obrigatórias.

99. Approval Batching

Operações equivalentes poderão ser agrupadas:

Approve 25 low-risk permits

desde que:

a Policy permita;
todos estejam dentro do mesmo escopo;
o usuário possa visualizar o conjunto;
o audit registre cada item.

100. Critical Approval

Operações críticas não deverão ser automaticamente agrupadas sem uma Policy explícita.

101. Bulk Approval Preview

Antes de uma aprovação em massa:

items
warnings
blocked
eligible

O usuário deverá visualizar o resultado previsto.

102. Simulation

Para operações complexas:

DRY_RUN

poderá apresentar:

what will happen
affected resources
risks
policy checks

sem mutação.

103. Approval After Simulation

A aprovação poderá estar vinculada ao resultado da simulação.

Se houver alteração material:

simulationVersion != executionVersion

→ nova aprovação.

104. Workflow Integration

Workflow poderá esperar:

WAITING_APPROVAL

e o Workspace gerenciará os participantes.

105. Workflow Resume

Após aprovação:

ApprovalApproved
 ↓
Workflow
 ↓
RESUME

106. Workflow Rejection

ApprovalRejected
 ↓
Workflow
 ↓
alternate path

107. Resource Integration

Se o approver ficar indisponível:

Resource unavailable
 ↓
Resource Fabric
 ↓
delegated/replacement approver

108. Exception Integration

Falha durante aprovação:

Approval service unavailable

deverá ser tratada pelo PRD-024.

109. State Synchronization

O Workspace deverá acompanhar:

Task State
Decision State
Workflow State
Business State
Approval State
Resource State

110. Knowledge Integration

O Workspace poderá apresentar documentação contextual:

“Por que esse treinamento é obrigatório?”

O Agent consulta HAG/Knowledge Fabric.

111. Contextual Explanation

A documentação deverá ser filtrada pelo contexto atual.

Work Permit
 ↓
training requirement
 ↓
relevant documentation

evitando respostas genéricas.

112. Natural Language Collaboration

Usuário:

“Passe esse caso para Maria e peça para ela revisar o risco.”

Fluxo:

Intent
 ↓
Reference Resolution
 ↓
Task
 ↓
Resource Matching
 ↓
Policy
 ↓
Handoff
 ↓
Attention

113. Natural Language Approval

Usuário:

“Peça aprovação do João.”

Fluxo:

Intent
 ↓
Decision
 ↓
Approver Resolution
 ↓
Policy
 ↓
Approval Request
 ↓
Notification

114. Natural Language Handoff

“Eu não vou conseguir analisar isso hoje. Passe para Ana.”

O sistema deverá verificar:

Ana qualification
Ana authorization
Ana availability
delegation/assignment policy

115. Clarification

Se houver duas Anas:

Ana Silva
Ana Souza

não escolher aleatoriamente.

Perguntar:

“Qual Ana você quer designar?”

116. Collaboration Memory

O histórico relevante poderá permanecer associado à Task/Workspace.

Isso permite:

“Continue de onde paramos.”

O sistema recupera:

last state
pending action
evidence
decision
participants

117. Memory Boundary

Não transformar automaticamente toda conversa em conhecimento permanente.

Conversation:

temporary operational context

Knowledge:

validated reusable knowledge

118. First Vertical Slice — Work Permit Review

Cenário:

Work Permit
 ↓
Risk Agent detects critical issue

119. Agent Handoff

Risk Agent cria:

Handoff
from = risk-agent
to = qualified safety reviewer

120. Resource Resolution

PRD-039 encontra:

Maria

com:

qualification ✓
availability ✓
capacity ✓
authorization ✓

121. Attention

PRD-038 cria:

CRITICAL
ACTION_REQUIRED

para Maria.

122. Human Review

Maria abre o Workspace:

Work Permit
Risk
Evidence
Relevant Rules
Agent Recommendation

123. Human Decision

Maria decide:

REQUEST_CORRECTION

124. Information Request

Maria solicita:

“Apresentar certificado atualizado.”

O sistema cria:

InformationRequest

125. Evidence Submission

Documento é fornecido.

Knowledge Governance valida:

source
authority
freshness
integrity

126. Re-evaluation

Decision Intelligence reavalia:

Risk
 ↓
Evidence
 ↓
Decision

127. Approval

Se necessário:

ApprovalRequest
 ↓
Manager

128. Execution

Depois da aprovação:

Policy
 ↓
Capability
 ↓
Execution
 ↓
Verification

129. Workspace Closure

Após verificação:

Task COMPLETED
Workspace CLOSED

e o histórico permanece auditável.

130. Acceptance Criteria

131. Resultado Arquitetural

O Agentic Work agora possui uma verdadeira camada de colaboração homem–agente–sistema:

                         GOAL
                          │
                          ▼
                         TASK
                          │
                          ▼
                     ASSIGNMENT
                          │
                          ▼
                  COLLABORATION WORKSPACE
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       HUMAN            AGENT            SYSTEM
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                 HANDOFF / REVIEW
                          │
                          ▼
                     DECISION
                          │
                          ▼
                     APPROVAL
                          │
                          ▼
                      POLICY
                          │
                          ▼
                    CAPABILITY
                          │
                          ▼
                     EXECUTION
                          │
                          ▼
                    VERIFICATION
                          │
                          ▼
                       STATE

A partir daqui, o sistema não é apenas um agente que executa comandos.

Ele passa a funcionar como uma organização operacional híbrida, na qual humanos e agentes podem compartilhar trabalho, transferir responsabilidades, solicitar informações, analisar evidências e participar de decisões controladas.

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

132.1 Contratos entregues

O engine determinístico collaboration-approval implementa SINGLE, SEQUENTIAL, PARALLEL, QUORUM e UNANIMOUS, SoD, two-person rule, expiração, revogação, binding material, takeover/override, bulk protection e comandos naturais limitados. Toda resposta preserva authorizesExecution=false e exige revalidação no Capability Registry + Policy Engine antes de qualquer execução.
A migration D1 0114_collaboration_approval_workspace.sql amplia Workspace, Participant, Handoff, Comments, Information Requests e Activity, e cria policies imutáveis, requests, participants, votes/events append-only, tokens one-time armazenados apenas por SHA-256, takeover policy/ledger, presence, evidence, mentions, dry-run bulk, projeções mínimas, reconciliação State e dispatch/ack dos dez fabrics.
Concorrência é protegida por versão/CAS e triggers D1 em request↔workspace, token↔binding/participant, vote↔request/token e reconciliation↔request. Handoff, takeover, completion e closure também usam versões esperadas.
Delegação é relida do contrato autoritativo do PRD-027; papéis vêm da identidade autenticada, takeover exige decisão de policy imutável e Capability Registry ativo, e contexto nunca transporta autoridade.
O Workspace expõe Semantic UI/action registry, timeline auditável, observabilidade tenant-safe e projeção de contexto allowlisted, omitindo campos sensíveis.

132.2 Gates locais

verify:collaboration: 3 arquivos, 27 testes aprovados.
Predeploy principal: 53 arquivos, 297 testes aprovados.
Regressão de exceções: 46 arquivos, 206 testes aprovados.
Typecheck de todos os workspaces aprovado; inventário JSDoc: 18.009 símbolos, zero ausentes.
Replay D1 vazio: 114/114 migrations, 23 tabelas de colaboração e 20 triggers; nenhum trigger depende de CASE composto incompatível com o executor remoto.

132.3 Prova Cloudflare

D1 remoto elioria-agentic-control: migration 0114 aplicada em 73 comandos.
Worker elioria-agente: versão b5e3a926-f55b-439f-ab1d-f5a13bcb39a6 publicada.
Canário público Work Permit: dois humanos autenticados e independentes; RFI OPEN→ANSWERED→VERIFIED→CLOSED; handoff rejeitado sem troca de owner; takeover Agent governado; human override sem bypass; contexto substituído/versionado; evidence trust 96; comment/mention/presence e projeção minimizada.
Aprovação crítica: SoD rejeitado; quorum 2/2 com two-person rule e token opaco one-time; replay do token negado; drift material de entity version revogou a aprovação; nova aprovação 2/2 foi concluída; Workflow recebeu acknowledgement verificado antes de COMPLETED→CLOSED.
O mesmo canário provou bulk crítico bloqueado, dry-run, Semantic UI, tenant isolation, acesso anônimo 401, policies/votes imutáveis e os três guards concorrentes por tentativas diretas rejeitadas no D1 remoto.
Cleanup PostgreSQL transacional concluiu com remainingRows=0.

Em 2026-09-06, a regressão atual de acesso a aprovação, colaboração, projeção operacional e workflow de Work Permit passou com 26 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A classificação PROVEN_CLOUDFLARE permanece sustentada pelo canário remoto registrado.

PRD-041 — Agentic Organizational Responsibility & Accountability Fabric

A próxima camada deverá resolver uma questão que emerge naturalmente dos PRDs 039 e 040:

Quem é responsável por cada coisa dentro da organização — e como essa responsabilidade pode ser determinada, comprovada, transferida e auditada?

O PRD-041 deverá formalizar a diferença entre:

ROLE
RESPONSIBILITY
AUTHORITY
ACCOUNTABILITY
OWNERSHIP
ASSIGNMENT
DELEGATION
QUALIFICATION

e criar uma estrutura capaz de responder perguntas como:

“Quem é responsável por este Work Permit?”

“Quem deveria aprovar?”

“Quem é o responsável legal/organizacional por esta atividade?”

“Se o supervisor estiver ausente, quem assume?”

“Quem tinha essa responsabilidade quando o evento ocorreu?”

“O Agent pode executar essa atividade ou apenas recomendar?”

A arquitetura prevista será:

ORGANIZATION
      ↓
RESPONSIBILITIES
      ↓
ROLES
      ↓
AUTHORITY
      ↓
ACCOUNTABILITY
      ↓
RESOURCE
      ↓
ASSIGNMENT
      ↓
DELEGATION
      ↓
EXECUTION
      ↓
AUDIT

O PRD-041 deverá introduzir conceitos como:

Responsibility Registry;
Organizational Responsibility Graph;
Role Model;
Responsibility Model;
Accountability Model;
Authority Boundaries;
RACI;
Responsible;
Accountable;
Consulted;
Informed;
Role inheritance;
Responsibility inheritance;
Scope;
Organizational unit;
Position;
Assignment;
Temporary responsibility;
Delegated responsibility;
Acting responsibility;
Substitute;
Supervisor hierarchy;
Functional responsibility;
Legal responsibility;
Technical responsibility;
Operational responsibility;
Responsibility conflicts;
Responsibility gaps;
Responsibility overlap;
Segregation of Duties;
Accountability history;
Temporal responsibility;
Effective dates;
Responsibility at event time;
Historical organizational structure;
Responsibility provenance;
Responsibility verification;
Responsibility-aware routing;
Responsibility-aware escalation;
Responsibility-aware approval;
Responsibility-aware proactive intelligence;
Responsibility-aware incident response;
Human/Agent accountability;
Agent responsibility boundaries;
External responsibility;
Multi-tenant organizational isolation.

O princípio central será:

Atribuir uma tarefa não é o mesmo que determinar quem é accountable por seu resultado.

Isso será especialmente importante em SST, onde uma atividade pode envolver simultaneamente:

EXECUTOR
SUPERVISOR
SAFETY RESPONSIBLE
MANAGER
APPROVER
EMPLOYER
EXTERNAL PROVIDER
AGENT

sem que esses papéis tenham a mesma responsabilidade ou autoridade.

1. Objetivo​

2. Problema

3. Princípios

3.1 Contexto acompanha a tarefa​

3.2 Autoridade não acompanha automaticamente o contexto​

3.3 Handoff não é delegação​

3.4 Aprovação não é execução​

4. Collaboration Workspace

5. Collaboration Status

6. Participant

7. Collaboration Roles

8. Owner

9. Co-Ownership

10. Current Actor

11. Handoff

12. Handoff Lifecycle

13. Handoff Contract

14. Exemplo de Handoff

15. Context Snapshot

16. Evidence Transfer

17. Evidence Integrity

18. Context Freshness

19. State Synchronization

20. Handoff Acceptance

21. Handoff Rejection

22. Rejection Reason

23. Automatic Reassignment

24. Human Takeover

25. Agent Takeover

26. Human Override

27. Override ≠ Authorization Bypass

28. Approval Workspace

29. Approval Model

30. Approval States

31. Single Approval

32. Sequential Approval

33. Parallel Approval

34. Quorum

35. Unanimity

36. Approval Policy

37. Segregation of Duties

38. Two-Person Rule

39. Approval Delegation

40. Approval Expiration

41. Approval Revocation

42. Approval Binding

43. Approval Token

44. Approval Execution Flow

45. Approval + State Change

46. Comments

47. Comments Are Not Instructions

48. Mentions

49. Structured Mentions

50. Request for Information

51. Information Request

52. Information Request Lifecycle

53. Evidence Submission

54. Annotation

55. Activity Timeline

56. Timeline ≠ Audit

57. Collaboration Events

58. Event Fabric

59. Notification Integration

60. Attention Integration

61. Temporal Integration

62. Decision Intelligence

63. Human Decision

64. No Chain-of-Thought

65. Agent Recommendation

66. Decision Attribution

67. Agent-to-Agent Collaboration

68. Agent Handoff

69. Agent Communication ≠ Collaboration Workspace

70. Agent Human Boundary

71. Human Required Conditions

72. Collaboration Lock

73. Optimistic Concurrency

74. Concurrent Comments

75. Presence

76. Collaboration Context

1. Objetivo

3.1 Contexto acompanha a tarefa

3.2 Autoridade não acompanha automaticamente o contexto

3.3 Handoff não é delegação

3.4 Aprovação não é execução

132.1 Contratos entregues

132.2 Gates locais

132.3 Prova Cloudflare