vreau-digital/chatGPT/simple-research-report.md

GovTech Commons Portal: Deep Research Blueprint for an Open-Source, Citizen-Friendly GovTech Aggregator

File A (full research report): full-research-report.md
Assumed date: 2026-04-06 (Europe/Bucharest)
Scope: EU/Romania-first; no vendor lock‑in (explicitly avoided unless unspecified); currency unspecified.

Executive summary

I propose an open-source “GovTech Commons Portal” that combines a public-sector software catalog (metadata-driven, reuse-first) with citizen-legible one-click runnable demos hosted in a hardened sandbox. The core hypothesis is that “adoption friction” is currently higher than “innovation friction”: prototypes exist, but they are hard to discover, trust, and pilot in public administration contexts. This aligns with the EU expansion of reuse infrastructure (the EU Open Source Solutions Catalogue is a centralized discovery layer and was launched in 2025, initially with hundreds of solutions and a plan to include more repositories and building blocks). citeturn2search2turn2search9

The strategy is to treat publiccode.yml as the baseline contract for discoverability and reuse (it is explicitly designed for public administration software discovery and reuse, and it has operational precedents across Europe, including national catalog crawling patterns). citeturn2search0turn2search4turn6search2 I then expand it with a strictly versioned “portal superset schema” that adds demo/runtime descriptors, security artifacts (SBOM/provenance/signatures), privacy declarations, and AI disclosure fields. citeturn2search0turn3search2turn1search2

The portal must ship with a trust ladder whose criteria are objective, auditable, and legible to non-technical citizens: Demo-safe → Pilot-verified → Production-adopted. Europe already provides a strong reference pattern for “badges in government catalogs” (e.g., a criteria-based badge program describing security/maintenance/reuse qualities). citeturn6search8turn6search4

The highest-risk part is executing untrusted demos; I therefore recommend a WASM-first demo runner as the default “safe mode” (WASM modules execute in a sandboxed environment and can’t escape without going through appropriate APIs), and I add a graduated path toward stronger isolation for heavier demos using microVM- or VM-backed runtimes (Firecracker, Kata, gVisor) once supply-chain controls and ops maturity are in place. citeturn9search0turn4search13turn4search6turn4search15

Compliance is not a bolt-on; it is a design constraint. In the EU/Romania context, the portal’s baseline obligations map to GDPR, the EU AI Act, the DSA, the Interoperable Europe Act (and its implementing rules for interoperability regulatory sandboxes), plus public-sector accessibility expectations (Directive (EU) 2016/2102 and EN 301 549). citeturn1search1turn0search5turn0search2turn0search4turn2search3turn0search3turn0search7

Prioritized next ten concrete steps

1. I will publish the platform’s hard safety rules (default: no personal data; default: no outbound network; signed-only runnable artifacts; transparent takedown; vulnerability disclosure policy). citeturn1search2turn0search2turn1search1
2. I will adopt publiccode.yml as the minimum metadata gate and publish a versioned “portal superset” extension schema. citeturn2search0turn2search1turn6search2
3. I will implement ingestion as “metadata-first”: listings can exist as Listed before any runnable demo is allowed. citeturn2search0turn6search18
4. I will ship a WASM-first demo runner with deterministic quotas, no PII, default-deny egress, and per-demo isolation. citeturn9search0turn9search1
5. I will implement supply-chain controls: SBOM generation, provenance attestations (SLSA-style), and signing/verification using Sigstore. citeturn3search2turn3search12turn3search21turn1search2
6. I will define the trust ladder (Demo-safe → Pilot-verified → Production-adopted) as criteria + evidence artifacts, patterned after public-sector badge programs. citeturn6search8turn6search4
7. I will ship “pilot packs” (security/privacy/deployment/procurement notes) aligned with real public-administration acquisition processes that already prioritize reuse/open source (Italy provides a strong reference model). citeturn6search18turn6search2turn6search14
8. I will launch with Romania anchor categories (SSO/identity, payments, open data discovery) using official national platforms as “reference ecosystems” for what citizens already understand. citeturn5search5turn5search7turn5search10
9. I will implement DSA-style foundation mechanics: notice-and-action, moderation logging, and transparency reporting posture (scaled to size). citeturn0search2
10. I will pilot with at least one public institution and publish the outcomes as reusable, evidence-backed modules to move beyond “showcase” into “adoption engine.” citeturn0search4turn2search3turn6search8

Ecosystem scan

The reused-components ecosystem already exists, but it is fragmented between (a) catalogs that optimize for inter-administration reuse, (b) demo/sandbox systems that optimize for learning, and (c) community platforms that optimize for visibility rather than trust. Your portal’s differentiated value is composing these into a single, citizen-readable experience while staying compatible with EU reuse infrastructure. citeturn8search11turn2search2turn7search3

A credible global reference for “catalog + standards-driven eligibility” is entity["organization","Digital Public Goods Alliance","global dpg steward"]: its Digital Public Goods Standard defines what qualifies as a digital public good (open source software, open data, open AI models, open standards, open content; must adhere to privacy and other applicable laws and do no harm), and the DPG Registry emphasizes that listed goods have been reviewed against that standard and require reassessment over time. citeturn8search0turn8search5 This maps cleanly to your portal’s need for “trust tiers,” even if your scope and review process differ.

At EU level, entity["organization","Interoperable Europe Portal","eu interoperability platform"] positions itself as a one-stop shop for discovering, sharing, and reusing IT solutions and good practices across public administrations, businesses, and citizens. citeturn8search11turn8search7 The EU Open Source Solutions Catalogue is a concrete instantiation of that idea: it is a centralized platform to discover open-source solutions from public administrations, and its launch communications highlight scale, areas covered, and planned expansion. citeturn2search2turn2search9turn2search13

Europe also provides mature national patterns for metadata-driven catalogs:

• entity["organization","Developers Italia","public sector reuse italy"] provides reuse and publication guidance where publiccode.yml is required to populate the catalog, and the standard is intended to be usable by both developers and less technical audiences. citeturn6search18turn2search0turn2search4
• entity["organization","openCode","german public sector oss platform"] is positioned as a public-sector open source platform and automatically imports software directory entries from publiccode.yml; it also runs a badge program that evaluates projects on criteria related to security, maintenance, and reuse. citeturn6search4turn6search0turn6search8
• entity["organization","code.gouv.fr","french government oss unit"] supports government agencies increasing FOSS usage and publishing source code, and France maintains a government-recommended FOSS list (SILL) for public administration usage. citeturn6search9turn6search5turn6search1

A separate but relevant reference model is entity["organization","Foundation for Public Code","publiccode standard body"]: the Standard for Public Code frames what “good public codebases” look like (open, legible, accountable, accessible, sustainable), which is useful as governance criteria for your portal and for “Production-adopted” standards. citeturn7search0turn7search8

Romania has strong “anchor services” that citizens already recognize, and these anchors can be used to seed categorization and demonstrate immediate relevance. entity["organization","Autoritatea pentru Digitalizarea României","national digital authority romania"] describes operating essential digital platforms and implementing government cloud infrastructure. citeturn5search8turn5search19 Romania also has official, widely used citizen-facing platforms: data.gov.ro is the national open datasets portal; ROePAS is positioned as a single access point to services/procedures; ROeID is positioned as the national SSO solution for citizens’ digital interactions; and Ghișeul.ro is the state’s official online payment platform. citeturn5search10turn5search4turn5search5turn5search15

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["EU Open Source Solutions Catalogue Interoperable Europe screenshot","openCode platform Germany screenshot","ROePAS portal screenshot","Ghiseul.ro platform screenshot"],"num_per_query":1}

A cautionary-but-useful reference for your discovery UX is entity["company","Product Hunt","tech product discovery site"]: it explicitly frames launch discovery as a leaderboard driven by upvotes and engagement. citeturn7search2 That mechanism is valuable for “energy” and community flow, but it is insufficient for public-sector trust; your portal should treat popularity as a weak signal and trust artifacts as strong signals.

Product concept and information architecture

I design the portal as two interlocking surfaces: a “developer publishing surface” that is strict about metadata and runnable artifacts, and a “citizen and institution surface” that is strict about legibility, safety, and evidence. The Standard for Public Code provides a useful value lens: public code should be usable, open, legible, accountable, accessible, and sustainable. citeturn7search0turn7search8

The information architecture should start from citizen mental models (“I need to do X”) rather than internal government org charts. Romania’s ROePAS framing (“services and documents you need” in one place) is a strong pattern that citizens already understand. citeturn5search4turn5search0 Therefore, I suggest a top navigation that stays stable across countries and institutions:

• Life events and tasks (citizen-first): pay, identify/authenticate, request certificates, permits, report issues, transparency/open data, benefits. citeturn5search7turn5search5turn5search10
• Building blocks (system-first): identity/SSO, payments, forms, document processing, workflow, notifications, data exchange/interop. The GovStack sandbox exists because government services often assemble from reusable building blocks, and the Interoperable Europe ecosystem explicitly supports reusable solutions. citeturn7search3turn8search11turn8search3
• Demos (safety-first): runnable, non-destructive, synthetic-data, read-only by default. citeturn9search0turn1search1
• Adoption evidence (institution-first): pilot packs, deployments, “used by,” compliance artifacts. Italy’s reuse publication and acquisition guidance provides the operational template for how administrations want evidence and comparability. citeturn6search18turn6search2turn6search14

Personas must map to these surfaces:

Developers need fast onboarding (“submit a repo + publiccode.yml + demo artifact”) and clear value (visibility, adoption pipeline). citeturn6search18turn6search10 Citizens need “what it does, can I try it safely, is it used by government, where do I report issues” in two screens. citeturn5search4turn8search11 Institutions and evaluators need non-negotiable artifacts: license clarity, security posture, privacy posture, deployment notes, and support model. citeturn6search18turn1search2turn1search1

Taxonomy and metadata design

A portal like this will fail if metadata is optional. A recurring European success pattern is that catalogs become useful once they are machine-indexable and consistent. publiccode.yml is explicitly designed as a metadata standard for repositories of software developed or acquired by public administrations, aimed at making them discoverable and reusable. citeturn2search0turn2search1turn8search14

Operational precedents matter: publiccode.yml is mandatory for public software developed in Italy and supports catalog crawling/building; openCode’s directory depends on valid publiccode.yml files; and the Interoperable Europe Portal promotes publiccode.yml as a standard for documenting and sharing public-sector open source. citeturn6search2turn6search0turn6search6

I recommend a “publiccode.yml superset” via a versioned extension, not by forking the standard. The Italian documentation explicitly notes interoperability goals and a separation between core keys and country-specific keys, which is the right design principle for a portal that might later federate with EU catalogs. citeturn2search4turn2search0 In addition, EU catalog ecosystems are increasingly structured around publiccode.yml as the “catalog contract.” citeturn2search12turn2search9

Proposed metadata extension fields

I treat the following as “must-have extensions” because your portal hosts runnable demos and AI-adjacent tools; catalogs that do not execute code can omit most of these.

• Demo/runtime descriptor: demo.runnable, demo.sandboxProfile, demo.egressPolicy, demo.dataPolicy, quotas, and session lifecycle. This enforces your “demo-safe” badge in a machine-checkable way. citeturn9search0turn2search3
• Security artifacts: SBOM location/format, provenance/attestation, signature verification policy. NIST SSDF explicitly treats artifact integrity, provenance, and vulnerability response as core secure development practices. citeturn1search2turn3search2turn3search12turn3search21
• Privacy declarations: data categories, retention, DPIA status if relevant, whether personal data is processed. GDPR obligations around lawful processing and DPIA risk evaluation dictate that privacy posture is not optional if any personal data appears in pilots or production deployments. citeturn1search1
• AI disclosure: whether AI is used, model source/type, known limitations, and an “AI Act risk hints” section intended as a disclosure artifact (not a formal legal classification). The EU AI Act creates obligations that vary by risk category, so structured disclosure reduces institutional uncertainty and improves safe adoption. citeturn0search5turn0search1
• Adoption evidence: pilots, references, support model. Developers Italia and other reuse catalogs demonstrate that software reuse becomes real when publication metadata and adoption pathways are explicit. citeturn6search18turn6search10

Trust and badge ladder

Public-sector tool discovery needs trust signals that are both legible and evidence-backed. A strong EU precedent is that badges can be generated from objective criteria and displayed in a software directory to communicate qualities such as security, maintenance, and reuse. citeturn6search8turn6search4

I recommend a ladder that allows early-stage innovation without pretending early-stage artifacts are “production safe.” The DPG Registry demonstrates that “review against a standard” can be a public trust mechanism and that compliance must be periodically reassessed, which is a useful governance concept for your higher badge tiers. citeturn8search5turn8search0

Trust badge ladder

Badge	Intended audience meaning	Minimum objective criteria	Evidence artifacts
Listed	“This exists and is described consistently.”	Valid publiccode.yml + portal extension; clear license; maintainer contact	Metadata validation output; LICENSE reference citeturn2search0turn6search18
Demo-safe	“I can try this without risking my data.”	Runs in constrained sandbox; synthetic data default; default-deny egress; time/memory quotas	Demo manifest; sandbox policy; runtime logs summary citeturn9search0turn2search3
Supply-chain verified	“The runnable artifact is verifiable.”	SBOM generated; provenance attested; signed artifacts; signature verified at run time	SBOM (SPDX/CycloneDX); provenance; Sigstore signature record citeturn3search2turn3search11turn4search4turn3search21turn3search0
Pilot-verified	“A public institution tested it in a scoped pilot.”	Pilot report + scope + metrics; DPIA note if personal data; incident channel	Pilot pack; DPIA summary if applicable; deployment notes citeturn6search18turn1search1turn2search3
Production-adopted	“This is used for real service delivery.”	Named deployment(s); support model; change management and security reporting expectations	Public deployment evidence; support/SLA statement; security update policy citeturn7search0turn1search2

I treat “Supply-chain verified” as non-optional for running third-party artifacts at scale because SSDF emphasizes protecting releases and responding to vulnerabilities as core practices, and modern SBOM + signing ecosystems exist exactly to reduce supply-chain risk. citeturn1search2turn3search6turn3search21

Legal and compliance analysis for EU and Romania

I assume the portal is a platform hosting third-party submissions and allowing interaction/testing; therefore, compliance is a system constraint across listing, demos, moderation, analytics, and adoption workflows.

GDPR is central because even if demos are synthetic-only, the portal will process some personal data (accounts, feedback, logs) unless explicitly designed to avoid it. GDPR sets the baseline for lawful processing, transparency, data minimization, security, and DPIA requirements where processing creates high risks. citeturn1search1 I recommend “no-login demo mode” wherever possible to reduce GDPR surface, and “data protection by default” patterns for everything else. citeturn1search1

The EU AI Act introduces obligations for AI systems depending on their use and risk category; for a govtech portal, the highest-risk scenario is tools used in public-sector decision workflows or affecting rights and access to services. citeturn0search5turn0search1 I therefore recommend mandatory AI disclosures in metadata (model source/type, limitations, oversight expectations) and stronger badge criteria for any AI that touches eligibility, allocation, or enforcement decisions. citeturn0search5turn1search2

The DSA matters because the portal will host user-generated submissions and content; the regulation defines obligations for hosting services and online platforms, including notice-and-action, transparency, and constraints around how moderation decisions are handled and documented. citeturn0search2 I recommend implementing moderation workflows and transparency reporting from day one, even if the portal is not “very large,” because retrofitting those workflows later is costly and undermines trust. citeturn0search2

The Interoperable Europe Act matters because it frames a Union-scale governance mechanism for public-sector interoperability and expects solutions, collaboration, and feedback mechanisms to exist within the Interoperable Europe ecosystem. citeturn0search4turn8search11 Its implementing regulation for interoperability regulatory sandboxes is directly relevant to your pilot and sandbox approach: it treats sandboxes as places to experiment with innovative interoperability solutions and includes constraints about personal data processed in sandbox projects not being reused as operative data outside the project without proper legal basis. citeturn2search3turn2search17 I recommend aligning your “Pilot-verified” badge and pilot-pack templates with these operational expectations so that administrations can reuse your documents if they later enter formal interoperability sandbox programs. citeturn2search3turn0search4

Accessibility is not optional for a citizen-facing portal. Directive (EU) 2016/2102 sets accessibility requirements for public sector websites and apps, and EN 301 549 provides testable requirements and methodologies, explicitly mapping requirements relevant to the directive. citeturn0search3turn0search7 I recommend treating basic conformance checks as a release gate for the portal UI and as part of “Production-adopted” criteria for citizen-facing tools. citeturn0search7turn7search0

Romania-specific context is favorable for “anchor categories” and partnerships because ADR positions itself as operating essential digital platforms and the government ecosystem already has recognizable citizen touchpoints: ROePAS (single access point), ROeID (SSO), Ghișeul.ro (payments), and data.gov.ro (open data). citeturn5search8turn5search4turn5search5turn5search7turn5search10

Secure sandbox architecture and the CI build-scan-run-observe pipeline

Hosting runnable tools changes the threat model from “catalog integrity” to “multi-tenant untrusted code execution.” I therefore design the platform as a secure software supply-chain system plus a sandbox execution system, not a typical web app.

Sandbox runtime comparison

Runtime option	Isolation mechanism (what it actually protects)	Best fit for this portal	Primary operational risks
WASM (WASI/capability-based)	Each module executes in a sandbox and can’t escape without host APIs; capability model can restrict filesystem/network/time. citeturn9search0turn9search1	Default demo mode: calculators, form assistants, policy simulators, transformations, lightweight AI helpers	Capability misconfiguration; runtime vulnerabilities; “unsafe guest code” inside sandbox
gVisor	Application kernel that moves kernel interfaces into a per-sandbox layer to reduce container escape risk. citeturn4search15turn4search7	Mid-tier Linux compatibility without full VM overhead for containerized demos	Syscall compatibility, performance tuning, operational complexity
Kata Containers	Lightweight VMs that “feel like containers” but add hardware-virtualization isolation as a second layer of defense. citeturn4search6turn4search2	High-risk demos requiring near-standard Linux userland and stronger workload isolation	VM image management, perf footprint, cluster tuning
Firecracker microVM	MicroVMs combine VM isolation with speed/efficiency; designed for secure multi-tenant workloads. citeturn4search13turn4search1	Strong isolation for untrusted full-stack demos; good for “per-session disposable environments”	MicroVM orchestration and lifecycle complexity; image and kernel maintenance

I treat WASM as the MVP default because it offers strong default sandbox semantics and a frictionless developer and citizen experience for many civic tool categories. citeturn9search0turn9search4 I treat Firecracker/Kata as necessary later stages for heavier workloads, because they target stronger isolation for multi-tenant execution, which becomes essential as the portal scales or hosts more complex demos. citeturn4search13turn4search6

Supply-chain controls: SLSA, SBOM, Sigstore, SSDF

NIST SSDF is a primary reference for secure software development practices and explicitly targets reducing vulnerabilities through organizational preparation, protecting software, producing well-secured software, and responding to vulnerabilities. citeturn1search2turn1search11 I use SSDF as the “policy backbone” for your platform’s CI rules and vulnerability processes.

I require SBOMs because the NTIA “minimum elements” approach frames SBOMs as formal records of software components and relationships and defines a baseline of fields/operational practices; SPDX is an international open standard (ISO/IEC 5962:2021) and CycloneDX is standardized via ECMA-424 and supports inventory information including ML models and other artifacts relevant to modern supply chains. citeturn3search6turn3search11turn4search4

I require provenance because SLSA treats provenance as verifiable information describing how artifacts were produced, supporting stronger integrity guarantees as maturity increases. citeturn3search12turn3search0

I require signing and verification because Sigstore describes a keyless approach that binds ephemeral keys to identities via short-lived certificates and logs signing events in a transparency log, enabling verification and auditing at scale. citeturn3search21turn3search1

CI/build/scan/run/observe pipeline

The portal’s policy must be: if it runs, it is built, attested, and signed. This is consistent with SSDF’s emphasis on protected releases and vulnerability response, and it is operationally enabled by SBOM/provenance/signing tooling. citeturn1search2turn3search6turn3search0turn3search21

flowchart LR
  A[Source Repo or Upload] --> B[Metadata Gate: publiccode.yml + extension lint]
  B --> C[Build in Isolated CI Runner]
  C --> D[Generate SBOM]
  C --> E[Generate Provenance Attestation]
  D --> F[Dependency + vuln scan]
  E --> G[Policy checks: build integrity]
  F --> H[Sign & attest artifacts]
  G --> H
  H --> I[Publish to OCI registry]
  I --> J[Admission Control: verify signature+attestation]
  J --> K[Sandbox Run: WASM/gVisor/Kata/Firecracker]
  K --> L[Observe: logs/metrics/traces]
  L --> M[Badge Evaluation + publish demo]
  M --> N[Ongoing vuln intake + revocation path]

I treat the runtime layer as “default deny”: no outbound network unless explicitly allowlisted; read-only filesystems; no system credentials; time/memory quotas; and per-session destruction. WASM and sandboxed container runtimes are explicitly positioned as isolation technologies for untrusted code, so the design should continuously minimize the host and network attack surface reachable from a demo. citeturn9search0turn4search15turn4search13

Reference architecture

flowchart TB
  subgraph Portal
    UI[Citizen UI + Dev UI]
    API[API + Auth (minimal)]
    DB[(Catalog DB)]
    IDX[(Search Index)]
  end

  subgraph SupplyChain
    CI[Isolated CI Builders]
    REG[(OCI Registry)]
    SBOM[(SBOM Store)]
    ATTEST[(Attestation Store)]
    SIG[Signature & Transparency Log]
  end

  subgraph Sandbox
    ORCH[Sandbox Orchestrator]
    WASM[WASM Runner]
    CRTL[Policy Engine: egress/quotas]
    HV[High Isolation Pool: gVisor/Kata/Firecracker]
    OBS[Observability Stack]
  end

  UI --> API
  API --> DB
  API --> IDX

  API --> CI
  CI --> REG
  CI --> SBOM
  CI --> ATTEST
  CI --> SIG

  REG --> ORCH
  ORCH --> CRTL
  CRTL --> WASM
  CRTL --> HV
  ORCH --> OBS
  API --> OBS

I keep this architecture vendor-neutral by specifying interfaces (OCI registry, attestations, SBOM formats) rather than cloud-specific services, which supports the no lock‑in assumption and aligns with EU reuse ecosystems focused on interoperability. citeturn8search11turn2search2turn4search4

Adoption pathway, sustainability, roadmap, and risk register

Catalogs become adoption engines only when they reduce evaluation workload for administrations. Italy provides a concrete model for how administrations evaluate and acquire software with a preference for reuse and open source, and Developers Italia provides guidance on publication and acquisition processes. citeturn6search18turn6search2turn6search14 I mirror that pattern with “pilot packs” and badge evidence.

Pilot packs for administrations

I package each Pilot-verified candidate with:

A deployment pack (IaC manifests, architecture diagram, minimum infrastructure), a security pack (SBOM + provenance + signature verification policy + scan results), a privacy pack (data categories + retention + DPIA template outcome if relevant), and an evaluation pack (scope, metrics, rollback plan, support model). SSDF’s structure provides a credible backbone for the security and vulnerability response portions of these packs. citeturn1search2turn3search6

In Romania, I prioritize pilots that integrate with already-recognized national primitives (SSO, payments, open data) because they reduce behavioral friction and demonstrate immediate value: ROeID, Ghișeul.ro, and data.gov.ro provide the citizen-understood baseline for those primitives. citeturn5search5turn5search7turn5search10

Sustainability and monetization

I keep discovery, listing, and “demo-safe” testing free to preserve credibility and community growth. I monetize operational burden and institutional requirements: dedicated environments, managed deployment support, security/compliance services, private pilot sandboxes, and enterprise connectors. This “charge for operations, not openness” posture remains aligned with public-sector open source strategies and avoids pay-to-win distortions that would undermine trust. citeturn7search0turn6search8turn1search2

Monetization option	Mostly-free compatibility	Typical buyer	What I deliver
Managed enterprise tenant	High	Agencies/municipalities	Dedicated portal instance, SSO, audit logs, backups
Private pilot sandbox	High	Agencies piloting with sensitive integration	Isolated runtime + allowlisted connectors + strict governance
Security/compliance service	Medium–high	Implementers and agencies	SBOM/provenance/signing setup, pentest coordination, DPIA support
Support marketplace	Medium	Builders and institutions	Paid support contracts around open projects

Phased roadmap

The Interoperable Europe ecosystem demonstrates that catalogs can scale, but runnable demo hosting requires additional controls; therefore, I stage runtime complexity behind trust maturity. citeturn2search9turn1search2turn6search8

gantt
  title GovTech Commons Portal Roadmap (Assumed Start: 2026-04-06)
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section MVP Foundation
  Governance + schemas + policies            :a1, 2026-04-08, 30d
  Catalog + search + citizen tool pages      :a2, after a1, 45d
  WASM demo runner (demo-safe only)          :a3, after a1, 45d

  section Trust and supply chain
  SBOM + signing + provenance baseline       :b1, after a2, 45d
  Badge ladder v1 (Listed + Demo-safe)       :b2, after a2, 30d

  section Pilot readiness
  Pilot pack templates + first pilots        :c1, after b1, 60d
  Upgrade runner tier (gVisor/Kata/microVM)  :c2, after c1, 60d

  section Scale and federation
  Federation/export feeds to EU patterns     :d1, after c2, 60d
  Production-adopted governance + audits     :d2, after c2, 90d

Risk register with mitigations

I focus on risks that are unique to “runnable demos + citizens + public administration trust.”

Risk	Why it matters	Mitigation (design constraint)
Untrusted code escape or host compromise	Runnable demos are attacker-controlled inputs	WASM-first; stronger isolation tiers; signed-only artifacts; default-deny egress; quotas; per-session destruction citeturn9search0turn4search13turn1search2
Supply-chain compromise	Open source does not mean safe	SBOM + provenance + signing; admission control verifies signatures/attestations citeturn1search2turn3search6turn3search0turn3search21
GDPR exposure through telemetry	Logs and analytics can become personal data	No-login demos; minimize identifiers; DPIA gating; retention limits citeturn1search1
Moderation/legal exposure under DSA	User-submitted content triggers platform duties	Notice-and-action workflow; decision logs; transparency posture citeturn0search2
AI misuse in public services	AI outputs can affect rights	Mandatory AI disclosures; stricter badges for decision-affecting tools citeturn0search5
Accessibility debt	Excludes citizens; harms public-sector credibility	Portal UI gates; EN 301 549-aware checks; accessibility as adoption criterion citeturn0search3turn0search7
“Popularity beats safety” dynamic	Hype can override evidence	Separate ranking: community signal vs trust score; restrict promo features citeturn7search2turn6search8
Project abandonment	Catalog fills with dead prototypes	Maintenance badge criteria; lifecycle dates; automated stale warnings citeturn6search8turn1search2
Vendor lock-in creep	Undermines the platform’s public-good posture	OCI artifacts, open schemas, export feeds; no proprietary runtime dependence citeturn4search4turn2search2

Notes on unspecified details

The exact procurement integration mechanism in Romania is unspecified; I therefore assume the portal will provide evidence packs and support pathways but will not initially function as a procurement platform. citeturn6search18turn6search14 The currency for budget ranges is unspecified by request, so I keep costs as ranges without currency.

File B (implementation plan + launch checklist + stack): implementation-plan-and-launch-checklist.md

Purpose (in first person): I will implement a safe, OSS-first portal MVP in 8–12 weeks that can list projects immediately and run “demo-safe” tools without exposing citizen data or my infrastructure.

Assumptions (explicit): I assume EU/Romania focus, no vendor lock-in, “mostly free” public access, and that I already have baseline hardware and ops capacity; currency is unspecified.

Recommended technical stack (vendor-neutral):

• Frontend: Next.js (SSR + static generation) or equivalent; strong accessibility baseline aligned to EN 301 549 expectations. citeturn0search7turn0search3
• Backend API: FastAPI or Node (NestJS); Postgres (catalog), OpenSearch/Meilisearch (search).
• Artifact format: OCI artifacts (containers and/or WASM bundles) stored in an OCI registry.
• CI: GitHub Actions or GitLab CI with isolated self-hosted runners; policy: only signed artifacts can run. citeturn1search2turn3search21
• SBOM: SPDX and/or CycloneDX (store and display). citeturn3search11turn4search4
• Provenance: SLSA-style provenance attestations stored alongside artifacts. citeturn3search0turn3search12
• Signing: Sigstore (Cosign + transparency log behavior). citeturn3search21turn3search1
• Sandbox orchestrator: Kubernetes + policy engine; MVP runner is WASM, with a later tier for gVisor/Kata/Firecracker. citeturn9search0turn4search15turn4search6turn4search13
• Observability: OpenTelemetry + Prometheus + centralized logs with strict retention.

Roles I will assign (responsibilities):

• Product lead (PL), Tech lead (TL), Security lead (Sec), SRE/DevOps (SRE), UX/content (UX), Community/partnerships (Comms), Legal/privacy (Legal).

MVP scope (8–12 weeks, in first person):

• I will ship the catalog with strict metadata gates (publiccode.yml + extension). citeturn2search0turn6search18
• I will ship citizen-readable pages that expose the trust badge and “data used” in plain language. citeturn7search0turn1search1
• I will ship a WASM demo runner with default-deny egress and synthetic data. citeturn9search0turn9search1
• I will ship badge ladder v1: Listed + Demo-safe, with automatic criteria checks. citeturn6search8
• I will ship DSA-aligned minimum moderation and reporting mechanics (report button, takedown workflow, logs). citeturn0search2

Launch checklist (complete, assigned, with effort and minimal budgets; currency unspecified):

Area	Checklist item (I will…)	Owner	Effort (person-months)	Minimal budget range
Governance & legal	publish Terms/Acceptable Use + demo disclaimers	Legal	0.30	0–1k
Governance & legal	publish privacy notice + retention policy + DPIA template	Legal	0.40	0–2k
Governance & legal	publish security policy + coordinated vulnerability disclosure	Sec	0.30	0–1k
Governance & legal	implement DSA-style notice-and-action workflow + logging	Legal+Comms	0.50	0–2k
Metadata	implement publiccode.yml validator + portal-extension schema v0.1	TL	0.60	0–1k
Metadata	create project templates (sample publiccode.yml + extension)	TL+UX	0.30	0–1k
Catalog	implement catalog DB + search index + filters	TL	0.70	0–2k
Catalog	build citizen tool page template (plain language, evidence, demo link)	UX	0.50	0–2k
Demo sandbox	harden WASM runtime profile (no net, RO FS, quotas)	Sec+SRE	0.80	0–3k
Demo sandbox	implement demo packaging + upload/attach flow	TL	0.60	0–2k
Demo sandbox	implement sandbox admission control (signed-only runnable)	Sec	0.60	0–2k
Supply chain	generate SBOM automatically on build	Sec	0.50	0–2k
Supply chain	create provenance attestations (baseline)	Sec	0.50	0–2k
Supply chain	implement Sigstore signing + verification	Sec+SRE	0.70	0–3k
Scanning	implement SCA/SAST/secrets scanning + thresholds	Sec	0.60	0–2k
Trust badges	implement badge rules engine + UI display	TL+Sec	0.70	0–2k
Observability	deploy metrics/logs with retention rules	SRE	0.60	0–2k
Accessibility	run accessibility audit aligned to EN 301 549 expectations	UX	0.30	0–2k
Content seeding	seed 30–50 quality listings with 10 runnable demos	Comms+PL	0.80	0–3k
Partnerships	secure 2–3 pilot institutions (letters/MoU)	Comms+PL	0.60	0–5k
Pilot readiness	ship pilot pack templates (security/privacy/deploy/eval)	PL+Sec+Legal	0.90	0–3k
Launch ops	run a pre-launch security review + emergency rollback plan	Sec+SRE	0.50	0–5k

Minimal operating rule (I will enforce): No demo runs unless it is buildable, scanned, attested, and signed, and unless it fits an explicit sandbox profile. citeturn1search2turn3search21turn9search0

English multi-AI review prompt (single prompt for Gemini/Claude/GLM/GPT; compare, merge, consolidate):

You are an expert reviewer panel. Review the attached plan for an EU/Romania-first open-source govtech portal that lists and hosts runnable civic/AI demos with a trust badge ladder and hardened sandboxes.

Your output must be structured as:
1) Top 10 critical gaps (explain impact and urgency).
2) Security critique: sandbox isolation (WASM, gVisor, Kata, Firecracker), multi-tenancy threats, egress control, secret handling, artifact admission control.
3) Supply-chain critique: SSDF alignment, SLSA provenance, SBOM formats (SPDX/CycloneDX), Sigstore signing/verification, revocation and vulnerability response.
4) Compliance critique: GDPR, EU AI Act, DSA duties, Interoperable Europe Act + sandbox implementing rules, accessibility (Directive 2016/2102 + EN 301 549). Identify what is missing and propose concrete mitigations.
5) Product critique: IA, personas, citizen legibility; recommend simplifications for an 8–12 week MVP.
6) Feasibility: what to cut, what to keep, and what to sequence to ship safely.
7) Risk register: add 10 additional risks with mitigations.

Comparison rules:
- For each disagreement with the baseline, label it as (Correction / Enhancement / Alternative).
- Conclude with “Merged Plan Delta” containing:
  KEEP (items you agree with),
  CHANGE (replace with your wording),
  ADD (missing items),
  REMOVE (what to drop and why).

Constraints:
- Assume attackers will submit malicious demos.
- Default posture must be deny-by-default (network, filesystem, identity).
- No vendor lock-in.
- Prefer primary/official sources when making factual claims.

Short Romanian prompt for other AIs (as requested):

Fă o versiune mai simplă și mai acționabilă a acestui plan, potrivită pentru un MVP de 8–12 săptămâni; evidențiază 6 pași concreți și 5 reguli de siguranță; returnează un "Merged Plan Delta" comparând cu planul original.