Compliance portal architecture: the decisions that matter

Situation: Reported figures are audited and legally significant; model arithmetic is not reproducible.

Choice: Compute every figure with pure functions over versioned factors and store the factor ids used; the model may only propose extracted fields that a human accepts.

• Rejected: Let the model compute totals: not reproducible.
• Rejected: Hard-code factors in source: cannot be audited by date.
• Consequence: Any figure can be recomputed byte for byte.
• Consequence: Factor updates need a data change, not a deploy.
• Consequence: Extraction quality affects effort, not correctness.

Situation: Auditors need the figure as originally reported and as corrected, with the reason.

Choice: Locked periods refuse in-place updates; a change inserts a new version that supersedes the old and requires a reason.

• Rejected: Edit in place with an audit row: the original is harder to reproduce.
• Rejected: Soft delete and recreate: loses the link between versions.
• Consequence: Reports pin a version.
• Consequence: Queries filter to the current version by default.
• Consequence: Storage grows with restatements.

Situation: Disclosure codes change between framework versions and differ by jurisdiction.

Choice: Store framework versions and metric mappings as rows with a verified flag and evidence; exports pin a version.

• Rejected: Code constants per framework: every change is a deploy.
• Rejected: Free text codes: no validation.
• Consequence: Adding a framework is a data task.
• Consequence: Unverified codes are refused unless opted in.
• Consequence: Owners must supply evidence for codes.

Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.

• entities: (group_id, parent_id) — walk the hierarchy for consolidation.
• metrics: unique (code) — metric lookup by stable code.
• source_documents: unique (entity_id, file_hash) — identical bill uploaded twice is stored once.
• extractions: (source_document_id, field) — fields of one document.
• values: unique (entity_id, metric_id, period, version) — one row per version.
• emission_factors: (fuel_or_grid, region, basis, valid_from) — as-of factor lookup.
• framework_mappings: unique (metric_id, framework, framework_version) — one code per metric per version.
• audit_log: (entity_id, created_at DESC) — audit viewer, keyset paginated.

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.

What is the most important architecture decision for a compliance portal?

Deterministic calculation, AI only proposes inputs. Compute every figure with pure functions over versioned factors and store the factor ids used; the model may only propose extracted fields that a human accepts.

Do I have to make these decisions myself?

No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.

What do the alternatives cost me?

For example, for "Restatements create versions, never edits": Edit in place with an audit row: the original is harder to reproduce. Soft delete and recreate: loses the link between versions.

• How to build a compliance portal
• Example prompt for a compliance portal
• Compliance portal security checklist
• Compliance portal scaling checklist
• Often combined: SaaS dashboard
• Often combined: approval workflow app
• All app types