Operational accountability

Rules only work when operations can follow them

Oprivia turns responsibilities, checkpoints, approvals and escalation paths into a visible operating structure.

Decisions remain with the accountable people. The platform shows who is responsible, what must be reviewed and how the case developed.

Abstract governance workspace showing roles, approvals, escalation points and documented decisions around an accommodation case.
Control points for daily operations

Six guardrails before work begins

Governance is not the reaction after something has gone wrong. It defines the operating rules in advance: who may act, what requires review, when an item escalates and which information remains documented.

Responsibility and access

Roles, permissions and visibility are limited to the assigned area of responsibility.

Status and response

Open items, time windows and overdue steps make required action visible early.

Records and evidence

Checklists, feedback, documents and photos remain linked to the relevant case.

Escalation path

Unresolved matters are routed to the responsible function through defined paths.

Change history

Updates extend the record without overwriting earlier processing states.

Operating boundaries

The platform supports control and documentation, but does not replace legal or regulatory assessment.

Segregation of duties

Execution, review and approval stay separate

Governance distinguishes operational execution, factual review and binding approval.

That separation makes clear who provides data, who handles assigned work, who assesses exceptions and who records decisions.

Data capture

Required information is entered by the designated person or role. Control fields remain separate from guest-facing input.

Execution

Assigned work is carried out, updated and supplemented with feedback or records.

Review

Incomplete details, deviations and critical items are assessed by the responsible function before closure.

Approval

Rules, access, escalations and decisions are confirmed by authorised people.

Exception path

Exceptions need a governed route

An open item is not merely captured. It receives a reference point, an accountable function, a review logic and a documented outcome.

01

Classification

Classification

Classify the issue

A request, task or deviation is assigned to the relevant stay, property or assignment.

Abstract workflow showing an open issue assigned to the relevant stay, property or operational assignment.
02

Accountability

Accountability

Assign accountability

An accountable person, processing status and, where required, a time window determine the next step.

Abstract workflow showing a responsible person, processing status and time window assigned to an operational case.
03

Evidence

Evidence

Document the handling

Checklists, feedback, documents and photos are linked directly to the relevant case.

Abstract workflow showing checklists, feedback, documents and photos linked to one operational case.
04

Escalation

Escalation

Route the unresolved item

Missing details, overdue steps or unresolved matters are handed over to the designated function.

Abstract workflow showing unresolved items routed to the designated function through a defined escalation path.
05

Decision

Decision

Record the outcome

The decision, rationale and acting person are documented. The preceding history remains preserved.

Abstract workflow showing a decision, rationale and acting person preserved in the case history.
Audit trail continuity

Changes extend the audit trail

Processing status, checklists, photos, documents and approvals remain linked to the relevant case over time.

New information extends the record instead of hiding earlier states. Critical decisions are made by accountable people, not by the system.

  • Time and acting person remain visible.
  • Records and decisions remain preserved in the case history.
  • Corrections are added, not hidden retrospectively.
Abstract timeline showing updates, records, decisions and corrections preserved as part of a continuous audit trail.
Before activation

Rules are set before operational use

Before activation, the intended use case, responsible roles, data access, review steps and escalation paths are defined.

Operating frame

Properties, modules, roles and responsibilities are limited to the agreed use case.

Data access and instructions

Processing purposes, data categories, permissions, retention and deletion are defined according to the specific setup.

Checklists and response times

Documentation requirements, processing paths and escalation levels are defined before operational use begins.

Configuration and changes

Roles, permissions and control rules are reviewed before activation. Later adjustments remain traceable.

Operating boundaries

Control is supported.
Responsibility remains assigned.

Personal data is processed for the relevant operational purpose. Visibility depends on roles, tasks and agreed access rights.

Oprivia supports process control and documentation, but does not replace legal, data protection or regulatory assessment.

Data minimisation

Process only required data

Only data required for the relevant purpose is processed. Access depends on role and task. Retention and deletion follow the agreed or legally required rules.

Boundary

No transfer of legal responsibility

Oprivia does not provide legal, data protection or compliance advice, regulatory certification or expert case-by-case assessment.

Governance in the pilot

Test control logic on a real case

In the pilot, roles, access, checkpoints, time windows and escalation paths are configured for one defined use case and assessed under real operating conditions.