Registro de perigos

Um perigo é algo que pode dar errado no seu sistema, escrito com quem é responsável e o que o mede. O registro fica ao lado da política de lançamento, em hazards.yaml, então é revisado em pull requests como o resto do projeto, e cada execução registra a versão com que foi lido.

Escrevendo o registro

version: 1
hazards:
  - id: rag-leak
    title: A poisoned document makes the assistant disclose a customer's data
    systems: [support-bot]
    triggers: [a retrieved document carries an instruction]
    exposed: customers whose tickets the assistant reads
    severity: {level: 5, narrative: customer data leaves the company}
    occurrence: {level: 2}
    detectability: {level: 3}
    controls: [retrieved text is quoted, never obeyed]
    residual: Low while the leak ceiling holds; reviewed after every model change.
    owner: [email protected]
    review_by: 2026-12-01
    state: open
    measured_by: [no-leak]
    tested_by: [safety]

Cada perigo nomeia em measured_by as regras que o medem. Elas devem ser tetos do release.yaml: uma regra max: ou uma regra max_failures: (Tetos de risco). Um piso mede com que frequência algo dá certo, então um perigo medido por um piso é recusado. systems e tested_by restringem de quais sistemas e suítes a evidência é lida; se ausentes, todos contam.

Gravidade, ocorrência e detectabilidade são as notas ordinais de uma análise de modos de falha e efeitos, de 1 a 5, dadas por pessoas. O Oloproof as mostra como foram dadas e nunca as combina: não há número de prioridade de risco nem pontuação de risco residual, porque o produto de notas ordinais é uma precisão que ninguém mediu. O risco residual é a frase do responsável. O state de um perigo (open, mitigated, accepted ou closed) é da equipe, nunca uma decisão.

Verificando

oloproof hazards check

A verificação recusa um registro cujos perigos nomeiam uma regra que a política não tem, ou um piso, e termina com 2. Caso contrário, lista cada perigo com suas notas, responsável e estado, avisa de uma revisão vencida e lê cada regra de medição na última execução de cada sistema em cada suíte, como o motor a decidiu. Um perigo sem regra de medição aparece como não medido, e uma regra que nenhuma última execução decidiu é nomeada. --json escreve o mesmo relatório para um pipeline.

Onde aparece

oloproof run registra o registro com a execução, oloproof push o leva ao seu espaço de trabalho e oloproof export o escreve ao lado dos bundles que uma bancada local lê. A página Safety and risk mostra cada perigo acima dos tetos, com notas, controles e o estado dos tetos que o medem, cada um ligado à sua evidência. Quando um registro de perigos mudou e voltou atrás, o atual é o registro que a execução mais recente registrou, não o último escrito. Um registro de decisão nomeia o registro de perigos que a sua execução registrou; record verify o apresenta como a palavra da equipe.

Próximos passos

• Tetos de risco cobre as regras que medem um perigo.
• Gating cobre como um teto bloqueia um lançamento.