Request a demo
Menu

Governance

Review what a model change will do before it goes live.

A revised workbook becomes a new version. Approvers see what changes in the API fields, functions and engine, and the results of the promotion’s automated checks. By default, a second person must approve the release. Production accepts changes only through this promotion process.

  1. DevelopmentUpload and try
  2. TestingChecks and approval
  3. ProductionRead-only
Illustrative environments. Each one is configured by an administrator; a version moves one step at a time.

The path to production

One way in, checked at every step.

Each step is a gate of the promotion itself, and the platform offers no other route into a protected environment.

  • Environments you configure

    Set up the environments your process needs, such as development, testing, staging and production, each with its own protection policy and call-history settings. Each API key belongs to exactly one environment, so a key for testing is never accepted in production.

  • Promotion with automated checks

    A promotion request carries a reason, and a ticket ID if you use one. The diff behind it lists inputs, outputs and tables added, removed or changed, with the fields that changed, functions added or removed, and any change of engine. A testbed records a version’s results for a set of cases, and a test run compares another version with them. Planned: test runs as a required promotion check, and impact analysis across a portfolio of cases.

  • Maker-checker approval

    By default a promotion into production needs two people: its author and an approver who is someone else, holds a releasing role and has confirmed their identity within the last ten minutes. Each approval is bound to the exact diff it reviewed, so it cannot be reused for a different change.

  • Read-only production

    A protected environment rejects every direct change, from administrators too. The rule is enforced at two separate layers.

Switching and recovering

Atomic switches, simple rollbacks.

A new version takes over in one step, and going back is the same governed step in the other direction.

  • Atomic switch and rollback

    Before the switch, XSheet starts the new version and checks it with a smoke test. If that check fails, nothing changes and the current version keeps answering. The switch happens in a single step, and each call is answered entirely by one version. Rolling back is a promotion of a previous version, with the same checks and record.

  • Break-glass for emergencies

    To stop a service, one releaser requests the action with a written reason and another approves within 30 minutes. A releaser then explicitly executes the approved action within 15 minutes. The service stays off until an approved enable action is executed or an approved promotion explicitly re-enables it. Every step is recorded in the audit log.

Evidence

A record that can be verified.

Each change and each call leaves a record that audit and model-risk reviewers can check for themselves.

  • A tamper-evident audit log

    Every change is appended to a tamper-evident audit log. A verification command checks the whole log and names the first point where the log was changed. Personal data is kept outside the log’s hash chain, so it can be anonymized when its retention ends without breaking the proof.

  • A receipt for every recorded call

    Each recorded call has its request ID and a receipt naming the version, the exact build and, where used, the decision-table row and transforms behind the result. While the inputs are retained, the call can be replayed bit for bit. After that, the receipt remains as evidence.

Questions

What release and audit teams ask.

Can a small team release with one person?
Yes, if it chooses solo mode when XSheet is installed. The author then confirms their own promotion with a fresh identity check. Going from two people to one later needs an approved request, or an operator command when no other releaser is active, and the change is audited.
What happens when a check fails?
The promotion request stops with the reasons, and nothing changes in the target environment. The author can run the checks again.
What if the switch itself fails?
Production keeps the current version. A failed start or smoke test leaves everything as it was and returns the request to its approved state. After the third failed attempt, the request fails and a new one is needed.
Do approvals expire?
An approval lapses when its request expires after 72 hours. An approver’s identity check may be at most ten minutes old when they approve.

See how your model would work as an API.

Discuss the workbook your team maintains and the applications that need its results. Explore integration and deployment in your environment.

Request a demo Deployment