Publicação e reconciliação
Como uma revisão vira tuplas no OpenFGA, e como o Xokepoint corrige divergências sem nunca ampliar acesso.
A publicação escreve em dois lugares, PostgreSQL e OpenFGA, e não há transação que cubra os dois. Uma das escritas pode falhar depois da outra. A regra que guia o desenho é que uma falha pode deixar acesso a menos, nunca a mais.
Publicação
O PostgreSQL é a fonte da verdade. O PAP calcula a diferença de tuplas entre a revisão anterior e a nova, apaga primeiro e escreve depois. Se a escrita falha, as remoções já aplicadas ficam, e o agente tem no máximo o acesso que as duas revisões têm em comum. A revisão nova só vira efetiva quando o OpenFGA confirma. Enquanto isso, as condições da revisão anterior continuam valendo.
Reconciliação
Falhas parciais, publicações interrompidas, restauração de backup ou um defeito podem deixar o OpenFGA diferente do PostgreSQL. Um reconciliador em segundo plano corrige isso sozinho, sem trabalho manual no Admin.
O alvo é sempre a última revisão publicada, nunca uma anterior. Se o reconciliador mirasse a revisão efetiva, poderia recriar uma relação que uma publicação nova acabou de remover. A ordem apagar-depois-escrever vale aqui também.
Só o backend escreve no OpenFGA, e só depois de validar. O Admin nunca escreve tuplas. Cada correção é registrada com agente, revisão e número de tuplas alteradas, sem o conteúdo das tuplas.