Sec. 01 — Evidence register · Form SC-03

Case files, on public record.

Three matters from current practice, anonymised: no client names, no confidential terms. Each file shows the problem, the decision, where it stands and which principle it shows. The systems built around the law are filed separately, as Annex E.

Evidence register — public case filesSC-03.00
Case Title
01Two entities, one contractor
02An NDA that survives role changes
03Privacy for a group run by one lawyer
EExecution layer — three public demos
[  ] Internal circulation[X] Anonymised — released to public record
D. Kein — General Counsel Approved · 07/2026
Sec. 02 — Case filesSC-03.01–03
CASE 01 Contracts · Privacy SC-03.01

Two entities, one contractor

One registration, two provable contracts — and privacy roles kept out of the contract.

Client
Jurisdictions
IE · HK
Status
[X] In use
1
The problem

A group pays freelancers from two entities, in Ireland and Hong Kong. Moving a project from one entity to the other meant re-signing contracts, and it blurred which company controls the contractor's data.

2
The decision

Double Acceptance: registration creates two separately provable framework agreements. Each Order names exactly one customer entity. An existing Order moves only by a three-party instrument — never by automatic novation. Accepting the contract is kept separate from privacy consent and from controller roles.

3
Status

Architecture in use; current revision in legal review.

4
What it shows

Facts before labels — the contract and the privacy role are two different questions.

Structure of the decisionSC-03.01
TWO ENTITIES ORDERS · PROVABLE PRIVACY ROLES · APART IE · HK FRAMEWORK × 2 ONE CUSTOMER / ORDER
Text description

Mini schematic: a contractor registers once with a group of two entities; Double Acceptance creates two framework agreements and binds each Order to one customer; out come provable Orders and privacy roles kept apart from the contract

CASE 02 Confidentiality · People SC-03.02

An NDA that survives role changes

A fixed core and a replaceable rider instead of a new NDA for every project.

Client
Jurisdictions
Group-wide
Status
[X] Live
1
The problem

Every new project or role meant a new NDA for staff, candidates and contractors.

2
The decision

A fixed NDA core plus a replaceable Permission Rider with nine permissions; a blank permission means not permitted. When someone changes role, only the Rider is signed again.

3
Status

Live in the e-signature platform since September 2026; HR trained; an 18-scenario regression checklist.

4
What it shows

Law that runs through what people already do.

Structure of the decisionSC-03.02
ROLE CHANGE NEW RIDER ONLY 18-SCENARIO CHECK STAFF · CONTRACTORS NDA CORE · FIXED PERMISSION RIDER
Text description

Mini schematic: a role change enters the NDA system; the NDA core stays fixed and only the permission rider changes; out come a new rider instead of a new NDA and an 18-scenario check

CASE 03 Privacy SC-03.03

Privacy for a group run by one lawyer

A privacy structure sized to the team that has to run it.

Client
Jurisdictions
EU · HK
Status
[X] In review
1
The problem

Several entities, GDPR and Hong Kong's PDPO, and one lawyer. Asking for permission at every processing step was unmanageable.

2
The decision

Roles are assigned by what each entity actually does, not by declaration. A master data processing agreement gives standing written authority on both sides of the processing chain, while prior notice of new sub-processors and the right to object are preserved (GDPR Art. 28(2)).

3
Status

Candidate documents in review.

4
What it shows

A system sized to the team that has to run it.

Structure of the decisionSC-03.03
GROUP ENTITIES STANDING AUTHORITY SUB-PROCESSOR NOTICE GDPR · PDPO ROLES BY FACT MASTER DPA
Text description

Mini schematic: group entities under GDPR and PDPO enter the privacy structure; roles are assigned by fact and a master DPA is signed; out come standing written authority and prior notice of new sub-processors

Sec. 03 — Practice logSC-03.L

Practice log.

What changed in the practice, month by month. Updated monthly; no client names.

MonthEntry
10/2026Sanscript relaunched as a lawyer-led legal solutions bureau; prices and a privacy notice published.
09/2026NDA core and permission rider go live in a group's e-signature platform; HR trained — Case 02.
03/2026Appointed General Counsel of a multi-entity group.
Annex E — ExecutionSC-03.E

Systems built around the law.

Where a legal rule has to run every month, Sanscript builds it into the client's own tools. These three demos are sanitized copies of working systems — live application, code, data source and output folder. They are the execution layer of an order, not a substitute for the legal work.

DEMO E-01 Finance Ops SC-03.E1

Contractor Payment Engine

Contractor payout packets, checked before they are generated.

Client
Contact person
Liaison
1
The problem

Contractor payout evidence is assembled by hand, slow and hard to defend in an audit.

2
System built

A Jira-gated Google Apps Script workflow that validates context, controls allocation and generates payout documents in one guided run.

Google Apps Script Google Workspace Google Sheets Google Docs PDF generation Jira-gated workflow archive/rerun logic validation gates
3
Control angle

Validation gates run before generation; allocation is controlled to the cent; every run leaves an evidence trail.

4
On record

Payout packets made fast AND defensible at 50+ contractors and 200–500 documents per month. A 6-month window recorded 0 bank/tax claims and about 20% lower recurring finance effort.

5
Result

1–3 hours by hand → under 10 minutes

Working schematic — how the demo runsSC-03.E1
JIRA TICKET REGISTRIES DOC TEMPLATES PAYMENT ENGINE CONTEXT CHECK ALLOCATION GENERATE DOCS EXCEPTION TRAY PAYOUT PACKETS RUN LOG EVIDENCE ARCHIVE RUN GATE CHECKSUM · TO THE CENT 4-TAB CONTROL MODEL GOOGLE DOCS HUMAN CHECK DOCS · PDF EVERY RUN ARCHIVE-FIRST SHEET SC-03.E1 — PAYMENT ENGINE FORM SC-03 · REV 07/2026
Text description

Payment engine schematic: a gated Jira ticket, master sheet of hours and rates, and document templates feed the payment engine — context check, allocation, document generation with a validation mark; exceptions go to a human tray; outputs are payout packets, a run log and an audit-ready evidence archive

Items — filed with this demoSC-03.E1-A
Item A — Live applicationOpen ↗ Item B — Public repositoryOpen ↗ Item C — Data source — SheetsOpen ↗ Item D — Output folder — DriveOpen ↗
DEMO E-02 Reporting SC-03.E2

Invoice & Report Creator

Billing packets generated from structured inputs.

Client
Contact person
Liaison
1
The problem

Recurring billing packets are rebuilt manually across days.

2
System built

A Google Workspace flow that turns recurring billing input into invoice and report packages, including PDF and signed PDF outputs.

Google Apps Script Google Workspace Google Sheets Google Docs PDF generation signed PDF validation gates
3
Control angle

Structured inputs and templates remove manual copy-paste errors; totals are recalculated server-side before any document is produced.

4
On record

Billing packets generated consistently from structured inputs, not rebuilt from old files. TM and FP billing models run in one process; reruns are non-destructive.

5
Result

about 2 working days → about 10 minutes

Working schematic — how the demo runsSC-03.E2
BILLING SHEET TEMPLATES REPORT BUILDER TM / FP RULES RECALC TOTALS FIX & RERUN INVOICE + REPORT SIGNED PDF PRIOR RUNS ONE SOURCE DOCS · BRANDED HOURLY · FIXED + OT SERVER-SIDE BACK TO SHEET GDOC · PDF READY TO SEND NON-DESTRUCTIVE SHEET SC-03.E2 — REPORT BUILDER FORM SC-03 · REV 07/2026
Text description

Report builder schematic: a billing sheet and branded templates feed the report builder — TM and FP billing rules, then server-side total recalculation; input errors loop back to the sheet; outputs are invoice and report gDocs and PDFs, signed PDFs, and non-destructive prior-run archives

Items — filed with this demoSC-03.E2-A
Item A — Live applicationOpen ↗ Item B — Public repositoryOpen ↗ Item C — Data source — SheetsOpen ↗ Item D — Output folder — DriveOpen ↗
DEMO E-03 Legal Ops SC-03.E3

Migration Document Pack Generator

Legal document packs with conditional logic and archived reruns.

Client
Contact person
Liaison
1
The problem

Legal document packs depend on old files and manual conditional logic per case.

2
System built

A structured data and validation workflow that generates Spain residency document packs and preserves previous runs before regeneration.

Google Apps Script Google Workspace Google Sheets Google Docs PDF generation conditional logic archive/rerun logic validation gates
3
Control angle

Conditional logic is encoded per family role and age; previous runs are archived before regeneration for traceability.

4
On record

Document packs carry conditional logic and traceable reruns — 50+ packages processed, 0% paperwork rejection, up to 13 PDFs per family in one run.

5
Result

about 5 hours → about 1 hour per case

Working schematic — how the demo runsSC-03.E3
CLIENT SHEET TRACK SELECT PACK GENERATOR ROLE & AGE LOGIC VALIDATION GATES ASSEMBLE PACK UP TO 13 PDFS / FAMILY DATA GAPS RESIDENCY PACK PRIOR RUNS RUN LOG FROM GOOGLE FORM REMOTE · STARTUP BACK TO OWNER NUMBERED DOCS ARCHIVE ROLLOVER SHEET SC-03.E3 — MIGRATION PACKS FORM SC-03 · REV 07/2026
Text description

Migration pack schematic: a client sheet filled from a Google Form and a Remote-or-Startup track selection feed the pack generator — role and age logic, validation gates, pack assembly of up to 13 PDFs per family; data gaps go back to the owner; outputs are a numbered residency pack, prior runs preserved by archive rollover, and a run log

Items — filed with this demoSC-03.E3-A
Item A — Live applicationOpen ↗ Item B — Public repositoryOpen ↗ Item C — Data source — SheetsOpen ↗ Item D — Output folder — DriveOpen ↗ Item E — Intake — Google FormOpen ↗

Case files are anonymised: client names, counterparties, confidential terms and personal data are excluded; the problem, the decision and the status are kept. The Annex E demos are sanitized public showcases.

Recognise your problem in one of these files? Start with a 20-minute call.

Book a 20-minute call