NSpec

A especificação pronta para implementação.
Um artefato. Cada player.

O NSpec alinha vendors, compras e entrega em uma única fonte de verdade. Os vendors estimam a partir dele. As organizações comparam propostas em relação a ele. As implementações começam com ele.

Sete conteúdos canônicos.

Cada pacote NSpec especifica as mesmas sete coisas — a estrutura que faz estimativa, comparação e entrega funcionarem sobre evidências compartilhadas.

01
Escopo
Qual trabalho o agente está autorizado a executar, no que ele não deve tocar e como o escopo é governado quando a realidade operacional diverge do plano. O envelope operacional do agente.
02
Unidades de Trabalho
As tarefas operacionais atômicas que o agente executa — cada uma dimensionada individualmente, com dependências mapeadas e testável. O contrato do agente em nível de tarefa.
03
Sistemas
As aplicações, fontes de dados e plataformas com as quais o agente interage. Versão, responsável e restrições de acesso especificados para que o alcance do agente seja inequívoco.
04
Integrações
Os conectores, APIs e fluxos de dados que o agente usa para agir. Cada integração tem um protocolo conhecido, um responsável conhecido e um modelo de autenticação conhecido — o caminho do agente para os sistemas operacionais.
05
Riscos
Riscos operacionais, regulatórios e relacionados à autonomia que o agente introduz. Cada risco tem uma probabilidade, um impacto e um responsável pela mitigação. O registro de riscos do agente.
06
Limites de Autonomia
Para cada unidade de trabalho: o que o agente faz de forma autônoma, o que requer revisão humana, o que dispara escalação. O contrato de autoridade do agente — explícito, auditável e exigível pelo Evidence.
07
Critérios de Aceitação
Outcomes mensuráveis que o agente deve produzir para ser considerado bem-sucedido. Binário ou quantificado — nunca narrativo. O contrato de aprovação/reprovação do agente, validado continuamente pelo Evidence.

Vendors estimam a partir do NSpec.

Sem uma especificação compartilhada
Cada vendor estima conforme a própria interpretação do RFP. As propostas inflam para cobrir incertezas. As comparações são subjetivas. A seleção muitas vezes se resume a relacionamento, não a adequação. O comprador acaba pagando pela ambiguidade.
Com o NSpec
O NSpec especifica as unidades de trabalho, os limites de autonomia, as restrições de integração e os critérios de aceitação — antes mesmo de o vendor ver a solicitação. Os vendors estimam contra o mesmo artefato. As propostas são devolvidas em estrutura compatível com NSpec. O excesso fica visível. A adequação fica mensurável.

As compras funcionam sobre evidências, não sobre pitch.

1
Mesmo artefato, todos os vendors
O NSpec vira o RFP. Distribuído de forma idêntica. Cada vendor vê o mesmo escopo, as mesmas unidades de trabalho, os mesmos critérios de aceitação.
2
Propostas comparáveis
Propostas devolvidas em formato compatível com NSpec. Custo detalhado por unidade de trabalho. Abordagem mapeada para limite de autonomia. A comparação deixa de ser subjetiva.
3
Seleção pela spec
Os critérios de decisão são explícitos. Os vendors são avaliados pela spec, não pelo slide deck. As compras ganham um raciocínio defensável. A entrega ganha o parceiro certo.

A entrega funciona contra o mesmo artefato.

1
Kickoff
O NSpec é o SOW. O time de implementação se alinha no mesmo artefato contra o qual a proposta foi estimada.
2
Marcos
As unidades de trabalho viram entregáveis. Cada unidade de trabalho é entregável de forma independente, testável de forma independente e aprovada de forma independente.
3
Aceitação
A aprovação é binária em relação aos critérios de aceitação. Sem reinterpretação, sem ambiguidade de scope-creep, sem disputas do tipo "entregamos o que você realmente quis dizer".
4
Repasse
A implementação repassa para operações contra o mesmo NSpec. O contrato é o artefato, do kickoff à produção.

Quer ver o NSpec na prática?

Torne-se um Design Partner. Faça um Discovery. Veja o seu primeiro NSpec.

Torne-se um Design Partner →