Skip to content
Walkthrough

Trust and control

The assistant prepares. The ledger holds.

Approval before an action runs, roles that travel with every request, a ledger that grows by addition, and your own server underneath it all.

  1. Approve
  2. Role
  3. Reverse
  4. Host

The approval gate

The decision comes before the action.

The approval check runs before an action is dispatched, from the action and its arguments. The question goes to the person, every time. A declined request leaves the books exactly as they were, and an approved one runs exactly as shown.

Three gates, one list

  • The host asks the person before dispatch.
  • The router checks every call, including scheduled jobs and scripts.
  • The server applies the same rule to every connected client, and a standard key hands each decision back to the web app.
The approval gate: request, card, run.A request arrives, the card shows the action and every argument to the person, and the action runs once the person approves it.Request01Card02Run03
The approval card listing the award action and every parameter, awaiting a decision.
The approval card listing the award action and every parameter, awaiting a decision.

Two classes

Routine work flows. Decisions wait.

Adding a customer or drafting an invoice runs on your clear request. Posting, cancelling, closing a year, restoring a backup, installing a module and generating a bank file each ask for a second, explicit yes. Keeping the stops rare keeps every card worth reading.

Routine

  • Adding a customer
  • Drafting an invoice

Asks first

  • Posting
  • Cancelling
  • Closing a year
  • Restoring a backup
  • Installing a module
  • Generating a bank file

Roles

Your role travels with every request.

A role is a list of actions a person may run. One permission check serves the dashboard, the assistant and every interface, and the assistant works within the role of the person asking.

One permission check for every surface.The CFO and the Manager Stores each reach the dashboard, the assistant and every other interface through the same permission check, which reads the role of the person asking.DashboardAssistantEvery interfaceCFOManager StoresOne permission check
The CFO's dashboard with its money figures.
The CFO's dashboard with its money figures.
CFO
The Manager Stores' dashboard: stock items, purchase orders awaiting receipt, open orders and warehouses, above the Vendorization and Enquiry to Delivery workflows.
The Manager Stores' dashboard: stock items, purchase orders awaiting receipt, open orders and warehouses, above the Vendorization and Enquiry to Delivery workflows.
Manager Stores

The ledger

A ledger that grows by addition.

Posted entries stay as posted. A correction is a reversing entry, linked to the entry it reverses, and both remain on the record for anyone who reads it.

A correction posts as a reversal, beside the original.The posted entry stays as posted. The reversing entry follows it on the ledger, linked to the entry it reverses, and both remain on the record.Posted entryReversing entryReverses

Shown with ABC Corp, a demonstration company.

The original rent entry and its reversal, side by side in the general ledger.
The original rent entry and its reversal, side by side in the general ledger.

The chain

Each entry vouches for the one before.

Every entry stores a hash of its predecessor. The integrity check recalculates the chain and confirms three things: balance, chain and complete cancellations.

  • Balance
  • Chain
  • Complete cancellations
The integrity check result: the books balance, the chain holds and every cancellation is complete.
The integrity check result: the books balance, the chain holds and every cancellation is complete.

Exact money

Exact decimals, end to end.

Amounts are calculated as exact decimals and stored as text. Every entry balances at the moment it posts. Each document and its ledger lines commit together, in one transaction.

1,234,567.89

Audit trail

From the figure to the document behind it.

Dashboard figures open the lists behind them. Records link to their ledger entries, and stored originals stay on file beside the quotations and orders read from them.

The review panel: the customer's PDF on the left, the values read from it on the right, line by line.
The review panel: the customer's PDF on the left, the values read from it on the right, line by line.

Ownership

Your server, your model, your keys.

Axis runs on infrastructure you choose. The assistant connects to the model you configure, including one hosted on your own network. Talk, the voice, runs through Fish Audio.

Illustration: a server and a model, both your own, joined on the axis line.Axis runs on a server you choose, and the assistant connects to a model you configure, hosted on your own network.Your serverYour model
How deployment works

Talk

The voice speaks. Your press decides.

Talk gives the assistant a voice and keeps every rule in place. A spoken question runs through the same assistant, under the same sign-in, role and approval gate as a typed one. Approval is a press on the card, on screen. Each question and answer stays in the conversation as text, and each action lands in the audit trail with your name.

  • Your identity. The call runs as the person signed in, with that person's role.
  • The same gate. A request that needs approval waits on its card, and Sarah points you to it.
  • A visible call. The call bar shows while the microphone is live, and one press ends the call.
  • One voice service. Speech runs through Fish Audio, and the record stays in Axis.
The voice hands off to an approval card: the caption reads "That's ready for your approval on screen" and the card awaits a decision.
The voice hands off to an approval card: the caption reads "That's ready for your approval on screen" and the card awaits a decision.

Personal keys

A key carries its owner's role, exactly.

Each key belongs to one person and carries that person's role, checked on every call by the same permission check as the dashboard. The key is shown once and stored as a hash. A change to the role reaches every key at once, and disabling the person stops all their keys. Administrators see every key in Users and Roles and can revoke any of them.

  • Standard keys hand decisions back. A posting, an award or a cancellation asked through a standard key goes to the web app, for a person to approve on a card.
  • The wider switch is visible. A key that may confirm those itself is chosen at creation, offered only to roles that hold them, and marked on the key.
  • Every key leaves a trace. Creating and revoking a key are audited, each key shows its last use, and revoked keys stay listed.
The API keys list: each key with its name, expiry, last use and state, one marked as allowing destructive actions.
The API keys list: each key with its name, expiry, last use and state, one marked as allowing destructive actions.
Users and Roles: one person's API keys, each with its last use and a Revoke button for the administrator.
Users and Roles: one person's API keys, each with its last use and a Revoke button for the administrator.

Questions

Questions

  • The approval gate is part of every deployment, for every seat. Roles decide who may act; approval confirms the person means it now.

Have a different question? Write to Saad.Khalid@autosphere.ai