Build a compliance portal
How to build a compliance portal with AI
To build a compliance portal, describe who it is for and what they do in it, and let Forge64 plan and generate the app. Entities submit activity data (forms, bulk files, PDF bills); AI proposes extracted fields that a human reviewer must accept; deterministic code computes the reported figures from versioned cited factors; periods lock, changes are restatements; every number traces to source, method, approver and version; regulatory framework mappings are data; exports for auditors and regulators. The core parts of a first version are entity hierarchy and tenant isolation, roles and period permissions, maker-checker approval, append-only audit trail and period lock and restatement versions.
Last checked
What the first version needs
These are the parts a compliance portal needs before it is useful. Each one is something the plan covers.
- Entity hierarchy and tenant isolation: Model the group, its operating companies and their ownership, and keep each entity's data invisible to the others.
- Roles and period permissions: Separate who submits, who reviews, who administers and who only reads.
- Maker-checker approval: Nothing becomes a reported value until a different person approves it.
- Append-only audit trail: Prove who changed what, when and why, including to auditors.
- Period lock and restatement versions: Approved periods are frozen; a change creates a new version with a mandatory reason and keeps the old one.
- Value-to-source traceability: Every figure traces to its source document, page, method, confidence, approver and version.
- Versioned reference data (factors, frameworks): Emission factors and regulatory mappings are data with validity periods and citations, not constants in code.
- Reviewer work queue: Route submitted and extracted items to reviewers, track assignment and ageing.
- Deterministic emissions calculation: Compute Scope 1 and Scope 2 (location and market based) and consolidate to group level without any model arithmetic.
Parts you can add in the first version
- Bulk CSV and Excel intake: Load many activity rows at once with row-level validation.
The data it stores
Each table below becomes part of the Postgres database that belongs to your app.
- entities: control_type: equity|operational|financial; equity_share 0..100 CHECKed.
- metrics: reference list shared by all entities.
- source_documents: immutable after insert; the hash is the SHA-256 of the exact bytes.
- extractions: status: proposed|accepted|rejected; only accepted rows can feed a value.
- values: CHECK approved_by <> submitted_by; approved and locked rows are never updated in place.
- emission_factors: versioned reference data; rows are never edited, superseded by a later valid_from.
- framework_mappings: unverified codes are refused for regulator exports.
- audit_log: insert-only; UPDATE and DELETE are refused by trigger.
- review_items: claimed with SKIP LOCKED; closed when the decision is recorded.
Pages and endpoints
| Route | Who can use it | What it does |
|---|---|---|
| /dashboard | authed | group dashboard with drill-down from any figure to its source. |
| /entries | authed | activity entry form and bulk upload for an entity. |
| /review | authed | reviewer queue: accept or reject extracted and submitted values. |
| /api/documents | authed | upload a source document; hashes, caps size and pages, proposes fields. |
| /api/values/[id]/approve | authed | approve a value; refuses the submitter. |
| /api/periods/[id]/lock | authed | lock an approved period (admin). |
| /api/reports/export | authed | PDF, Excel and regulator-format exports from pinned versions. |
| /audit | authed | read-only audit trail for auditors. |
What to leave out of version one
- No model-computed figures: the model proposes fields, code computes values.
- No unverified regulatory code presented as verified.
- No automatic submission to a regulator in phase 1.
- External assurance workspace: plan for it, build it later.
How Forge64 builds it
Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.
FAQ
- What does a compliance portal need first?
- Entity hierarchy and tenant isolation, roles and period permissions, maker-checker approval, append-only audit trail, period lock and restatement versions and value-to-source traceability. The plan for a compliance portal covers all of these before it generates code.
- What should I leave out of the first version of a compliance portal?
- No model-computed figures: the model proposes fields, code computes values. No unverified regulatory code presented as verified. No automatic submission to a regulator in phase 1.
- Which products define the compliance portal category?
- Well-known examples include Persefoni, Watershed, Workiva, Sphera and GHG Protocol corporate standard. Use them to decide which features your users expect, then describe your own version.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free