Rastreabilidade e versionamento

A rastreabilidade é a infraestrutura de memória do método. Ela impede que decisões, releases e resultados sejam interpretados fora do contexto que os produziu.

Trace mínimo

Signal/Demand
→ Project
→ Epic
→ Practice/Workflow/Task
→ Artifact/Evidence
→ Gate Decision
→ State Transition
→ Capability Release ou Live Configuration
→ Operation/Event
→ Outcome
→ Learning Candidate

Identidade

Objetos persistentes recebem ID estável e versão. Nomes podem mudar; IDs preservam relação histórica. O método recomenda IDs legíveis por classe, mas não impõe banco ou ferramenta específicos.

Versionamento

• Core segue Semantic Versioning.
• Módulos declaram faixa compatível do Core.
• Práticas, schemas e manifests possuem versão própria.
• Artefatos de tenant possuem versão e status.
• Mudanças breaking exigem migration note.
• Documentação e ativos executáveis compartilham release ID quando descrevem a mesma capability.

Proveniência entre repositórios

Trace não depende de monorepo. Releases devem registrar commit, hash, assinatura, SBOM quando aplicável, registry, dependências e binding usado. Um Capability Release pode ser consumido por vários MDC Packs ou projetos sem copiar sua identidade.

Status truthfulness

SPECIFIED → PROTOTYPE → AVAILABLE → DEPRECATED → RETIRED

Um ativo só muda de status com evidência definida. AVAILABLE exige distribuição ou operação verificável, documentação mínima, owner e caminho de suporte. A documentação pública deve diferenciar o que existe do que está planejado.

Auditoria e retenção

Retenção é proporcional a materialidade, regulação e valor de aprendizagem. Logs técnicos não substituem Decision Trace; Decision Trace não precisa replicar todos os logs. O objetivo é preservar cadeia causal e de autoridade suficiente para revisão.