A single module, in detail
Onyx BillS
Local-first legal-billing infrastructure, built for the firm's own work.
The premise
The architecture
The mathematics it is designed around
Every figure on this page is computed by a fixed rule. Sheet A is shipped and carries its line of code; Sheet B is specified-but-not-yet-wired — named as design, with no code mark claimed.
Layer I
Deterministic billing arithmetic
Every billed figure is computed by a fixed, floored rule in minor units.
Time is billed in tenths of an hour. Minutes are floored to a six-minute tenth — never less than one — the gross line is taken in minor units (truncated toward zero, so the firm never over-bills), and any discount is subtracted to a floor of zero. VAT is computed on the rounded base in basis points, then reconciled so subtotal, VAT and total agree to the fil. The whole computation is integer arithmetic on minor units; there is no floating ambiguity to drift, and the result reproduces under recomputation by hand.




Layer II
The tamper-evident ledger
The ledger is append-only; the store refuses edits. Each event hashes the one before it into a chain.
Every event embeds the hash of its predecessor and contributes its own; the sequence, the previous-hash links and the tip hash are all checkable, so any break is detectable. The store blocks mutation outright: immutable SQLite triggers abort update and delete, and the sequence is unique, so the chain cannot fork. Each hash is an HMAC-SHA256 over canonical content under keys derived through HKDF from the vault key, so a record cannot be silently rewritten and re-signed.
Layer III
The exact-token retrieval floor
Search fuses lexical and vector ranking; a floor keeps exact tokens in the results.
Retrieval is hybrid: a reciprocal-rank fusion of a BM25 lexical leg and a brute-force cosine vector leg, with a fusion constant of k = 60 (the active default weights the two legs equally; a protected-retrieval profile weights the lexical leg higher to harden exact-token recall). Above the fusion, a floor holds: under the protected guard, exact tokens — UTBMS codes, clause references, dates, AED amounts, percentages — are pinned into the top results with recall 1.0, so semantic ranking can only add to the floor. The guarantee is enforced as an evaluation gate: a new method must beat the floor with no exact-token regression, measured against a Wilson 95% lower bound alongside Recall@k and nDCG@k.
Layer IV
The cryptographic perimeter
The vault is local and quiet; outbound traffic passes one audited gate.
The default network policy blocks inbound and outbound traffic and ships an empty allowlist — the billing core consults this contract before it ever reaches the network. At rest the database is sealed with SQLCipher, the cipher version checked on open; backups travel in AES-GCM envelopes under an Argon2id-derived key, and vault blobs are content-addressed by a keyed SHA-256 hash. The recovery key is minted once, returned for a printed sheet; the system keeps no copy. An enabled off-device feature routes every send through a single audited gate that refuses secrets, records a payload hash, and fails closed when offline; vault sync itself is opt-in, default-disabled and ciphertext-only.
Layer V
AI that cannot act alone
Classification is rules-first; any model that assists is frozen, gated, and proposal-only. The model proposes a code; a person decides.
Any model that assists is a small, frozen, on-device classifier, trained only on synthetic data. Its corpus is 440 constructed legal narratives across the 22 phases, built with deliberate hard-negatives, so the model learns the shape of the work. A new model is admitted only after it clears an offline evaluation gate bound to its own weight-hash; until those weights are vendored the classifier runs rules-first. In assist mode it scores a suggested UTBMS code by cosine behind a five-clause confidence margin, and below that margin it declines. A draft becomes a record only by passing back through the deterministic workflow with a step-up, leaving conflicts, AML, sanctions and payment outcomes with the operator.


UTBMS activity codes, hash-pinned (A110 is intentionally absent); the 22-phase DIFC/ADGM taxonomy maps to UTBMS L-codes.
Layer VI
Conflicts screened, parties cleared
Every client and counterparty is checked before a matter opens — names matched as keyed tokens — and no engagement proceeds until each party clears.
Conflict screening is deterministic, and runs without a model. Each name on a matter — the client, every co-client, the counterparties, a third-party payer, and any name typed in by hand — is folded to a normalised form and reduced to a keyed token: an HMAC-SHA256 of that normalised string under a key derived from the vault's admin key. Names are compared as tokens, so the screening index can match an alias or a transliteration without storing the name itself. A candidate is scored by the strongest of five signals: an exact normalised match, a keyed-token alias, a script transliteration so a name written in Arabic or Cyrillic meets its Latin spelling, a corporate-group root shared by two different entities, and an edit-distance near-match. Anything at or above 70 is surfaced for a person to clear or block, the reason written to the audit ledger.
Screening is one clause of a wider gate. A matter cannot be engaged until every client on it — the lead and any co-clients — has cleared client due diligence and carries an anti-money-laundering decision scored against a single versioned rubric; sanctions, source-of-funds and the payer are weighed in the same pass. Due diligence and the money-laundering rating are held per client, so a joint matter clears each on its own evidence. Those per-party fields were added as nil-omitting optionals — a record sealed before they existed re-encodes to the same bytes — so the audit chain over older entries still verifies.
Operational proof
Invoices, proformas & controls
The rules hold up on a real invoice.
Invoices are gap-numbered as OL-INV-YYYY-NNNN and, once finalised, carry a re-verifiable SHA-256 economic seal over identity, lines, VAT, subtotal and total — the document attests to its own totals. A proforma advances through separated, audited steps — create, review, approve, finalise — with a step-up before a final invoice issues. Voiding requires a reason; write-offs carry minutes, value, description and an enumerated reason. The billing-item taxonomy is fixed at three kinds: fixed-fee, external-at-cost and disbursement.


At the edge
Biometric unlock & signed pairing
The same local-first guarantees, across devices. A companion joins through a signed pairing ceremony; the running timer shows only a non-secret matter code.
The vault opens by biometrics. Step-up re-authentication is built on one-time proofs that are bound to their target and expire — a proof cannot be replayed, reused, or aimed elsewhere. A companion device joins through a signed pairing ceremony: import an invitation, create a device response, save the signed handoff; the verification code is the first eight characters of a SHA-256 over the pairing secret, responses are HMAC-signed and compared in constant time, and the secret never leaves the Keychain. Capture surfaces show no client identity: the running timer and its Live Activity carry only a non-secret matter code — so a glance at a lock screen can’t reveal who the work is for.



In brief
Questions, answered
What is Onyx BillS?
Onyx BillS (the Onyx Billing System) is local-first legal-billing infrastructure built by Onyx Legal. Every billed figure is computed by a fixed, floored rule in integer minor units, and every consequential action is written to a tamper-evident, HMAC-SHA256 hash-chained audit ledger that admits additions and refuses edits.
Is the AI in Onyx BillS autonomous?
No. AI in Onyx BillS only ever proposes. Classification is rules-first; where a model assists it is a frozen, on-device classifier — trained on a synthetic corpus, no client data — held behind a confidence gate. A suggestion becomes a record only after human review and a step-up, and conflicts, AML, sanctions and payment outcomes are refused outright.
Where is data stored, and does anything leave the device?
Data is stored locally by default. The default network policy is no inbound, no outbound and an empty allowlist; the database is encrypted at rest with SQLCipher and backups travel in AES-GCM envelopes under an Argon2id-derived key. Where an off-device feature is enabled, every send passes a single audited gate that refuses secrets and fails closed when offline.
How is an Onyx BillS invoice verified?
Each finalised invoice is gap-numbered as OL-INV-YYYY-NNNN and carries a re-verifiable SHA-256 economic seal over its identity, lines, VAT, subtotal and total, so the document attests to its own totals.
How does Onyx BillS check for conflicts of interest?
Before a matter opens, every client, co-client, counterparty and payer is screened against the firm's existing clients and matter parties. Names are compared as HMAC-SHA256 keyed tokens — so aliases and transliterations match without the screening index holding a name in the clear — and any candidate at or above the deterministic threshold is surfaced for a person to clear or block, with the reason written to the audit ledger. A matter cannot be engaged until every client clears due diligence and a per-party anti-money-laundering decision.
What platforms does Onyx BillS run on?
Onyx BillS runs natively on macOS, with an iPhone and iPad companion vault. It is built local-first, for a firm's own work.
What is The Vault?
The Vault is Onyx Legal's suite of local-first legal instruments, built for the firm's own practice and not offered for sale. Onyx BillS is its billing module; the suite also includes Onyx ATXE (an evidence workbench) and Onyx LiTT (litigation technology).
