This page describes how a project becomes a Research & Intelligence record — intake through lock — and what quality gates apply before the record becomes input to the Risk Engine.
A new project enters the R&I system as an intake record. Minimal metadata: sponsor, sector, indicative stage, geography, point of contact.
No analytical work happens at intake. The goal is to establish the project in the system with a unique identifier and assign an R&I Analyst. The intake record is not yet analytical data; it is registration.
The R&I Analyst builds the record — iteratively, with version history preserved at every step.
Every material analytical claim is entered as a structured assumption: category, statement, stated confidence (high/medium/low), evidence source, citation.
Assumptions are versioned; superseded assumptions remain in the record linked via their successor for full traceability.
Documents, datasets, and references are ingested, typed, and indexed. Sponsor-provided materials and externally-sourced materials are distinguished.
Each source pack item stores a SHA-256 content hash; later detection of tampering is trivial.
Structured fields of the project model — operator data, asset characteristics, technical parameters, market positioning — are filled from the assumption register.
The R&I Analyst self-reviews against a completeness checklist before submitting for Compliance review. Analytical weaknesses are documented in the record itself, not hidden.
Compliance reviews the record for completeness, internal consistency, and adequacy of evidence.
A locked R&I record is immutable for the purposes of downstream work. The version hash (SHA-256 over the entire R&I data) is stored with the lock record. Any later correction requires an explicit Compliance-authorized unlock with a documented reason; the unlock is audit-logged; all prior versions are retained.
The locked record becomes read-only input to the Risk Engine. Risk Scorers cannot modify it; they can only consume it.
This separation — architectural, not just procedural — is the foundation of TCA's analytical independence. It's enforced at three layers: authentication, authorization, and the database schema itself.