Security

What holds, and what enforces it.

Siringo reads from the systems a hotel already runs and writes an independent record of what they did. That is a credential and a trust boundary, so this page states exactly what the software enforces, what enforces it, and what this product does not yet claim. Nothing below is aspirational; where something is not true today it is in the last section rather than absent.

• Tenant scope is derived on the server

  Every tenant-owned row carries an organization id. Scope is applied from the authenticated session on the server and is never read from a request parameter, a header or a client-supplied body. A record belonging to another organization answers 404 rather than 403, because a 403 confirms that the record exists.

  organization_id on every tenant table · repositories take a server-derived scope and issue no unscoped query · row-level security as a fail-closed backstop

• Evidence, audit and finalized verdicts are append-only

  The role the application runs as can read and insert these records. It cannot update or delete them. A verdict cannot be quietly improved after it is finalized, and an audit entry cannot be removed by the code path that wrote it.

  database triggers refusing UPDATE and DELETE on evaluation, evaluation_dimension and evidence_item · runtime grants are SELECT and INSERT only

• Redaction removes content and keeps the record of it

  The one exception to append-only is authorized redaction, and it is stated here rather than omitted. It runs through a single privileged function the runtime role may execute: the payload is cleared, the content hash is kept, and a tombstone is written. The evidence is gone; the fact that it existed, and what it hashed to, is not.

  a SECURITY DEFINER function, executable by the runtime role and by nothing else · the hash and the tombstone survive the payload

• A published contract is frozen and digested

  A workflow contract is sealed on publication as a canonical snapshot with a SHA-256 digest. Every transaction locks the version and digest it was judged under and is evaluated from that snapshot, so a verdict from last quarter still means what it meant then even if the contract has since been republished.

  digest over a canonical form · version and digest locked per transaction · UPDATE on both columns revoked from the runtime roles

• Nobody approves their own action

  A high-risk action cannot be approved by the actor that raised it. There is no configuration flag to relax this, because a control with an off switch is a preference. Approvals are bound to the digest of one exact action and are spent on first use: an approval does not carry to the next action, nor to an altered version of the same one.

  approval records bind the action digest and are single-use · the raising actor is excluded at the authorization path, not in the interface

• Overrides are permitted and never silent

  Operations sometimes require overriding a control, and refusing that outright produces a system people work around. Overriding one unobserved is the thing that is refused. Each override is written to the audit trail with who did it, when, and against which action.

  every override writes an audit entry on the same append-only path as the rest

• Execution and outcome need an independent read

  Where a contract requires the Execution or Outcome dimension, it passes only when a connector re-reads a distinct system of record and finds the change present — or when the contract itself states, in writing, why there was nothing to read back. The acting system’s own report of success is that system’s claim, and the evaluator does not consume it.

  connector.verifyMutation() against a system of record distinct from the one that acted · a caller-supplied verified flag is discarded