PoCE & Compliance — Cryptographic Audit for Hotel Operations

Status: Compliance & Audit Specification
Sources: Core Subsystem → PoCE Bridge Architecture, Proof of Correct Execution (PoCE), Cross-Organization Federation & Federated PoCE Specification, docs/platform-map/system/S-142-SCOPE-GOVERNANCE.md, Playbook Engine Architecture & Runtime Execution Model §3

1. Proof of Correct Execution (PoCE) for Hotels

Every critical hotel state transition executes through a PoCE Session (s131-s150), producing a self-contained cryptographic audit receipt containing every step, signature, evidence hash, and timestamp. Any external auditor or arbiter can verify the receipt offline against the public keys of the involved parties — without access to internal hotel databases.

PoCE session lifecycle:

fn::lifecycle::start_poce_session(event_type, entity_type, entity_id, scope_id, governance_path_spec_id, actor_id, metadata) — resolves governance path spec, starts session, records poce_session_id
fn::lifecycle::record_poce_step(session_id, stage_id, rule_ids, input_hash, output_hash, meta) — wraps fn::poc::append_step
fn::lifecycle::finalize_poce_session(session_id, result_claim_id, result_hash, issuer_id, subject_id) — wraps fn::poc::finalize_receipt
fn::lifecycle::emit_poce_stage_event(session_id, stage_id, event_status, metadata) — routes stage completion to NATS JetStream poce.v1.stage.> via NATS Outbox

2. Hotel PoCE Trigger Points

Hotel Transition	PoCE Trigger	Steps Recorded
Guest check-in	lifecycle event (`on_user_created`)	ID verification, room assignment, receptionist signature, payment method
Housekeeping clean sign-off	`record_poce_step`	attendant, checklist items, photo hash, inspector, timestamp
Maintenance completion	`record_poce_step`	technician, parts consumed, OpenMAINT close, expert sign-off
Folio adjustment above tier	`fn::poce::record_step`	approvers, quorum threshold, dual-custody signatures
PO approval (procurement)	`fn::poce::record_step`	approver roles, amount band, evidence attachments
Event settlement / escrow release	`fn::poce::finalize_session`	client sign-off, delivery verification, payment authorization
Group procurement award	federated PoCE	multi-property quota signatures, BBS+ attestations, escrow lock/release
Incident escalation	`record_poce_step`	severity, responder, escalation approvals, evidence
Guest identity / BBS+ proof	lifecycle event	credential proof, verifier, selective disclosure fields

3. Separation of Duties (SoD) & Quorum

Declarative SoD and quorum values live in NATS JetStream KV lookups (never hardcoded):

lookup.claims.sod.v1 — separation-of-duties rules by claim type. Example: forbid_creator: true (creator cannot approve their own claim); dual_control with forbid_pairs (specific user pairs cannot both sign).
lookup.claims.threshold.v1 — quorum thresholds by claim type (standard: min_approvals 1, two_person: 2, three_person: 3, cross_agency: 3, assembly: 3).
lookup.claims.threshold.procurement.v1 — amount bands × risk band → named quorum + approver roles.

Hotel application:

Housekeeping sign-off: cleaner ≠ inspector (SoD); min_approvals: 1 inspector
Folio adjustment above TIER_2: two_person quorum (e.g., F&B manager + finance controller)
PO approval: tier-based quorum with named approver roles (procurement officer, executive chef, finance director)
Incident escalation: human approval at each ladder step (security desk → GM → regional safety office)

Guard rails: No auto-approval; no auto-certify; no auto-fine; bands are data, resolver never defaults — missing band refuses.

4. Compliance Gates (s350)

Declarative compliance gates register stages and evaluate events:

fn::compliance::register_gate(gate, stages) — define a compliance gate with ordered stages (e.g., "Health & Safety Inspection", "Fire Safety", "Food Hygiene", "Accessibility")
fn::compliance::evaluate_gate(gate_id, event_type, entity_id, payload, correlation_id) — evaluate an event against a gate
fn::compliance::record_eval(eval_id, stage_id, status, violations, duration_ms) — record evaluation result
fn::compliance::advance_stage(gate_id, current_stage_id) — advance gate stage
fn::compliance::match_gate(event) — match an incoming event to applicable gates
fn::compliance::list_gates(domain) / get_gate_evals(gate_id, entity_id, limit) — query

Hotel compliance gates:

Health & safety inspection (food hygiene, kitchen)
Fire safety inspection (fire alarms, extinguishers, egress)
Accessibility inspection (ramps, signage, room access)
Building safety inspection (large buildings — building-safety-inspections.scenario.json, seven-stage chain: scheduled → fire → accessibility → hygiene → expert sign-off → certificate → packet export)
Data privacy / guest identity (BBS+ selective disclosure, key rotation)

Guard rails: Expert sign-off mandatory for certificates; no auto-certify; no auto-fine; expiry watches re-schedule next inspection.

5. Record Federation (s184) — Multi-Property & Cross-Organisation

For hotel groups and cross-organisation contracts (group procurement, event clients, insurance):

cns_federation_policy — which CNS schemas may cross property/org borders
record_federation_binding — binds a local record to an authorized peer scope (READ_ONLY / COLLABORATIVE, BIDIRECTIONAL)
record_federation_event — immutable audit ledger of cross-tenant actions
Fields on claim, truth_node, truth_edge: is_federated, federation_scope, federation_mode, federation_policy

BBS+ selective disclosure: An organisation proves participation validity (e.g., "our property authorized 15,000 units at price X") while cryptographically redacting internal member lists and margins.

Keycloak DID linking: Each organisation identity anchored to a Keycloak realm and DID; cross-tenant calls pass X-Sovereign-DID-Proof header.

6. Scope Governance & Authority (s142)

Datalog-based delegation chain authorization:

fn::authority::root_authorized / fn::authority::verify_chain (10-hop bounded unroll)
fn::authority::delegate / fn::authority::cascade_revoke
fn::scope::join_scope
15 invariant check functions fn::invariant::check_*; recovery functions sweep_orphans, sweep_expired, request_root_transfer/approve_root_transfer

Hotel application: Property manager delegates approval authority to department heads; regional office delegates to property GMs; revocation cascades. All delegation chains are auditable and bounded.

7. Security Essentials (s146)

Session context, MFA factors, encryption keys, security audit log, login attempts
fn::security::log_audit_event, fn::security::record_login_attempt, fn::security::check_login_rate_limit
Front desk and engineering staff sessions audited; MFA for finance/admin roles

8. Compliance Claims We Can (and Cannot) Make

Can claim (with evidence):

Cryptographic audit receipt for every state transition (PoCE)
Separation of duties enforced via declarative KV lookups
Quorum-based approvals with named approvers
Immutable cross-property federation audit ledger
BBS+ selective disclosure for guest identity proofs
Fail-closed behavior when external peers are unavailable

Cannot claim (honesty limits):

No specific uptime or savings percentage until a baseline is measured
No autonomous escrow release or autonomous dispatch (machines propose, rules dispose)
No PHI/system-of-record for medical clinics (non-goal)
No FedRAMP High / FIPS-validated crypto (target non-federal, non-PHI paths)

9. What to Ask Us Next (Compliance)

Which compliance gates (health, fire, accessibility, building safety) are in scope for the pilot property?
Who holds the approved register and who taps "approve" on each award (naming the propose-vs-dispose line)?
Which guest identity proofs (age, nationality) require BBS+ selective disclosure, and which jurisdiction's data rules apply?
What is the maximum acceptable downtime for a housekeeping or maintenance SLA, and which properties may choose a faster promise?