Open Innovation Stack Public proposal

Vision

This document describes the intended direction of the Open Innovation Stack. It is a public design commitment, not evidence that the full platform, standard, governance body, or deployment network already exists.

Status

The change we want

A founder should be able to describe their company once, control who can see each part of that record, and reuse verified information across participating programs. An operator should be able to run applications, evaluation, mentoring, milestones, compliance, facilities, and reporting without reconstructing the same operating system from spreadsheets. Institutions should be able to make expertise and infrastructure discoverable. Funders and public programs should be able to receive comparable information without forcing everyone into one vendor's product.

Over time, the network should be able to learn from aggregate patterns while participants retain control of identifiable records.

The long-term aspiration is an open operating layer for innovation systems: shared enough to interoperate, modular enough to adopt gradually, and governed with the people who depend on it.

The problem

Innovation ecosystems commonly have three disconnected layers:

  1. Operations: applications, evaluation, onboarding, mentoring, facilities, milestones, compliance, and reporting are rebuilt by each institution.
  2. Access: founders repeatedly re-enter the same information and documents for each program, scheme, incubator, or fund.
  3. Intelligence: outcomes and lessons stay in local files and human memory, making comparison slow and ecosystem learning difficult.

Each layer weakens the next. Unstructured operations produce poor data. Fragmented access prevents portability. Weak evidence makes policy and support less responsive.

The proposed response

The Open Innovation Stack is intended to combine:

  • an implementation-independent Innovation Hub Data Standard;
  • a modular reference implementation of common workflows;
  • portable, permissioned participant records;
  • integration and export contracts for independent systems;
  • conformance tests that make interoperability verifiable;
  • privacy-preserving aggregate analysis; and
  • public governance that can broaden as adoption and contribution broaden.

The draft PRD explores seven application modules: Incubator OS, Founder Identity + DealFlow, Ecosystem Map, Facility Booking, Institute Intelligence, Federated Intelligence, and Mentorship & Coaching. Their scope and sequencing remain open to evidence and design review.

Commitments

Interoperability

The data standard must be usable without adopting the reference application. Extensions should be versioned, documented, and designed to avoid trapping participants in one deployment.

Participant control

Founders control founder-owned artefacts. Institutions control their operational records. Receiving organisations see only what a participant has shared or what a legitimate, documented workflow requires.

Privacy by construction

Data minimisation, purpose limitation, tenant isolation, retention controls, auditable access, and explicit consent are architecture requirements. Claims about differential privacy or federated learning must be demonstrated and independently reviewable before production use.

Honest automation

AI-generated fields and suggestions should carry provenance. Missing, conflicting, inferred, and human-confirmed information must remain distinguishable. Causal links require human confirmation.

Modular adoption

A useful workflow should deliver value before network effects exist. No participant should need to adopt every proposed module to begin.

Sustainable openness

Core code and the standard should remain openly usable. Implementation, hosting, migration, training, custom integration, and advanced services may be commercial. Commercial work should not make basic interoperability or data portability a paid gate.

Evidence before authority

Adoption, conformance, security review, and demonstrated outcomes must precede claims of certification, national infrastructure, or independent stewardship.

What this is not

  • It is not a production-ready national platform today.
  • It is not a government portal or a claim of government endorsement.
  • It is not a private startup-data broker.
  • It is not a public ranking system for founders or mentors.
  • It is not a requirement that every institution use the same user interface.
  • It is not a promise that aggregation automatically makes sensitive data safe.
  • It is not currently governed by an independent or neutral foundation.

Who should shape it

The standard and workflows need input from:

  • founders and founder representative bodies;
  • incubators, accelerators, university innovation cells, and program operators;
  • mentors and coaches;
  • capital providers and scheme administrators;
  • researchers, facility owners, and institutional administrators;
  • privacy, security, accessibility, and data-governance practitioners;
  • public-infrastructure custodians; and
  • independent implementers who may never use the reference application.

No one category should define interoperability for all the others.

How we will know the direction is useful

Before national-scale outcome targets matter, the project should demonstrate smaller truths:

  • two independent workflows can exchange the same validated record;
  • a founder can reuse information without losing control of it;
  • an operator can export a complete, auditable reporting bundle;
  • a second implementation can pass the same conformance tests;
  • accessibility and privacy requirements survive real workflow pressure;
  • aggregate analysis does not expose participant-level records; and
  • contributors outside the founding team can understand and change the standard.

The broader economic and adoption outcomes in the draft PRD remain hypotheses until these foundations are proven.

Published from VISION.md.

Search the stack

Pages, the article, and infographics.

moveEnter openEsc close