The scorecard the prototype produces
Synthetic case.
Trust
Independence
in the method.
Clarity in the controls.
Where the product stands, how evidence will be kept, how the review stays independent, and what is agreed with each partner before customer data is processed.
Current deployment / synthetic data onlyNo customer data processed
Current
Synthetic cases.
Working prototype.
- Running in the prototypeCDD prototype accepts PDF case files
- Running in the prototypeWeighted QA report on synthetic CDD cases
- In progressRecruiting founding design partners
Before customer data
Controls agreed
with each partner.
- 01IndependenceAgreed per partner
- 02ScopeAgreed per partner
- 03ConfirmationAgreed per partner
- 04Data handlingAgreed per partner
01
Product status
Where YSSEM is now.
A working CDD prototype
The prototype accepts PDF case files and produces a weighted QA report. The review pipeline operates on synthetic CDD cases.
Inspect the outputBefore first deployment
YSSEM is recruiting founding design partners. Data handling, security and review responsibilities are agreed with each partner before any case data is processed.
About the companyRunning in the prototype
02
Data integrity
How evidence will be kept.
- One data model
Every case will be mapped into a single internal format when it arrives, whether it comes from a case-management system, a CSV export or a PDF. QA results will be comparable across sources: if two cases score differently, the difference will be in the cases, not in how they were exported.
- Customer isolation
Each customer’s data will be structurally separated. Every record will carry the customer it belongs to, and the data layer will not run a query without knowing which customer is asking.
Scoping will be enforced in the data access layer, with Postgres row-level security as a second layer.
- Original records kept
What your system sends will be stored exactly as it arrived and never overwritten, alongside the normalised version. If a finding is disputed, the record your system sent, and when it sent it, will be there to check.
- Versioned, tamper-evident reports
A QA report will never be edited. Re-reviewing a case will create a new version; the earlier one will remain, linked to the version that replaced it, so you can always see what was approved at the time it was approved.
When a reviewer locks a report, a SHA-256 fingerprint of the report and every finding disposition will be stored. Recomputing it later will show whether anything changed after approval.
- Audit log
An append-only record of who did what, when, and what changed. Every action that touches evidence, or who may access evidence, will record the actor, the action, the object, the values before and after, and the request it came from. It will answer an examiner’s question: who approved this finding, and when?
03The method is part
Review method
The method is part
of the control.
Nothing is auto-resolved. YSSEM raises and escalates. What to do with it is your judgment.
Discuss deployment requirements- 01
Keep the review independent.
Separate the original decision from its quality assessment. YSSEM independently tests the outcome. Likely policy breaches are flagged for your reviewers, with the audit trail showing what was reviewed and where the exception was identified.
- 02
Make the scope explicit.
Agree the population, sample, policy criteria and version. State the limits of a sampled result.
- 03
Define how findings are confirmed.
Document human-review responsibilities, escalation, disputed results and the evidence retained with each finding.
- 04
Agree data handling before deployment.
Hosting, access, retention, AI provider terms, the DPA and security testing are documented and agreed with each partner before customer data is processed.
Due diligence
Bring your due-diligence questions.
Ananya and Simon will walk through the prototype, the method and the evidence required for your environment.