PRD-028 — Agentic Knowledge Operations & Continuous Knowledge Fabric

1. Objetivo

O PRD-028 define a camada responsável por transformar o conhecimento do Agentic Work em uma estrutura viva, temporal, versionada, proveniente de fontes confiáveis e continuamente atualizada.

Até aqui, a arquitetura já possui:

TypeScript
   ↓
TypeDoc
   ↓
Docusaurus
   ↓
Markdown
   ↓
Obsidian
   ↓
HAG
   ↓
Keyword Index / BM25 / Wikilinks / Vectorize

Agora precisamos incorporar também:

Business APIs
External Integrations
Events
Workflows
Decisions
Documents
Operational Data
User Corrections
Agent Results

O resultado será uma Knowledge Fabric.

2. Princípio Fundamental

A arquitetura deverá separar rigorosamente:

KNOWLEDGE
FACT
EVENT
STATE
INFERENCE
RULE
RECOMMENDATION
DOCUMENT

Uma inferência do agente jamais deverá ser promovida automaticamente a fato.

Por exemplo:

LLM:
"Provavelmente o treinamento está vencido."

não poderá virar:

training.status = EXPIRED

sem uma fonte que sustente essa afirmação.

3. Knowledge Fabric

A Knowledge Fabric será responsável por conectar:

                 KNOWLEDGE FABRIC
                       │
       ┌───────────────┼────────────────┐
       ▼               ▼                ▼
   Static          Operational       External
 Knowledge          Knowledge        Knowledge
       │               │                │
       └───────────────┼────────────────┘
                       ▼
                 Provenance Layer
                       │
                       ▼
                Temporal Model
                       │
                       ▼
                  HAG / Graph
                       │
              ┌────────┴────────┐
              ▼                 ▼
          Lexical           Semantic
       Index / BM25        Vectorize
              │                 │
              └────────┬────────┘
                       ▼
                Agent Retrieval

4. Tipos de Conhecimento

O sistema deverá reconhecer pelo menos:

Tipo	Exemplo
`DOCUMENTATION`	documentação TypeDoc
`BUSINESS_RULE`	regra de validade
`FACT`	treinamento válido até 15/09
`STATE`	Work Permit está APPROVED
`EVENT`	TrainingExpired
`ENTITY`	trabalhador EMP-104
`RELATIONSHIP`	trabalhador pertence à empresa
`INFERENCE`	risco provavelmente alto
`RECOMMENDATION`	solicitar renovação
`DECISION`	liberar permissão
`EXTERNAL_DATA`	informação do LMS
`USER_FEEDBACK`	usuário corrigiu informação

5. Static Knowledge

Conhecimento estático inclui:

documentation
manuals
TypeDoc
business definitions
technical specifications
policies
procedures

A origem continuará sendo o pipeline existente.

Não será criado um novo sistema de documentação.

6. Operational Knowledge

Conhecimento operacional representa o estado atual do negócio.

Exemplo:

Work Permit WP-10231
status = APPROVED

ou:

Employee EMP-104
training NR-10
validUntil = 2026-09-15

Esse conhecimento deverá possuir origem rastreável.

7. Event ≠ State

Um evento:

TrainingExpired

é um fato ocorrido.

O estado:

training.status = EXPIRED

é uma representação atual.

O Event Fabric registra o evento.

A Knowledge Fabric poderá derivar o estado.

8. Event Sourcing Não Será Obrigatório

A arquitetura não deverá transformar todo o SST em Event Sourcing.

O sistema existente continuará sendo a fonte de verdade dos dados transacionais.

A Knowledge Fabric será uma camada derivada para:

retrieval
reasoning
context
relationships
historical analysis

9. Source of Truth

Cada informação deverá declarar sua fonte de autoridade.

Exemplo:

interface KnowledgeSource {
  sourceId: string;

  sourceType:
    | "BUSINESS_API"
    | "DATABASE"
    | "DOCUMENT"
    | "EVENT"
    | "EXTERNAL_API"
    | "USER"
    | "AGENT";

  authorityLevel:
    | "AUTHORITATIVE"
    | "TRUSTED"
    | "VERIFIED"
    | "UNVERIFIED";

  sourceReference?: string;
}

10. Provenance

Todo conhecimento factual deverá possuir provenance.

interface KnowledgeProvenance {
  sourceId: string;

  sourceType: string;

  sourceReference?: string;

  retrievedAt: string;

  observedAt?: string;

  importedAt: string;

  transformation?: string;

  confidence?: number;
}

11. Exemplo de Provenance

{
  "sourceType": "EXTERNAL_API",
  "sourceReference": "lms:worker-99281",
  "observedAt": "2026-09-01T18:00:00Z",
  "retrievedAt": "2026-09-01T18:00:01Z",
  "authorityLevel": "VERIFIED"
}

Assim o agente poderá responder:

“Essa informação veio do LMS e foi consultada há 2 minutos.”

12. Temporal Knowledge

Informações de SST frequentemente dependem de tempo.

Exemplo:

Training valid:
2026-01-01 → 2026-09-15

A Knowledge Fabric deverá suportar:

validFrom
validUntil
observedAt
createdAt
updatedAt
expiredAt

13. Bitemporal Model

Quando necessário, deverá ser possível distinguir:

Valid Time

Quando a informação é verdadeira no mundo real.

Transaction Time

Quando o sistema tomou conhecimento dela.

Exemplo:

Training expired:
15/08

SST discovered:
20/08

Isso é diferente de dizer que expirou em 20/08.

14. Knowledge Record

interface KnowledgeRecord {
  knowledgeId: string;

  tenantId: string;

  type: KnowledgeType;

  subjectId: string;

  predicate: string;

  object: unknown;

  validFrom?: string;

  validUntil?: string;

  observedAt?: string;

  provenance: KnowledgeProvenance;

  version: number;

  status:
    | "ACTIVE"
    | "SUPERSEDED"
    | "REVOKED"
    | "EXPIRED";
}

15. Knowledge Graph

O HAG existente deverá continuar sendo a estrutura principal de relacionamento.

Exemplo:

Employee:EMP-104
       │
       ├── HAS_TRAINING
       │       │
       │       └── Training:NR10
       │
       ├── ASSIGNED_TO
       │       │
       │       └── WorkPermit:WP-10231
       │
       └── BELONGS_TO
               │
               └── Tenant:A

16. Semantic IDs

O PRD-009 continua sendo a autoridade para Semantic IDs.

Exemplos:

employee:EMP-104
training:NR10
workPermit:WP-10231

Não criar novos identificadores paralelos sem necessidade.

17. Knowledge Relationships

A Knowledge Fabric deverá suportar relações como:

HAS_TRAINING
ASSIGNED_TO
BELONGS_TO
REQUIRES
DEPENDS_ON
DOCUMENTED_BY
IMPLEMENTED_BY
VALIDATED_BY
AFFECTS
CAUSED_BY
SUPERSEDES
CONFLICTS_WITH

18. Wikilinks

As conexões existentes de Wikilinks deverão ser preservadas.

Elas poderão representar:

documentation relationships
semantic relationships
business relationships
cross-domain references

A expansão deverá continuar limitada para preservar performance.

19. Knowledge Ingestion

O pipeline geral será:

Source
 ↓
Connector
 ↓
Parser
 ↓
Normalizer
 ↓
Validator
 ↓
Entity Resolver
 ↓
Provenance
 ↓
Temporal Processor
 ↓
Conflict Detection
 ↓
Knowledge Store
 ↓
Indexing

20. Ingestion Sources

A primeira versão deverá suportar:

TypeDoc
Markdown
Docusaurus
Business APIs
Event Fabric
External Gateway
Documents
User Corrections

21. Documentation Ingestion

O conteúdo do TypeDoc/Docusaurus deverá ser associado aos Semantic IDs.

Exemplo:

workPermit.updateValidity
       │
       ├── TypeDoc
       ├── Source Function
       ├── Capability
       ├── UI Action
       └── Policy

Isso reutiliza diretamente o PRD-009.

22. Code Knowledge

O conhecimento técnico poderá conter:

module
class
function
interface
type
API
endpoint
capability
dependency

O TypeDoc continuará sendo a principal representação documental.

23. Business Knowledge

O sistema também deverá conhecer:

entities
relationships
states
business rules
workflows
capabilities
policies

Por exemplo:

Work Permit
→ requires
→ Training

24. API Knowledge

Cada API poderá ser associada:

endpoint
capability
entity
input schema
output schema
authorization
documentation

O agente nunca deverá usar essa informação para contornar o Capability Registry.

Ela serve para entender o sistema, não para criar um caminho paralelo de execução.

25. External Knowledge

Informações externas deverão possuir:

integrationId
externalEntityId
retrievedAt
authority
freshness
tenantId

26. Freshness

Cada Knowledge Source deverá declarar seu nível de atualização necessário.

Exemplo:

training:
  freshness: 24h

permit:
  freshness: 5m

critical_access:
  freshness: 1m

27. Freshness Policy

Quando o agente recuperar um dado:

Knowledge
 ↓
Freshness Check

Resultado:

FRESH
STALE
EXPIRED
UNKNOWN

28. Stale Knowledge

O agente não deverá apresentar:

STALE

como se fosse:

CURRENT

Exemplo:

“O último status conhecido do treinamento era válido até 15/09, mas essa informação foi consultada há 48 horas.”

29. Automatic Refresh

Quando o conhecimento estiver stale e existir uma capability de consulta:

Knowledge stale
 ↓
Capability
 ↓
External Gateway
 ↓
Fresh data
 ↓
Knowledge update

Isso conecta:

Knowledge Fabric
+
Capability Runtime
+
External Gateway

30. Knowledge Cache

O sistema deverá utilizar diferentes níveis:

L1 → in-memory/request
L2 → KV/cache
L3 → structured knowledge
L4 → HAG
L5 → Vectorize

A estratégia deverá privilegiar baixa latência.

31. Indexing Pipeline

Depois de ingerir conhecimento:

Knowledge Record
       │
       ├── Exact Index
       ├── Keyword Index
       ├── BM25
       ├── Graph Index
       └── Vectorize

O PRD-003 continuará sendo responsável pela recuperação.

32. Incremental Indexing

Não deverá ser necessário reconstruir todo o índice a cada mudança.

Exemplo:

TrainingUpdated
 ↓
Affected Knowledge Records
 ↓
Incremental Index Update

33. Change Detection

A ingestão deverá detectar:

CREATED
UPDATED
DELETED
EXPIRED
SUPERSEDED
REVOKED

34. Knowledge Version

Toda alteração relevante deverá produzir uma versão.

Knowledge:
v1
v2
v3

Isso permitirá reproduzir uma decisão histórica.

35. Decision Reproducibility

Se uma decisão ocorreu em:

2026-08-20

o sistema deverá conseguir consultar:

Knowledge version
Policy version
Capability version
Agent version

daquele momento.

36. Knowledge Snapshot

Para operações importantes poderá existir:

interface KnowledgeSnapshot {
  snapshotId: string;

  tenantId: string;

  knowledgeVersion: string;

  createdAt: string;

  scope: string[];

  checksum: string;
}

37. Conflict Detection

Duas fontes podem discordar.

Exemplo:

SST:
training.validUntil = 2026-09-15

LMS:
training.validUntil = 2026-08-15

A Knowledge Fabric deverá produzir:

CONFLICT

e não escolher silenciosamente uma delas.

38. Conflict Resolution

A resolução poderá considerar:

source authority
freshness
timestamp
tenant policy
domain rule
verification

39. Conflict Example

Government Source
        ↓
Authoritative

LMS
        ↓
Verified

Uploaded PDF
        ↓
Unverified

A regra de domínio poderá determinar a prioridade.

40. Knowledge Confidence

Confidence deverá ser distinta de authority.

Uma fonte pode ser:

AUTHORITATIVE

mas os dados podem estar:

STALE

Portanto:

authority ≠ freshness ≠ confidence

41. LLM Inference

Inferências do LLM deverão ser marcadas:

type = INFERENCE

com:

model
promptVersion
inputReferences
createdAt
confidence

42. Inference Expiration

Inferências deverão possuir validade curta quando dependerem de dados mutáveis.

Exemplo:

Risk inference:
expires in 1 hour

Não deverão permanecer indefinidamente como fatos.

43. Recommendation Storage

Recomendações poderão ser armazenadas separadamente.

Recommendation
 ≠
Fact

Exemplo:

FACT:
Training expires in 10 days.

RECOMMENDATION:
Schedule renewal.

44. User Corrections

O usuário poderá corrigir o agente:

“Não, esse funcionário não é o responsável por essa permissão.”

Isso deverá gerar:

USER_FEEDBACK

e não alterar diretamente o conhecimento oficial.

45. Correction Workflow

User Correction
 ↓
Feedback Record
 ↓
Validation
 ↓
Human/System Review
 ↓
Knowledge Update

Para dados críticos, revisão será obrigatória.

46. Learning Boundary

O Agentic Work não poderá fazer:

User says X
 ↓
X becomes permanent truth

O caminho deverá ser:

User says X
 ↓
Evidence
 ↓
Validation
 ↓
Approved Knowledge

47. Knowledge Governance

Cada conhecimento deverá possuir:

owner
source
authority
lifecycle
version
tenant
classification
retention

48. Knowledge Lifecycle

DISCOVERED
 ↓
INGESTED
 ↓
VALIDATED
 ↓
ACTIVE
 ↓
SUPERSEDED
 ↓
EXPIRED
 ↓
ARCHIVED

49. Revocation

Informação incorreta deverá poder ser revogada.

ACTIVE
 ↓
REVOKED

O índice deverá ser atualizado imediatamente ou dentro do SLA definido.

50. Tenant Isolation

Todos os registros operacionais deverão possuir:

tenantId

e as consultas deverão ser tenant-aware.

Isso inclui:

HAG
BM25
Vectorize
cache
knowledge records
embeddings
events
documents
feedback
inferences

51. Global Knowledge

Alguns conhecimentos poderão ser globais.

Exemplo:

API documentation
TypeScript language
system architecture

Mas o acesso continuará sujeito às políticas.

52. Tenant Knowledge

Conhecimentos específicos:

Tenant A's procedures
Tenant A's workers
Tenant A's permits
Tenant A's integrations

não poderão aparecer no contexto do Tenant B.

53. Embedding Isolation

Embeddings deverão carregar metadata suficiente para garantir filtragem:

{
  "tenantId": "TENANT-A",
  "semanticId": "training:NR10",
  "type": "FACT"
}

A filtragem deverá ocorrer antes de retornar resultados ao agente.

54. Cache Isolation

Cache keys deverão incluir tenant quando o dado não for global.

knowledge:{tenantId}:{knowledgeId}

Não:

knowledge:{knowledgeId}

para conteúdo privado.

55. Knowledge Access Policy

Nem todo agente poderá consultar tudo.

Exemplo:

Training Agent
→ training knowledge

Medical Agent
→ medical knowledge

Compliance Agent
→ compliance knowledge

56. Knowledge Projection

Assim como o contexto de agentes possui projeção, o conhecimento poderá ser projetado:

Full Knowledge
      ↓
Agent Scope
      ↓
Allowed Knowledge
      ↓
Minimal Context

57. Sensitive Knowledge

Dados classificados como sensíveis deverão possuir:

classification
accessPolicy
redactionPolicy

O agente deverá receber apenas os campos necessários.

58. Knowledge-to-Agent Context

O pipeline de retrieval será:

Intent
 ↓
Context
 ↓
Agent Scope
 ↓
Tenant Filter
 ↓
Freshness
 ↓
Exact
 ↓
Keyword
 ↓
BM25
 ↓
Graph
 ↓
Vectorize
 ↓
Rank Fusion
 ↓
Context Selection

Isso mantém a arquitetura de alta performance já definida.

59. Knowledge-to-Decision

O Decision Engine poderá solicitar:

Facts
Rules
Relationships
History
Evidence

A Knowledge Fabric fornecerá os fatos, mas não decidirá por conta própria.

60. Knowledge-to-Workflow

Workflows poderão consultar conhecimento:

Workflow
 ↓
Knowledge Query
 ↓
Current Facts
 ↓
Transition condition

Exemplo:

IF training.valid == false
THEN WAITING_RENEWAL

61. Event → Knowledge

O Event Fabric poderá produzir mudanças:

TrainingCompleted
 ↓
Knowledge Update
 ↓
training.status = VALID

62. Knowledge → Event

Uma mudança importante poderá produzir evento:

Knowledge State Changed
 ↓
KnowledgeUpdated

Porém isso deverá ser usado com cuidado para não criar loops.

63. Knowledge Feedback Loop

A arquitetura completa será:

External System
      ↓
Event/API
      ↓
Knowledge Fabric
      ↓
Agent
      ↓
Decision
      ↓
Workflow
      ↓
Capability
      ↓
Business System
      ↓
Event
      ↓
Knowledge Fabric

64. Loop Protection

O sistema deverá identificar:

Knowledge update
 ↓
Event
 ↓
Workflow
 ↓
Capability
 ↓
same knowledge update

e impedir loops infinitos.

Deverão existir:

causationId
correlationId
event lineage
reaction depth
deduplication

65. Knowledge Quality

Métricas deverão incluir:

Freshness
Coverage
Conflict Rate
Stale Rate
Validation Rate
Source Authority
Retrieval Accuracy
Knowledge Drift

66. Knowledge Drift

O sistema deverá detectar quando:

Documentation

está divergindo de:

Implementation

ou:

Capability

ou:

Business API

Exemplo:

TypeDoc says:
parameter = validityDays

API now expects:
validityPeriod

Isso deverá gerar:

KNOWLEDGE_DRIFT

67. Documentation Drift

O pipeline poderá comparar:

Source Code
TypeDoc
Capability Registry
API Contract
UI Manifest

e detectar inconsistências.

Isso complementa o PRD-009.

68. External Drift

Também deverá detectar:

External API schema changed

através de:

contract tests
schema validation
integration health

69. Knowledge Alerts

Condições importantes poderão gerar eventos:

KNOWLEDGE_CONFLICT
KNOWLEDGE_STALE
KNOWLEDGE_DRIFT
SOURCE_UNAVAILABLE
SOURCE_REVOKED
VALIDATION_FAILURE

Esses eventos poderão alimentar o PRD-024.

70. Search Explainability

O Agent Retrieval poderá registrar:

matched exact
matched keyword
BM25 score
graph boost
vector score
freshness
authority

Isso será usado para observabilidade.

Não será necessário expor todos esses detalhes ao usuário.

71. No Hidden Reasoning

O sistema poderá explicar:

“Usei o registro do LMS atualizado há 3 minutos.”

Mas não deverá revelar chain-of-thought interno do modelo.

72. Knowledge Cost Optimization

Nem todo conteúdo precisa de embedding.

Estratégia:

Exact → no embedding
Keyword → no embedding
BM25 → no embedding
Graph → no embedding
Semantic fallback → Vectorize

Isso reduz:

storage
compute
latency
cost

73. Embedding Strategy

Embeddings deverão ser criados prioritariamente para conteúdo que:

possui valor semântico;
não é facilmente recuperado lexicalmente;
possui estabilidade suficiente;
justifica custo de indexação.

74. Chunking

Documentos deverão ser divididos semanticamente.

Preferir:

function
section
procedure
business rule
entity
paragraph group

em vez de chunks arbitrários.

75. Semantic Chunk Metadata

Cada chunk deverá possuir:

tenantId
knowledgeId
semanticId
documentId
section
source
version
type
authority
validity

76. Knowledge Bundle

Para cada release poderá existir:

interface KnowledgeBundle {
  knowledgeVersion: string;

  manifestVersion: string;

  sources: string[];

  records: number;

  embeddings: number;

  checksum: string;

  createdAt: string;
}

77. Release Integration

O PRD-016 deverá incluir:

knowledgeVersion

na Release Bundle.

Assim:

Agent Version
+
Knowledge Version
+
Capability Version
+
Policy Version

serão sempre identificáveis.

78. Rollback

Uma release poderá voltar para:

Knowledge v12

sem necessariamente restaurar o banco operacional.

A Knowledge Fabric é uma camada versionada/derivada.

79. Historical Queries

O agente poderá futuramente responder:

“Como estava essa permissão na semana passada?”

através de:

temporal knowledge
+
events
+
snapshots

80. Example — Work Permit

Conhecimento:

WP-10231

relações:

ASSIGNED_TO → EMP-104
REQUIRES → NR-10
REQUIRES → PPE-001

estado atual:

status = SUBMITTED

treinamento:

validUntil = 2026-09-15

risco:

MEDIUM

81. Query Example

Usuário:

“Por que a WP-10231 ainda não pode ser liberada?”

Retrieval:

WP-10231
 ↓
State
 ↓
Required Training
 ↓
Training Status
 ↓
Risk
 ↓
Compliance Rules
 ↓
Decision

O agente poderá responder com fatos e fontes.

82. Example of Conflict

LMS:
training expired

SST:
training valid

Knowledge Fabric:

CONFLICT

Decision Engine:

UNCERTAIN

Decision Center:

REQUIRES_REVIEW

Isso é muito superior a simplesmente escolher a resposta do LLM.

83. First Vertical Slice

O primeiro vertical slice deverá utilizar:

Work Permit
+
Employee
+
Training

Fontes:

Business API
LMS External Gateway
Event Fabric
Existing HAG
TypeDoc

84. Fluxo do Vertical Slice

LMS
 ↓
TrainingUpdated
 ↓
Event Fabric
 ↓
Knowledge Ingestion
 ↓
Validation
 ↓
Provenance
 ↓
HAG
 ↓
BM25 / Vectorize

Depois:

User
 ↓
"Qual o status do treinamento de João?"
 ↓
Intent
 ↓
Knowledge Retrieval
 ↓
Freshness
 ↓
Answer

85. Segundo Fluxo

Usuário:

“Por que a permissão dele não pode ser liberada?”

Work Permit
 ↓
Knowledge Graph
 ↓
Training
 ↓
Compliance Rule
 ↓
Risk
 ↓
Decision Engine
 ↓
Explanation

86. Terceiro Fluxo

LMS envia:

TrainingExpired

↓

Knowledge Update

↓

Affected Work Permits

↓

Proactive Intelligence

↓

Decision

↓

Workflow

Esse fluxo conecta praticamente toda a arquitetura desenvolvida até aqui.

87. Critérios de Aceitação

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

Bundles de conhecimento versionados são compilados para índice tenant/release-bound e armazenados com hash em R2/D1. A recuperação combina exact, keyword, BM25, semântica e Vectorize, preserva citações, validade temporal e limite de contexto. Jobs de indexação incremental e recertificação de confiança são acionados pelo cron; fatos não verificados, evidência revogada, conflito ou staleness não passam pelo trust gate para ação.

Em 2026-09-05, as suítes de Knowledge Fabric passaram com 47 testes em 8 arquivos. O canário remoto comprovou bundle tenant-bound ACTIVE, índice READY, dois documentos-fonte, seis chunks e seis vetores observados, chunking versionado, manifesto hash, recibo de mutação vetorial e retrieval com integridade verificada; nenhum segredo foi exposto e o cleanup confirmou remainingRows:0. O router preserva wikilinks no índice compilado e os expande no ranking com limite de relevância; sua consulta temporal é tenant/release-bound e retorna uma versão histórica somente quando o instante at pertence à sua janela de validade. A recertificação detecta drift de conhecimento ao confrontar lifecycle e hashes ativos do bundle com os chunks vetoriais esperados e observados, marcando o índice DRIFTED quando divergem. O trust gate detecta fontes conflitantes, abre revisão humana isolada por tenant e resolve-a somente com evidência ativa selecionada, motivo hashado, versão otimista e expiração. Ingestão operacional/externa ampla, drift documental/externo e vertical slice Work Permit permanecem abertos para prova dedicada.

Em 2026-09-06, a regressão atual de trust governance, retrieval pinado, indexação, embeddings e rotas de conhecimento passou com 61 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A prova Cloudflare do bundle e do índice permanece válida; ingestão operacional/externa ampla, drift documental/externo e o vertical slice Work Permit continuam como expansão.

88. Resultado Arquitetural

Com o PRD-028, o conhecimento deixa de ser simplesmente:

documentação + embeddings

e passa a ser:

                    KNOWLEDGE FABRIC
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
 Documentation        Business State     External Data
        │                  │                  │
        └──────────────────┼──────────────────┘
                           ▼
                     Provenance
                           │
                     Temporal Model
                           │
                    Conflict Detection
                           │
                      HAG / Graph
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
           BM25                    Vectorize
              │                         │
              └────────────┬────────────┘
                           ▼
                    Agent Retrieval
                           │
                           ▼
                     Decision Engine

E surge uma propriedade fundamental:

O agente passa a conhecer não apenas uma informação, mas a origem, validade, autoridade, temporalidade e relacionamento daquela informação.

Isso é essencial para um sistema de SST realmente confiável.

PRD-029 — Agentic Knowledge Governance, Provenance & Trust

O próximo PRD deverá aprofundar uma consequência direta do PRD-028:

como determinar se o conhecimento pode ser confiado?

Teremos múltiplas fontes:

Banco SST
LMS
RH
documentos
usuários
agentes
eventos
APIs externas
LLM

e elas poderão divergir.

O PRD-029 deverá criar uma camada formal de Trust & Provenance, definindo:

Source Authority
Evidence Quality
Data Freshness
Confidence
Trust Score
Conflict Resolution
Source Hierarchy
Evidence Chains
Knowledge Certification
Human Verification
Revocation
Legal/Compliance Provenance

A arquitetura deverá evoluir para:

             KNOWLEDGE
                 │
                 ▼
            PROVENANCE
                 │
                 ▼
          TRUST EVALUATION
                 │
        ┌────────┼────────┐
        ▼        ▼        ▼
     Authority Freshness Evidence
        │        │        │
        └────────┼────────┘
                 ▼
           Trust Decision
                 │
       ┌─────────┴─────────┐
       ▼                   ▼
   Agent Context       Decision Engine

A principal regra será:

O sistema nunca deverá confundir “o modelo acredita nisso” com “o sistema possui evidência suficiente para afirmar isso”.

1. Objetivo​

2. Princípio Fundamental

3. Knowledge Fabric

4. Tipos de Conhecimento

5. Static Knowledge

6. Operational Knowledge

7. Event ≠ State

8. Event Sourcing Não Será Obrigatório

9. Source of Truth

10. Provenance

11. Exemplo de Provenance

12. Temporal Knowledge

13. Bitemporal Model

Valid Time​

Transaction Time​

14. Knowledge Record

15. Knowledge Graph

16. Semantic IDs

17. Knowledge Relationships

18. Wikilinks

19. Knowledge Ingestion

20. Ingestion Sources

21. Documentation Ingestion

22. Code Knowledge

23. Business Knowledge

24. API Knowledge

25. External Knowledge

26. Freshness

27. Freshness Policy

28. Stale Knowledge

29. Automatic Refresh

30. Knowledge Cache

31. Indexing Pipeline

32. Incremental Indexing

33. Change Detection

34. Knowledge Version

35. Decision Reproducibility

36. Knowledge Snapshot

37. Conflict Detection

38. Conflict Resolution

39. Conflict Example

40. Knowledge Confidence

41. LLM Inference

42. Inference Expiration

43. Recommendation Storage

44. User Corrections

45. Correction Workflow

46. Learning Boundary

47. Knowledge Governance

48. Knowledge Lifecycle

49. Revocation

50. Tenant Isolation

51. Global Knowledge

52. Tenant Knowledge

53. Embedding Isolation

54. Cache Isolation

55. Knowledge Access Policy

56. Knowledge Projection

57. Sensitive Knowledge

58. Knowledge-to-Agent Context

59. Knowledge-to-Decision

60. Knowledge-to-Workflow

61. Event → Knowledge

62. Knowledge → Event

63. Knowledge Feedback Loop

64. Loop Protection

65. Knowledge Quality

66. Knowledge Drift

67. Documentation Drift

68. External Drift

69. Knowledge Alerts

70. Search Explainability

71. No Hidden Reasoning

72. Knowledge Cost Optimization

73. Embedding Strategy

74. Chunking

75. Semantic Chunk Metadata

76. Knowledge Bundle

77. Release Integration

78. Rollback

1. Objetivo

Valid Time

Transaction Time

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