The 7-layer verification model.
Evidence-first, analyst-validated. Every finding is tied to observable evidence — a file, a line, a config value — never an opinion.
Seven layers, one verdict
Each engagement works through the same seven layers and rolls them into a single score with a PASS / HOLD / FAIL verdict.
Code substance
Is the codebase real, coherent, and consistent with the story being told?
Claim reality
Do product and AI-capability claims match what the code and configuration actually do?
Security posture
Authentication, authorisation, input validation, secrets, and dependency exposure.
Data handling
How data is stored, protected, retained, and whether privacy signals hold up.
UX & workflow
Does the build actually support the workflow it promises, end to end?
Evidence pack
File-referenced findings, severity, and a tamper-evidence hash manifest you can verify.
Launch readiness
A prioritised view of what to fix before market, funding, or acquisition.
How each layer is evidenced
Representative checks. Every answer is a structured code — never a freeform opinion.
| Layer | Example check | Evidence type | Answer format |
|---|---|---|---|
| Code substance | Business logic separated from data access? | file structure, class names | CODE-YES / PARTIAL / NO / NOT-FOUND |
| Claim reality | Is the "proprietary AI" claim borne out in the repo? | model/training code vs API calls | SUBSTANTIATED / PARTIAL / NOT |
| Security posture | Secrets excluded from version control? | .gitignore, env, secret manager | CODE-YES / NO / NOT-FOUND |
| Data handling | PII encrypted at rest? | DB schema, crypto libraries | CODE-YES / PARTIAL / NO |
| UX & workflow | Core promised flow complete end-to-end? | route/handler trace | CODE-YES / PARTIAL / NO |
| Evidence pack | Every finding cites file + line? | report cross-refs + manifest | YES (by construction) |
| Launch readiness | Staging gate before production? | CI config, deploy steps | CODE-YES / PARTIAL / NOT-FOUND |
Evidence-based review in 5 steps
Repeatable and auditable, from intake to secure delivery. No code execution; no data retention beyond 24 hours.
Intake
Receive repo access or a code package. Create a read-only clone. No modification, execution, or deployment at any stage.
Evidence freeze
Hash every file (SHA-256) and lock a tamper-evidence manifest — a verifiable snapshot of the codebase as received.
Automated evidence sweep
Work the 7 layers against the code. Each finding links to a file path and line number — direct reference, not inference.
Analyst validation
A senior reviewer validates every P0/P1 finding and resolves ambiguous evidence manually, with rationale recorded.
Package & deliver
Deliverables assembled and sent securely. Repository data deleted within 24 hours; deletion confirmation available on request.
Reference frameworks
The evidence model is structured to support reporting that references:
Central Bank UAE technology risk management guidance
Dubai Financial Services Authority technology governance
Financial Services Regulatory Authority technology requirements
Information-security control domains (reference)
Trust Service Criteria — security, availability, confidentiality (reference)
Evidence, not opinion
Our scope is deliberately narrow and precise: structured technical evidence — nothing more, nothing less.
What we provide
- ✓File references with exact line numbers
- ✓Code excerpts as direct evidence
- ✓A SHA-verified baseline of the codebase
- ✓Objective result codes and a PASS/HOLD/FAIL verdict
- ✓Severity classification (P0 / P1 / P2 / Low)
What we do not provide
- ✕Legal advice or compliance opinions
- ✕Investment recommendations
- ✕Compliance certifications
- ✕Forward-looking performance guarantees