Decision Architecture

Decision Architecture começa quando existe objeto suficiente para engenharia: escolha, alternativas, owner, ação, consequência, timing e materialidade. A fase não pressupõe que os dados ou a tecnologia já estejam prontos.

Épicos de referência

C1. Decision Contract

Define pergunta decisória, trigger, alternativas, owner, materialidade, reversibilidade, timing, consequência, critérios e condição de retirada.

C2. Evidência e semântica aplicadas

Vincula evidence products, semantic contracts, freshness, limitations e uso autorizado à decisão específica.

C3. Humanos, agentes, skills e workflows

Desenha papéis, handoffs, interação, contestação, tools e decomposição entre interpretação e execução determinística.

C4. Autoridade, risco e controles

Define autonomy matrix, purpose, scope, budget, TTL, segregation, HITL, four-eyes, rollback, kill e incident ownership.

C5. Ação e observabilidade

Modela action envelope, systems of record, idempotência, telemetry, traces, SLOs, outcome signals e value measurement.

C6. MDC Blueprint

Compila viewpoints, contracts, capability requirements, runtime requirements e gate criteria num blueprint ratificável.

Saídas

Decision Contract, Evidence/Semantic Binding, Human-Agent Operating Model, Authority Matrix, Harness Profile, Observability Contract, Value Contract, MDC Blueprint e MDC Pack Candidate.

Architecture Gate

O Gate verifica coerência entre decisão, evidência, ação, authority, operation e economics. Uma arquitetura tecnicamente executável pode ser rejeitada por ausência de owner, valor observável ou recovery.

Vendor bindings

O blueprint declara capabilities. Technology Runtime Profiles materializam Semantic Views, policies, jobs, agents, APIs, MCP tools ou equivalentes. Trocar binding não deve exigir redefinir a decisão.