3 · Conceitos¶
Este capítulo define as palavras que o resto do guia usa para a verificação, um parágrafo para cada uma. Depois deste capítulo, cada palavra significa exatamente o que diz aqui, e uma página que a usa aponta de volta para cá.
Política¶
Uma política é o arquivo de regras que um guardrail executa: quais ações uma conversa pode alcançar, e sob que condições. A verificação lê políticas escritas em Colang 1.0, a linguagem do NeMo Guardrails, e um subconjunto declarado do Colang 2.x. Uma planilha de regras (rule sheet) é o mesmo tipo de regra escrito em YAML (capítulo 41), compilado na mesma forma antes que qualquer coisa o leia.
Rulebook¶
Um rulebook é uma política tal como um agente roda sob ela: as regras contra as quais cada chamada
de ferramenta é verificada. O rulebook: de um agente é um arquivo Colang ou uma planilha de regras, e o
serviço o compila no registro que a verificação de ferramentas aplica
(capítulo 45).
Ação¶
Uma ação é algo que uma política deixa uma conversa fazer acontecer: uma mensagem do bot, ou uma
chamada de ferramenta como execute_transfer_funds. A verificação pergunta sobre uma ação de cada vez.
Contexto¶
Um contexto é um fato sobre a conversa que uma política consulta antes de agir, escrito como uma
variável: $is_authenticated, $supervisor_approved. A política o lê; algo fora da política, como os
seus sistemas de registro, o define. A verificação trata todo contexto como livre para assumir qualquer
um dos dois valores, e é isso que deixa uma resposta cobrir todas as situações de uma só vez.
Obrigação¶
Uma obrigação é a pergunta que a verificação responde: esta ação pode disparar enquanto este
contexto é falso? Ela é um par, uma ação e o contexto sem o qual ela nunca pode disparar, como
execute_transfer_funds e is_authenticated. Uma execução decide uma obrigação, e nada mais
(capítulo 4).
Pin¶
Um pin fixa uma variável em 0 ou 1 para a pergunta, de modo que a obrigação só seja feita nas
situações de que ela trata. Uma resposta de alto risco deve trazer um aviso de risco, para este tipo de
produto é a obrigação respond with high risk answer / risk_warning_given, com o pin
product_is_nmmi=1. Uma obrigação condicional feita sem o seu pin pergunta sobre situações que a regra
nunca cobriu, e a resposta não significa nada (capítulo 4).
Veredito¶
Um veredito é a resposta, e é um de três:
UNSAT: nenhuma situação faz a ação disparar com o contexto falso. A obrigação vale, sobre todas as combinações de entradas de uma só vez.SAT: existe uma situação, e o veredito a nomeia. A obrigação está quebrada.STALL: a execução não conseguiu decidir, um impasse. Do lado dos guardrails, ele é tratado comoSAT; do lado das random forests, ele não conclui nada.
O que cada um deles não significa está no capítulo 6.
Certificado¶
Um certificado é um documento JSON que registra por que as equações de uma pergunta não têm
solução, passo a passo, para que qualquer pessoa possa conferi-lo sem o nosso software. Ele vem com um
veredito UNSAT quando o perfil constrói um (capítulo 7).
Patch¶
Um patch é o reparo que o motor propõe para uma obrigação quebrada ou indecisa: uma condição, escrita com os próprios nomes da política, acrescentada a cada fluxo que chega à ação. Ele vem com uma prova de que a política reparada descarta o resultado (capítulo 8).
Perfil¶
Um perfil é uma configuração nomeada do motor, escolhida a cada requisição. Ele decide quais fases
rodam e, portanto, o que a resposta pode afirmar: fast decide em cerca de um quarto de segundo e não
constrói certificado; patch constrói um reparo e um certificado; proof, enumerate e forest servem
aos propósitos que os seus nomes dão (capítulo 10).
Orçamento¶
Um orçamento é o tempo que uma execução pode gastar: um para a resolução inteira, e um para a busca de um reparo. Uma execução que esgota o seu orçamento diz isso, e o que ela ainda devolve está dito no capítulo 10.
Diagnósticos¶
Os diagnósticos são o que o compilador diz sobre uma política que ele não conseguiu ler inteira: uma linha que ele pulou, uma construção que ele não trata. Um veredito sobre uma política com diagnósticos de análise ao alcance da pergunta é nulo (capítulo 6).
Job, modo e operandos¶
Toda verificação é um job: uma requisição a POST /v1/solves que nomeia um modo (guardrail,
batch, graph, hunt, forest e os demais), os seus arquivos de entrada e os seus operandos, os
campos que não são arquivos, como a ação e o contexto. Um job roda nos nossos servidores e é lido,
acompanhado ou cancelado pelo seu id (capítulo 9). Os modos estão listados na
referência gerada.