Um único método, do primeiro depoimento à entrega à direção
A RISKOPILOT segue a cadeia de raciocínio Tripod Beta de ponta a ponta: o relato do incidente torna-se uma base factual, a base factual torna-se uma árvore de causalidade, a árvore expõe as barreiras que falharam e as barreiras apontam as condições organizacionais que permitiram essa falha. Nada consta do relatório sem estar ligado a uma evidência.
Uma investigação é moldada pelo que é registado nas primeiras horas. A recolha recebe o relato bruto — depoimentos, registos de turno, permissões de trabalho, fotografias, histórico de alarmes — na língua em que chega e guarda-o como material de origem, não como conclusão.
Cada item carregado torna-se um objeto citável com origem, data/hora e responsável. Os capítulos seguintes só podem afirmar algo se conseguirem remeter para um desses objetos.
CAPÍTULO 02
Base factual — separar o que aconteceu do que se acredita
Os depoimentos são decompostos em factos distintos, cada um classificado como observado, registado, inferido ou contestado. Inferir é permitido; disfarçar inferência de observação não é.
As contradições entre fontes permanecem visíveis em vez de serem resolvidas em silêncio, para que a análise possa ser verificada por quem ler o relatório mais tarde.
CAPÍTULO 03
Árvore Tripod — construir a cadeia de causalidade
A base factual é organizada na estrutura Tripod Beta: agente de dano, objeto e o evento que os liga, seguidos da cadeia de falhas ativas, pré-condições e condições latentes por trás de cada uma.
A árvore é um artefacto de raciocínio, não um exercício de diagramas. Cada nó traz a sua referência de evidência e a sua classificação, e o painel abaixo mostra as superfícies de análise geradas a partir dela.
ARTEFACTOS DE CAUSALIDADE — CASO R-2847EXPORTAR DADOS
Árvore Tripod Beta, caso R-2847: o agente (a gravidade, trabalho em altura) atinge o objeto (um operador em plataforma de andaime) através de duas barreiras falhadas — verificação antiqueda e reposição do guarda-corpo — produzindo o evento, uma queda de altura de 8 m. Cada barreira falhada remonta a uma causa imediata, uma pré-condição e uma causa organizacional subjacente.
CAUSA SUBJACENTESem verificação antiqueda no procedimento de permissão de trabalhoPR · PROCEDIMENTOS
PRÉ-CONDIÇÃOPassagem de turno apressada — autorização verbalCO · COMUNICAÇÃO
CAUSA IMEDIATACinto não ligado a um ponto de ancoragemDECLARAÇÃO W-03
AGENTEGravidade — trabalho em altura (8 m)
OBJETOOperador em plataforma de andaime
EVENTO-AGENTEOperador exposto na borda desprotegida
EVENTOQueda de altura · 8 m
B1 · FALHADAB2 · FALHADA
CAUSA SUBJACENTESem etapa de reposição do guarda-corpo após as elevaçõesMM · MANUTENÇÃO
PRÉ-CONDIÇÃOGuarda-corpo retirado para a elevaçãoFOTO E-09
CAUSA IMEDIATABorda desprotegida aberta no acessoFOTO E-09
FALHADAVerificação antiquedaAutorização verbal 2 min antes da subida, sem controlo registado — cronograma STEP T+5 min
Caso R-2847 na gramática Tripod Beta padrão: o evento ocorre quando o agente (a gravidade) atinge o objeto (o operador) através de barreiras falhadas. Cada barreira falhada remonta a uma causa imediata, uma pré-condição e uma causa organizacional subjacente. Clique numa barreira.
CAPÍTULO 04
Barreiras — testar cada controlo que devia ter resistido
Para cada trajetória do evento, os controlos que deviam prevenir ou limitar o resultado são nomeados e recebem um estado: intacto, falhado ou ausente. Um controlo não pode ser dado como intacto por existir no papel — tem de ser demonstrado nas evidências.
O bow-tie abaixo é o mesmo explorador usado no produto. Selecione uma barreira para ver o seu estado e a citação de evidência que o sustenta.
FIG.01 — ANÁLISE BOW-TIECASO R-2847 · GRAVIDADE 4 · AO VIVO
AUSENTEVerificação da permissão de trabalhoPermissão PTW-114 emitida sem a assinatura conjunta do supervisor — Declaração S-02, p.1 lin. 8
INTACTAFALHADAAUSENTEClique numa barreira — cada estado remete para uma evidência
CAPÍTULO 05
Perfil GFT — ler a organização, não o indivíduo
Cada barreira falhada ou ausente é ligada aos fatores de risco de base que a explicam, pontuados nos onze General Failure Types: projeto, equipamento, gestão da manutenção, procedimentos, condições que induzem erro, arrumação e limpeza, objetivos incompatíveis, comunicação, organização, formação e defesas.
O perfil transforma um incidente isolado numa afirmação sobre o sistema de gestão — é isso que o torna comparável entre casos e útil para a direção.
CAPÍTULO 06
Conclusões — recomendações que resistem ao terreno
As recomendações são geradas por barreira fraca e por tipo de falha dominante, e escritas segundo a hierarquia de controlos: eliminação e substituição antes da engenharia, engenharia antes do administrativo, administrativo antes dos equipamentos de proteção.
Cada recomendação indica a barreira que repara, o tipo de falha que trata e a evidência que a justifica, para que o argumento de fecho continue auditável anos depois.
CAPÍTULO 07
Entrega — um relatório útil para a direção e para o regulador
A entrega inclui um relatório de investigação completo, uma nota para a direção e as figuras subjacentes, em inglês, francês, espanhol ou português, gerados a partir de uma única análise para que as versões não possam divergir.
As evidências permanecem no seu espaço de trabalho. Os relatórios são exportáveis, a retenção é configurável e cada acesso é registado para a trilha de responsabilização.
APROFUNDAMENTOS
Os quatro métodos por trás do percurso
Cada capítulo apoia-se num método publicado. Estas páginas expõem a fonte, os passos e os limites de cada um.