Publication and reconciliation
How a revision becomes tuples in OpenFGA, and how Xokepoint repairs drift without ever widening access.
Publication writes to two places, PostgreSQL and OpenFGA, and no transaction covers both. One write can fail after the other. The rule behind the design is that a failure can leave less access, never more.
Publication
PostgreSQL is the source of truth. The PAP computes the tuple difference between the previous revision and the new one, deletes first and writes after. If the write fails, the deletes already applied stay, and the agent has at most the access that both revisions share. The new revision becomes effective only when OpenFGA confirms. Meanwhile, the conditions of the previous revision still apply.
Reconciliation
Partial failures, interrupted publications, backup restores or a defect can leave OpenFGA different from PostgreSQL. A background reconciler repairs this on its own, with no manual work in the Admin.
The target is always the latest published revision, never an older one. If the reconciler targeted the effective revision, it could recreate a relation that a newer publication just removed. The delete-then-write order applies here too.
Only the backend writes to OpenFGA, and only after validation. The Admin never writes tuples. Each repair is logged with agent, revision and number of tuples changed, without the tuple contents.