Architecture

Status

Two artefacts, not one

The project intends to publish two related but separable artefacts:

1. The Innovation Hub Data Standard: an implementation-independent contract for exchange, ownership, provenance, visibility, and validation.
2. A reference implementation: one modular application demonstrating how those contracts can support real workflows.

An independent system should be able to conform to the standard without using the reference application's code, interface, database, or hosting model.

Proposed system shape

The current draft favours a modular application over seven separately deployed products. Modules share identity, permissions, workflow primitives, and a common data spine while keeping explicit internal contracts.

flowchart TB
    UI["Public and authenticated UI shell"]
    AUTH["Identity, roles, consent, and tenant boundaries"]
    API["Module and public APIs"]
    WORKFLOW["Workflow engine, audit events, and signal routing"]
    DATA["Shared relational data spine"]
    STANDARD["Implementation-independent data standard"]
    INTEGRATIONS["Exports, connectors, and signed webhooks"]
    AGG["Governed aggregate analysis"]

    UI --> AUTH
    UI --> API
    AUTH --> API
    API --> WORKFLOW
    WORKFLOW --> DATA
    API --> DATA
    STANDARD -. "defines exchange contracts" .-> API
    STANDARD -. "defines portable records" .-> DATA
    WORKFLOW --> INTEGRATIONS
    DATA --> AGG
    AGG --> API

The reference implementation explored in the draft PRD uses a Next.js/React interface and a shared Postgres data spine. Those are implementation choices, not requirements of the open standard.

Proposed modules

Modules own workflows, not participant data. Shared entities and permission rules belong to the data spine and standard.

Core domains

The proposed shared spine includes:

• identities, organisations, memberships, roles, and tenants;
• applications, destinations, reviews, offers, and handoffs;
• programs, cohorts, member tracks, milestones, and compliance artefacts;
• contacts, interactions, mentoring sessions, decisions, action items, and outcome links;
• institutions, researchers, technologies, programs, schemes, and facilities;
• booking and usage records;
• sharing grants, retention policy, provenance, and audit events; and
• aggregate query definitions and disclosure-controlled outputs.

These are candidate domain concepts, not a released schema.

Data ownership and trust boundaries

Founder-controlled material

A founder's reusable profile and documents should travel only with explicit sharing. Destination-specific internal evaluation should not travel back into the founder vault or onward to another funder.

Organisation-controlled operations

An operator controls its operational records within documented legal and contractual obligations. Export, retention, deletion, and access rules must be visible and testable.

Shared workflow records

Applications, bookings, mentoring action items, or offers may have more than one legitimate participant. The model must define who can change which fields at each state instead of assigning vague “shared ownership.”

System-authoritative records

Audit events, conformance results, and integrity records should be append-only or otherwise tamper-evident. Administrative bypass paths must be narrow, server-side, logged, and tested.

Aggregate intelligence

Identifiable records must not enter public or cross-tenant analysis by default. Any future aggregate layer needs:

• a documented lawful purpose and consent model;
• minimum cohort and suppression rules;
• re-identification and differencing-attack analysis;
• query budgets where differential privacy is claimed;
• transparent model and data provenance;
• human review for high-impact signals; and
• an appeal or correction path.

Federated computation does not remove these obligations.

Identity, tenancy, and permissions

The current direction is one human identity with multiple roles rather than duplicate profiles for each module. An identity may participate in multiple organisations or tenants.

Permissions should be composed from explicit primitives:

• actor identity and role;
• tenant and facility scope;
• record ownership or processing authority;
• workflow state;
• sharing grant and purpose;
• field sensitivity; and
• time or retention constraint.

The exact identity provider and relationship to external identifiers remain open questions. External identifiers should be links, not unreviewed sources of authority.

Workflow and integration

Cross-module behaviour should use typed, audited events rather than hidden database coupling. A typical proposed flow is:

1. a founder shares an application with a destination;
2. the destination receives a standard record;
3. an operator advances it through a state machine;
4. acceptance creates an authorised membership or handoff;
5. milestones, mentoring, facilities, and reporting subscribe to relevant events; and
6. only approved aggregate signals leave the participant boundary.

External integrations should use versioned exports, explicit mappings, idempotency keys, signed requests, retry policy, and reconciliation. A named government program in a planning document is not proof that an API, partnership, or production connector exists.

Deployment direction

The reference application is intended to support self-hosting and a hosted option using the same open core. Before either is described as production ready, the project needs:

• repeatable deployment and rollback;
• tenant-isolation and authorisation tests;
• backup, restore, export, and deletion procedures;
• secret management and dependency controls;
• security, privacy, and accessibility review;
• observable but data-minimising operations; and
• a migration path an independent adopter can exercise.

The public documentation and publishing site do not satisfy those gates.

Architecture decisions carried forward

The following directions are strong enough to guide foundation work but remain reviewable:

• begin with one modular reference application rather than seven products;
• use one consistent data spine inside that reference application;
• license code under MIT and standard prose under CC-BY-4.0;
• keep founder-controlled records portable;
• treat mentorship as a first-class workflow;
• track AI provenance by section or field;
• require human confirmation for causal outcome links; and
• make any future certification voluntary and based on public conformance tests.

Open questions

High-priority unresolved questions include:

• the minimum viable standard surface;
• identity and consent across multiple organisations;
• tenant hierarchy and dual participation;
• extension and backward-compatibility policy;
• retention and deletion across shared records;
• low-bandwidth, multilingual, and accessibility requirements;
• facility liability and safety records;
• disclosure controls for aggregate analysis;
• standards-council composition;
• the boundary between open core and paid services; and
• which narrow workflow should become the first reference slice.

These should become public issues or RFCs before implementation commits the project to irreversible assumptions.

Implementation status