Three things that are true of the build
Not a technical page. Each idea names its mechanism once, and then says what it means for the person who has to stand behind the file.
Access is enforced by the database, not by the screen
The mechanism is row level security. Every table carries it, so permission is checked where the data lives rather than where it is displayed.
What that means for you: if somebody's session should not see a work paper, no bug in the interface can show it to them. Most systems enforce access in the screen, which means a single mistake in the screen is a disclosure. Here the screen is not the thing being trusted.
Records that are meant to be permanent are permanent
The mechanism is append only storage with hash chained audit trail entries. Assessments are never updated in place, and each work paper event's digest covers the one before it.
What that means for you: a correction appends, it does not overwrite. The earlier record stays readable, so the history of a judgement is part of the file rather than something lost when somebody changed their mind. The chain can be verified on screen, and a verification states how many events it checked.
That last detail matters more than it sounds. An empty chain also verifies as intact, so a verification that does not say how many events it covered has said nothing at all.
Regulatory content is selected, not assumed
The mechanism is a jurisdiction pack, chosen at onboarding rather than inferred from where you happen to be.
What that means for you: the product says on screen which pack is in force, so nobody has to guess which regulatory content the work was done against.
It also says that the content is provisional pending counsel review, because it is. A pack is a starting position built by people who are not your lawyers. Saying so on screen is less comfortable than not saying it, and it is the only version of this that survives a due diligence conversation.