The chained record
State is not held as a field that gets overwritten. What is held is the list of what happened, in order, and the state is computed by walking it.
Each note carries the cryptographic digest (SHA-256) of the one before it, so the list forms a chain. Altering or removing a note breaks the digest of every note after it, and walking the chain detects that. The check is open to anyone with access to the file: there is no need to take the system's word that the chain is intact — you walk it and check.
Two properties institutions usually ask for separately fall out of this: traceability — who did what and when — and reproducibility: two people walking the same chain arrive at the same state.
One engine, many applications
The nine applications are not separate systems wired together. They are views over one engine and one store, which is why what one of them records the others find without any synchronisation.
The procedure — bodies, majorities, quorum, deadlines and the approval chain — is data, not code. Changing it is a data change that goes through its own approval, with a revision and an effective date, and it can be rehearsed against the record before it is published.
A change request against a rule and a bill against the body of law are the same object, which is why one engine serves both.
Identity and permissions
Identity is the person's Google account, verified by Amazon Cognito over OpenID Connect with PKCE. The system stores no passwords.
Permissions are not a separate list. A post on the org chart carries a role, the role carries permissions per application, and appointing a person to that post is what writes their access. Withdrawing the appointment revokes it, leaving no forgotten active account.
Every call is resolved with the identity of the caller and the organisation they belong to, which is derived from that identity and never from anything in the request.
Infrastructure as code
The whole installation — network, storage, functions, domains, mail and certificates — is declared in a single AWS CloudFormation template. There is no step somebody performs by hand and then has to remember.
The template lives in Git with its full history: what changed, who changed it, when and why. An earlier version is applied again the way code is rolled back.
What is declared and what is actually running are compared, and the difference is shown. A new installation is raised with the same command that raised the last one.
Serverless execution
The engine, the API doors and the scheduled jobs are AWS Lambda functions. The data is in DynamoDB and the files in S3, behind CloudFront.
No machine stays switched on between one request and the next: there is no operating system to patch, no capacity to size, and no maintenance window to announce. DynamoDB's backup is continuous and storage is replicated across three availability zones.
Where it runs
In the Ciserex cloud, where the institution signs in and works; or in the institution's own cloud account, where the data never leaves that account. The template is the same and the place is a parameter.
The region is the customer's choice, which is usually decided by where the data must reside.
Checkable compliance
Each control is defined once, with the query that produces its evidence. The standards — ISO 9001, ISO/IEC 27001, ISO 15489, ISO/IEC 42001, the GDPR and SOC 2 — are mappings over that catalogue, so two standards cannot give different answers about one control.
A clause no query can answer is marked “by hand”, names who must verify it, and does not count as satisfied. Ciserex is not certified against those standards: it publishes how it meets them and the evidence for each clause.
Interfaces
The only programming surface is one HTTP door: the interface and every other channel call through it, carrying the identity of the caller. There is no separate, privileged path underneath.
Beyond the web and the phone applications, the system answers by e-mail and over Telegram, and publishes what it should as public, verifiable pages.
