A single module, in detail
Onyx BillS
Cutting-edge legal-billing infrastructure — built local-first, for the firm's own work.
The premise
The architecture
The mathematics it is designed around
Every figure on this page is computed by an explicit 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 an explicit, 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. Value-added tax is computed on the rounded base in basis points and reconciled so the minor-unit residuals of subtotal, VAT and total all agree. 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
Records are appended, never edited. 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 truncation of the tip are all checkable, so any break is detectable rather than assumed. 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 guarantees exact tokens are never lost.
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 may only add on top of the floor, never regress it. 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
By construction the vault is local and quiet — and where it does reach out, it does so through one audited gate.
The default network policy is no inbound, no outbound, and 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, and never persisted, logged, or written to the audit chain. Where an off-device feature is enabled, every send passes 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; where a model assists it is frozen, gated, and proposal-only. The model proposes a code; a person decides.
Where a model assists, it is a small, frozen, on-device classifier — no cloud, and no client matter in its training. Its corpus is synthetic: 440 constructed legal narratives across the 22 phases, built with deliberate hard-negatives, so the model learns the shape of the work without ever seeing a real client. 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, adding nothing it cannot prove. When it does assist, it scores a suggested UTBMS code by cosine behind a five-clause confidence margin and, below margin, declines rather than guesses — and it only ever proposes: a draft becomes a record solely by passing back through the deterministic workflow with a step-up, with conflicts, AML, sanctions and payment outcomes refused outright.


UTBMS activity codes, hash-pinned (A110 is intentionally absent); the 22-phase DIFC/ADGM taxonomy maps to UTBMS L-codes.
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: three kinds — fixed-fee, external-at-cost and disbursement — and no more.


At the edge
Biometric unlock & signed pairing
The same local-first guarantees, across devices. A companion joins only through an explicit, signed ceremony; the running timer shows only a non-secret matter code — not the client's name.
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 are privacy-clean by construction: the running timer and its Live Activity carry only a non-secret matter code, never the client’s name — 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 an explicit, 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.
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).
