For a diocesan IT department

A web application. Staff use it in a browser, and nothing is installed on their computers.

A small Linux server or virtual machine, with Node.js 22. It can sit on the virtualisation a diocese already runs, such as Hyper-V or VMware, or in the diocese's own Azure tenant. It has not been tested on Windows itself.

The database is SQLite: a single file on that server. The original documents of the acts are kept in a folder beside it, which may be a network share.

On that server, in the documents folder if that is kept on a network share, and in whatever backups the diocese takes. Installed on a server the diocese owns, the records do not leave the diocese.

Each original document is encrypted with AES-256-GCM under a key of its own, and that key is encrypted under the installation's key. The installation's key is a file on the server, held by the diocese. Someone who obtains the folder of documents, or a backup of it, without that key can read nothing.

The application does not encrypt the database file. It holds everything that is not an original document, including names, grounds and the passages quoted in a chronology. A judge's votum is not in it: a votum is kept only as its document, encrypted. The database should sit on an encrypted disk with access to the server restricted.

It is served over HTTPS, behind the web server or proxy the diocese uses for its other applications.

A password, stored as a salted scrypt hash, and a six-digit code from an authenticator app. Repeated wrong attempts lock the account for fifteen minutes. A session ends after twelve hours, or after two hours without use. Signing in with Microsoft 365 accounts (Entra ID) is not built yet. A diocese that uses Entra Application Proxy can publish the application to people outside the office through its own Microsoft sign-in, with no change to the application.

If judges and others are to use it from outside the office, the server is reachable from the internet, or through the diocese's VPN if it prefers.

A party or a witness can be given a link and a short code in place of an account. The two are sent by different routes and are kept only as hashes. Five wrong codes make the link wait fifteen minutes. A link expires on a day the tribunal sets, ninety days by default, and can be withdrawn at once. It opens a separate, limited view and never the acts.

Each account has a role. An account for a judge, defender of the bond or advocate engaged for particular causes opens those causes only. A document that a decree has withheld is given out only through the application, which checks who is asking.

Every change is written to the record in the same database transaction as the change itself, with the account, the time and the IP address (the visitor's own, when the application sits behind a proxy). The application offers no way to edit or delete an entry.

The record is a hash chain. Each entry is numbered and carries a SHA-256 hash of its own contents and of the hash before it, and a command checks the whole record from its first entry. An entry changed, removed or inserted afterwards is detected.

Someone with administrative access to the server could still alter an entry and seal the chain again from there. What guards against that is a copy of the latest seal kept somewhere else. The record's page shows it, to be printed and signed by the notary, or given to a timestamping service of the diocese's choosing. The application itself sends it nowhere.

None, unless one is turned on. The application sends no usage data to anyone, and its fonts and scripts are its own, so it works with no connection to the internet.

Two connections are optional. Time limits can be written into Outlook calendars through Microsoft 365, by an application the diocese registers in its own tenant with access limited to the tribunal's mailboxes. And the planned assistant would send the text of a deposition to a model at an address set on the server by its administrator. The application shows that address, and whether it is on the local network, to everyone who uses the assistant. It does not itself prevent the address being set to a machine elsewhere.

On a server the diocese administers: none, unless the diocese gives it for installation or support, and for as long as it chooses.

The provider, the country the server is in, and who has administrative access to it are agreed with the diocese beforehand. Whoever administers a server can reach what is on it, so in that case the entry above holds only as far as that agreement provides.

Three things are backed up: the database file, the folder of documents, and the installation's key, which is kept apart from the other two. The diocese's own backup system can take them. The database should be copied with SQLite's backup command, or with the application stopped, and not simply copied while in use. A command checks that a restored folder is complete and that every document in it still decrypts.

An update is a new version of the application, installed on the server by whoever administers it. Changes to the database are applied by a command that comes with the update. Where the diocese gives him access for the purpose, Richard can install an update himself; otherwise he goes through it with whoever does. An update may not fit a copy the diocese has altered.

Richard wrote the system and gives the support himself, so he is the person to write to. With the diocese's leave he can look at the server directly. He does not promise a fixed time for an answer.

If a security fault is found, Richard tells every tribunal that uses the system directly. Security fixes are not charged for, for as long as he maintains the system. He does not promise a fixed time for a fix.

Nothing stops working. The system runs on the diocese's server and depends on nothing of his: no licence server, no connection to him, no key he holds.

It comes with a written guide for whoever looks after the server: how to tell whether it is running, restart it, back it up, restore it and check that the restore is whole, install an update, and let someone back in who is locked out. None of it needs him.

The records would remain readable without the maker. SQLite is an open, widely used format. The letters and decrees are ordinary Word files. The originals can be decrypted with the diocese's own key.

The diocese also holds the source code, which is installed on its server, and a licence to go on using and changing it for itself. Yours to change describes this.

Richard Verver, a sole proprietor in Ontario. He is the only developer and gives the support himself. There is no company and no second person.

No independent security review has been carried out. A single export of all records is planned and not yet built. There is no sign-in with Microsoft 365. The application is in English only.