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

# GovTech Commons Portal for AI and Civic Tools

## Executive summary

A citizen-friendly govtech aggregator that *hosts runnable demos and MVPs* can become a practical accelerator for digitalization—if it behaves less like a “showcase website” and more like a **trusted, inspectable distribution channel** with a **security-first sandbox**, **standardized metadata**, and a **clear trust ladder**. The window is good in the entity["organization","European Union","supranational union"] because reuse infrastructure has matured (e.g., the EU Open Source Solutions Catalogue launched in 2025 and is expanding to include more individual modules and libraries), and public-sector metadata standards like publiccode.yml are already operational at national scale (Italy) and being adopted across Europe. citeturn6search8turn6search1turn6search0turn5search12turn5search0

A “foolproof” plan is less about a perfect product spec and more about **enforceable constraints**: (1) demo environments that default to **no personal data and no outbound network**; (2) **supply-chain controls** (SBOM + provenance + signing) on everything that runs; (3) a **badge system** that makes risk legible to normal citizens while also giving administrations procurement-grade evidence; and (4) governance rules that map cleanly to EU obligations (GDPR, DSA, AI Act, accessibility). citeturn15view1turn12view1turn19view2turn33view1turn26view2turn34search6turn34search0

The portal should be open source end-to-end (code + policy + schemas), but operationally it must behave like a **multi-tenant platform**. That means treating every uploaded demo/tool as untrusted until proven otherwise, and *never* letting “it’s open source” substitute for verification. This aligns with the direction of NIST SSDF (secure-by-design practices, provenance/SBOM, and controlled build/release processes) and modern supply-chain frameworks like SLSA and Sigstore. citeturn26view0turn26view2turn34search18turn34search0turn34search6

### Prioritized next ten steps

1. Define the portal’s **scope boundaries** and “hard rules” (no citizen PII in demos by default; sandbox profiles; outbound network policy; takedown policy). citeturn21view0turn12view1turn15view1  
2. Adopt **publiccode.yml as the base**, and publish a **superset schema** (govtech + AI + security + privacy + demo runtime descriptors). citeturn5search12turn5search0turn6search4  
3. Implement ingestion as “metadata-first”: publiccode.yml validation + minimal listing before any runnable demo. citeturn5search15turn5search5  
4. Build the initial trust ladder and badges (Demo-safe → Pilot-verified → Production-adopted) with objective criteria and required artifacts (SBOM, signatures, docs). citeturn34search6turn26view2turn3search10  
5. Stand up a secure demo runner MVP using **Wasm-first** (safe-by-default, low cost) + plan for microVM expansion for heavier workloads. citeturn2search0turn2search1turn2search2  
6. Establish CI policy: reproducible builds, SBOM generation, signing/attestations, baseline SAST/SCA, and publish-only-signed artifacts. citeturn34search6turn34search0turn3search16turn26view2  
7. Create “pilot packs” that administrations can evaluate quickly (security pack, DPIA pack, deployment pack, procurement notes). citeturn6search7turn15view1turn21view0  
8. Launch with 2–3 Romanian “anchor” categories (payments, identity, open data) and invite projects that already exist in the ecosystem to list. citeturn7search8turn7search33turn7search5turn0search3  
9. Formalize governance: maintainers, security response process, moderation/DSA workflow, and transparent metrics/reporting. citeturn12view3turn5search10  
10. Run a first cohort: “one-click pilot hack-week” with at least one city/agency partner and publish results as reusable modules. citeturn21view1turn6search5  

## Ecosystem scan with actionable patterns

Europe already provides “parts of the stack” you want, but split across multiple initiatives; the opportunity is to **compose** them into a single citizen-readable experience while staying compatible with EU reuse infrastructure.

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["EU Open Source Solutions Catalogue Interoperable Europe Portal screenshot","Developers Italia software reuse catalog screenshot","openCode Germany software directory screenshot","code.gouv.fr Free Software unit screenshot"],"num_per_query":1}

The EU OSS Catalogue—hosted via the Interoperable Europe Portal—was launched in 2025 to help public administrations discover and reuse OSS solutions, and is evolving to include more individual components and libraries beyond federated national catalogues. citeturn6search8turn6search1turn6search0turn6search5

Italy is the strongest “operational reuse” reference model: publiccode.yml is mandatory for public software developed in Italy, and is used to populate the national catalogue via automated crawling; the standard is explicitly intended to be understandable for both technical and non-technical audiences. citeturn5search15turn5search5turn5search12turn5search0

Germany’s openCode demonstrates a second important pattern: a platform-level badge program that communicates security/maintenance/reuse qualities of listed projects, and a “publiccode.yml as gate” approach for the directory. citeturn5search2turn5search6turn5search20

France’s code.gouv.fr shows a central government unit supporting publishing source code and increasing free/open-source usage across administrations, with an explicit action plan and catalog references (e.g., SILL list). citeturn5search3turn5search9turn5search36

At the EU institutional level, the entity["organization","European Commission","eu executive"] adopted an internal open source software strategy (2020–2023) positioning open source as a key lever for internal processes and collaboration, reinforcing that public-sector OSS is not “experimental” but mainstreamed. citeturn9search3turn9search5turn9search9

Globally, the entity["organization","Digital Public Goods Alliance","un multi-stakeholder initiative"] provides a registry-shaped pattern: a public listing that is anchored in a formal standard and verification process, oriented to public-benefit digital goods. This is directly relevant to your portal’s “trust layer,” even if your scope is narrower (EU/Romania civic tools rather than all DPG categories). citeturn0search0turn0search5

For sandboxed experimentation and “building blocks,” GovStack’s sandbox concept is an example of a shared environment to test digital government components, which aligns with the Interoperable Europe Act’s push toward interoperability solutions and regulatory sandboxes. citeturn0search1turn21view1turn23view1

Romania has real anchor services that can seed your portal and make it immediately legible to citizens and administrations: entity["organization","Autoritatea pentru Digitalizarea României","national digital agency ro"] has announced ROePAS as a single access point for digital public services; Romania operates the national online payment system Ghișeul.ro (officially operated by ADR); the national open data portal data.gov.ro acts as a central access point for open datasets; and the national digital identity SSO solution ROeID is positioned for citizen authentication across services. citeturn0search3turn7search8turn7search5turn7search33turn7search1

## Product concept and information architecture

The portal should be designed as **two interlocking products**:

A. A developer-facing “govtech GitHub layer” that standardizes publication and reproducibility (metadata, builds, attestations).  
B. A citizen-facing “app gallery layer” that translates that evidence into **plain-language trust signals** and safe demos.

This two-layer model matches how public-sector reuse initiatives already operate: machine-readable metadata (publiccode.yml) for indexing and discoverability, plus human-friendly presentation and governance. citeturn5search12turn5search0turn6search4turn21view0

### Personas and primary journeys

Developers: need a fast path from repository → listing → demo. They respond to low-friction onboarding (automated linting, templates, GitHub/GitLab integration) and strong incentives (visibility, interoperability adoption). This is consistent with publiccode.yml’s goal of being discoverable and understandable across audiences. citeturn5search12turn5search15

Citizens: want simple answers: “What does it do?”, “Is it safe to try?”, “Is the state using it?”, “Can I report an issue?”. The Interoperable Europe Act explicitly expects portals to be accessible to all citizens and to allow citizen feedback. citeturn21view0turn21view1

Institutions and evaluators: need procurement-grade artifacts and low-risk pilot pathways. Italy’s public administration acquisition guidance explicitly privileges open source/reuse and mandates comparative evaluation, providing a model for “evaluation packets” that your portal can pre-assemble. citeturn6search7turn6search3turn6search10

### Information architecture

A practical IA that maps to how citizens think, while still indexing like a catalog:

Top-level navigation:  
- **Services** (citizen tasks): pay, identify, request documents, permits, reporting, transparency, benefits.  
- **Building blocks** (for institutions/devs): identity, payments, forms, document processing, notifications, workflow, interoperability, AI assistants, search.  
- **Demos** (safe sandbox): runnable, read-only by default.  
- **Adoption**: pilots, deployments, case studies, “used by” listings.  
- **Standards & trust**: badges, compliance, security model, reporting.

This aligns with the EU OSS Catalogue’s framing as a centralized platform to discover OSS solutions for public administrations. citeturn6search0turn6search5

### Metadata and taxonomy: publiccode.yml superset

publiccode.yml is already a Europe-aligned, public-administration-oriented metadata standard intended to make software discoverable and understandable for technical and non-technical users. citeturn5search12turn5search0

A portal like yours should treat publiccode.yml as the “minimum contract,” and extend it with an explicit, versioned **govtech extension**. Suggested additional fields (conceptually; adapt naming to YAML conventions):

- **demo**: `runnable: true/false`, `sandboxProfile: wasm|container|microvm`, `internet: none|egress-allowlist`, `piiPolicy: synthetic-only|no-storage|user-provided`, `maxRuntimeSeconds`, `resources`.  
- **security**: `sbom: SPDX|CycloneDX + artifact ref`, `provenance: SLSA predicate ref`, `signing: sigstore|key-based`, `vulnPolicy: thresholds`, `pentest: date/summary`.  
- **privacy**: `dataCategories`, `controller/processor`, `dpia: link/ref`, `retention`, `dpaAvailable`.  
- **ai** (if applicable): `aiUsed: yes/no`, `modelType`, `modelSource`, `riskClassHint`, `humanOversight`, `limitations`, `knownFailureModes`.  
- **adoption**: `usedBy`, `pilots`, `productionDeployments`, `supportModel`.  
- **interoperability**: `standards`, `apis`, `openapi`, `eventSchemas`, `exportFormats`.

Why these are “load-bearing”: the EU OSS Catalogue uses publiccode.yml as its reference specification and requires a valid publiccode.yml for onboarding—so building your superset as a compatible extension keeps you future-proof and interoperable with EU catalog infrastructure. citeturn6search4turn6search0turn5search0

## Trust, badges, governance, and transparency

Trust must be expressed as a ladder because a “single trust stamp” fails both citizens (too vague) and institutions (not evidence-based). The openCode badge program illustrates how criteria-based badges can communicate security/maintenance/reuse qualities. citeturn5search6turn5search2

### Trust badge ladder

The ladder below is designed so that (a) early-stage projects still get listed; (b) runnable demos are gated by sandbox security; and (c) administrations can identify “pilot-ready” candidates quickly.

| Badge level | What it means | Minimum evidence required |
|---|---|---|
| Listed | discoverable entry | valid publiccode.yml; license; contacts; short citizen description citeturn5search15 |
| Demo-safe | runnable in constrained sandbox | no PII default; sandboxProfile declared; security scans pass; clear limitations |
| Verified supply chain | artifacts are verifiable | SBOM (SPDX/CycloneDX); signed artifacts; provenance/attestation (SLSA-style) citeturn3search5turn3search2turn34search6turn34search0 |
| Pilot-verified | tested with a public body in controlled scope | pilot report; DPIA summary if personal data; deployment notes; incident channel citeturn15view1turn23view1 |
| Production-adopted | used in real service delivery | named deployments; uptime/SLO disclosure; support model; change management summary |

Supply-chain “verified” is not optional if you host runnable artifacts: modern guidance emphasizes SBOM/provenance, and NIST SSDF explicitly calls out collecting and sharing provenance data, including SBOMs, as part of protecting releases. citeturn26view2turn3search10turn34search0

### Governance model that fits open source and EU reality

A minimal model that avoids “governance theater”:

- Maintainers + technical steering group (open, recorded decisions).  
- Security response team (private intake, coordinated disclosure, SLA).  
- Moderation team (DSA-aligned notice/takedown, transparency reports). citeturn12view1turn12view3  
- Public schema governance (versioned metadata extension; deprecation policy).

This is consistent with the Standard for Public Code’s emphasis on accountable, sustainable collaboration for public codebases. citeturn5search10turn5search34

## Legal and compliance map for EU and Romania

This portal is a “compliance intersection”: it hosts software listings + potentially user-generated content + runnable demos + AI-related disclosures.

### GDPR and privacy by design

If demos collect or process personal data, GDPR obligations trigger immediately (lawful basis, minimization, security measures, transparency). GDPR requires data protection by design and by default and requires DPIAs for processing likely to result in high risk, including certain profiling/large-scale scenarios. citeturn15view0turn15view1turn14view2

Design implication: your default demo posture should be **no personal data** (synthetic datasets; no account creation to try demos; no persistent storage unless strictly necessary). This also aligns with Interoperable Europe portal constraints that solutions accessible through the portal should not contain personal data or confidential information. citeturn21view0

### EU AI Act obligations that matter for a govtech tool portal

The AI Act includes outright prohibited AI practices and a structured regime for high-risk AI systems, including requirements around lifecycle performance, cybersecurity, and provider obligations (documentation, logs, conformity processes). citeturn19view0turn19view1turn19view2

Practical portal implication: don’t try to “classify” each tool legally for developers—but require **structured self-declaration** fields and publish them, plus disclaimers and human-oversight notes. This reduces ambiguity, and aligns with the Act’s emphasis on trustworthy AI and clear obligations. citeturn16view0turn19view2

### Digital Services Act obligations

Because the portal hosts third-party submissions and may expose demos, it should assume it is at least a hosting service under the DSA and implement: clear terms/conditions, notice-and-action mechanisms, reasoned decisions for moderation actions, and transparency reporting obligations depending on platform classification. citeturn12view0turn12view1turn12view3

Even if you remain below “very large platform” thresholds, the operational pattern is the same: documented moderation, user reporting, audit-friendly logs. citeturn12view3

### Interoperable Europe Act and regulatory sandboxes

The Interoperable Europe Act requires the Commission to provide a portal as a single point of entry for interoperability solutions and explicitly includes citizen/business feedback functions; it also frames interoperability regulatory sandboxes with openness and reporting. citeturn21view0turn21view1

A Commission implementing regulation (2025/1420) sets out operational rules for interoperability regulatory sandboxes and includes expectations like publishing calls and eligibility criteria and making sandbox/project information available via a dedicated interface. citeturn23view0turn23view2

Your portal can function as a **national/independent complement**: either a feeder into EU mechanisms (metadata-compatible) or a sandbox entry ramp for Romanian public bodies. citeturn6search0turn23view1

### Accessibility: legal baseline and operational standard

EU law requires public-sector websites and mobile applications to meet accessibility requirements, and EN 301 549 provides functional accessibility requirements, test procedures, and methodology usable in procurement and compliance contexts. citeturn33view1turn31view1turn8search11

Portal implication: treat accessibility as release gating for portal UI and as a badge criterion for hosted demos (especially anything citizen-facing). citeturn31view0turn33view1

### Romania-specific operational anchors

Romania’s digital ecosystem already includes national-scale platforms that can seed the portal’s categories and “real usage” stories: Ghișeul.ro as the national online payment system operated by ADR; data.gov.ro as the national open datasets portal and central access point; and ROeID positioned as a national SSO solution for citizen digital interactions. citeturn7search8turn7search5turn7search33

Where institutions are already producing digital services, your portal’s value is making components reusable and testable, not duplicating official portals. citeturn0search3turn21view0

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

The security architecture must assume adversarial submissions (malware, crypto-miners, data exfiltration, phishing, prompt-injection style abuse in AI tools). The goal is to make “click-to-try” safe by default.

### Sandbox runtime comparison

Each runtime has a role; avoid a premature “one runtime for everything” decision.

| Candidate runtime | Core security property | Best fit in this portal | Key trade-offs |
|---|---|---|---|
| WebAssembly sandbox | Modules execute in a sandboxed environment and can’t escape without going through appropriate APIs citeturn2search0 | default “demo-safe” for lightweight compute, text transforms, policy simulators | limited OS-level compatibility; needs careful capability design |
| Firecracker microVM | purpose-built for secure, multi-tenant container and function-based workloads citeturn2search1turn2search5 | medium-risk demos requiring Linux userland, stronger isolation | higher ops complexity; VM image management |
| Kata Containers | containers with VM-level isolation using hardware virtualization as second layer of defense citeturn2search2turn2search18 | Kubernetes-integrated multi-tenant workloads where compatibility matters | overhead vs plain containers; runtime complexity |
| gVisor | application kernel that limits host kernel surface accessible to containers citeturn2search39turn2search3 | “middle isolation” for container workloads when microVM overhead is too high | syscall compatibility limits for some apps |

A practical approach is **Wasm-first** for MVP, then add microVM-backed runners for “heavier” demos once governance and scanning are mature. citeturn2search0turn2search5turn2search2

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

NIST SSDF organizes secure development into four groups (Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities) and explicitly includes collecting and sharing provenance data like SBOMs as part of protecting releases. citeturn26view0turn26view2

SLSA provides a framework and attestation formats (provenance) that support verification of how artifacts were built and the need to verify provenance against expectations. citeturn34search18turn34search0turn34search4

Sigstore provides an ecosystem for artifact signing and verification, including keyless signing and transparency logs, and explicitly targets signing/verifying artifacts including SBOMs. citeturn34search6turn34search13turn34search9

SBOM standards have credible “minimum elements” guidance (NTIA) and well-established machine-readable formats like SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424). citeturn3search10turn3search5turn3search2

### CI/build/scan/run/observe pipeline

The platform should have no “manual exceptions” for runnable artifacts: if it runs, it must be buildable and verifiable.

```mermaid
flowchart LR
  A[Repo or upload] --> B[Metadata lint: publiccode.yml + portal extension]
  B --> C[Build in isolated runner]
  C --> D[Generate SBOM + provenance]
  D --> E[Static scans: SAST + SCA + secrets]
  E --> F[Sign + attest (Sigstore)]
  F --> G[Publish artifacts to registry]
  G --> H[Deploy to sandbox runner (Wasm / gVisor / microVM)]
  H --> I[Runtime controls: no PII default, egress policy, quotas]
  I --> J[Observability: logs, metrics, traces]
  J --> K[Trust badge evaluation + publish demo]
  K --> L[Ongoing monitoring + vuln intake + revocation]
```

This pipeline is directly motivated by SSDF’s emphasis on protected releases and provenance/SBOM practices and by Sigstore/SLSA’s attestation and verification approach. citeturn26view2turn34search6turn34search0turn34search4

### Reference architecture: key components

```mermaid
flowchart TB
  subgraph Portal
    UI[Citizen UI + Dev UI]
    API[Portal API]
    META[(Metadata store)]
    SEARCH[(Search index)]
  end

  subgraph SupplyChain
    CI[CI builders]
    REG[(Artifact registry)]
    LOG[Transparency log]
  end

  subgraph Sandbox
    ORCH[Sandbox orchestrator]
    R1[Wasm runner]
    R2[Container runner]
    R3[MicroVM runner]
    OBS[Observability stack]
  end

  UI --> API
  API --> META
  API --> SEARCH

  API --> CI
  CI --> REG
  CI --> LOG
  REG --> ORCH
  ORCH --> R1
  ORCH --> R2
  ORCH --> R3
  ORCH --> OBS
  API --> OBS
```

Core design constraint: demos are “sealed” artifacts pulled from a registry, not arbitrary code executed from a web form; this supports verifiable supply chain controls (SLSA/Sigstore) and reduces attack surface. citeturn34search6turn34search0turn29view1

### Entity relationships: catalog model

```mermaid
erDiagram
  DEVELOPER ||--o{ PROJECT : submits
  PROJECT ||--o{ RELEASE : publishes
  PROJECT ||--o{ DEMO : exposes
  RELEASE ||--o{ ARTIFACT : contains
  ARTIFACT ||--o{ ATTESTATION : has
  PROJECT ||--o{ BADGE : earns
  INSTITUTION ||--o{ EVALUATION : performs
  PROJECT ||--o{ EVALUATION : receives
  CITIZEN ||--o{ FEEDBACK : files
  DEMO ||--o{ FEEDBACK : receives
  PROJECT ||--o{ ADOPTION : has
  INSTITUTION ||--o{ ADOPTION : uses
```

This model supports Interoperable Europe expectations about citizen feedback and discoverability, while remaining compatible with catalog-first discovery patterns. citeturn21view0turn6search0turn5search12

## Adoption pathway, sustainability, roadmap, and risks

### Adoption pathway for administrations

Adoption is mostly blocked by evaluation cost and procurement friction, not by lack of prototypes. Your portal should ship “pilot packs” that reduce evaluation time:

- Technical pack: deployment topology, APIs, data flows, integration points.  
- Security pack: SBOM, signed artifacts, provenance, scan summaries, threat model. citeturn26view2turn34search6turn3search10  
- Privacy pack: DPIA template/summary, lawful basis assumptions, retention, data categories. citeturn15view1  
- Interop pack: standards supported, schema/export formats, mapping to EIF-style concerns. citeturn21view0  
- Procurement fit notes: comparable offerings, support options, exit strategy, licensing. Italy’s comparative evaluation and preference for reuse/open source is a strong pattern to mirror. citeturn6search7turn6search10  

This gives administrations a “one-click” evaluation path that is consistent with EU reuse and interoperability goals. citeturn6search5turn21view1

### Sustainability and monetization options

The portal’s credibility increases if listing and baseline demos remain free. Monetization should target **enterprise-grade operational needs**, not citizen access.

| Option | What’s paid | Why it’s compatible with “mostly free” | Risks |
|---|---|---|---|
| Managed hosting for agencies | dedicated tenant, uptime, backups, SSO, audit logs | agencies pay for operations, not code | must avoid lock-in; publish infra-as-code |
| Security & compliance services | pentests, DPIA assistance, conformity documentation packs | aligns with admin needs, improves trust | needs strict conflict-of-interest policy |
| Private sandbox for sensitive pilots | isolated environment, custom egress allowlists, on-prem connectors | supports real pilots without exposing data | higher security liability |
| Vendor support marketplace | paid support contracts around open tools | mirrors existing public procurement patterns | must prevent “pay to win” discovery |

The Interoperable Europe Act explicitly values openness and reuse, and requires portal-accessible solutions not contain personal data/confidential info—pushing your paid layer toward operations and private pilots rather than public demo monetization. citeturn21view0

### Phased roadmap

```mermaid
gantt
  title GovTech Commons Portal Roadmap
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section Foundation
  Governance, schema, policies           :a1, 2026-04-10, 45d
  Portal MVP (catalog + search)         :a2, after a1, 60d

  section Demo capability
  Wasm demo runner MVP                  :b1, after a2, 45d
  Trust badges v1 + moderation workflow :b2, after a2, 45d

  section Pilot readiness
  Supply-chain verification (SBOM+sign) :c1, after b1, 45d
  Pilot packs + first agency pilots     :c2, after c1, 60d

  section Scale
  MicroVM runner + multi-tenant harden  :d1, after c2, 75d
  Federation with EU catalog patterns   :d2, after c2, 75d
```

This roadmap is shaped by EU-level reuse infrastructure maturity (EU OSS Catalogue), the Interoperable Europe portal/sandbox direction, and the need to build trust controls before scaling runnable hosting. citeturn6search8turn6search1turn21view1turn23view1

### Risk register with mitigations

1. **Untrusted code execution leads to compromise** → Default Wasm sandbox; microVM for higher-risk workloads; strict outbound policy; resource quotas; signed-only artifacts; continuous monitoring. citeturn2search0turn2search5turn34search6turn29view0  
2. **Phishing / social engineering via “citizen demos”** → UI warnings, origin transparency, no credential collection in demos, content moderation workflow, takedown SLAs. citeturn12view0turn12view1  
3. **GDPR violations via accidental PII collection** → Synthetic datasets only by default; explicit DPIA gating for any tool that stores personal data; retention limits; privacy review checklist. citeturn15view1turn21view0  
4. **“Trust badge inflation” reduces credibility** → Criteria-based badges with revocation; publish evidence artifacts (SBOM, provenance); external audits for higher badges. citeturn26view2turn34search0turn5search6  
5. **Low admin adoption due to procurement friction** → Pilot packs aligned to comparative evaluation patterns; clear licensing; support marketplace. citeturn6search7turn6search10  
6. **Maintainer burnout / governance capture** → transparent governance; contribution guidelines; security process; rotate roles; publish metrics. citeturn5search10  
7. **AI-related legal ambiguity** → structured AI disclosures; conservative labeling; require human-oversight notes; avoid hosting prohibited AI practices. citeturn19view0turn19view2  

## File B: concise implementation plan, launch checklist, and technical stack

```markdown
# Implementation plan and launch checklist

## Target outcome
Launch an open-source govtech portal that:
- lists civic/AI tools with publiccode.yml-based metadata
- allows safe, runnable demos (default: no PII, no outbound network)
- exposes a trust ladder (Demo-safe → Pilot-verified)
- supports administrations with pilot packs (security + privacy + deployment)

## Baseline technical stack (no vendor lock-in)
- Frontend: Next.js (or equivalent SSR), static-first pages for catalog entries
- Backend API: FastAPI or Node (NestJS), REST + optional GraphQL
- Data: Postgres (source of truth), OpenSearch/Meilisearch (search)
- Storage: S3-compatible object storage for artifacts and logs
- Artifact registry: OCI registry (Harbor or registry:2)
- CI: GitHub Actions / GitLab CI; isolated self-hosted runners for builds
- Signing: Sigstore Cosign (keyless where possible) + Rekor transparency
- SBOM: SPDX and/or CycloneDX (Syft/Trivy generation)
- SCA/SAST: Trivy + Semgrep + secret scanning
- Sandbox orchestration: Kubernetes + dedicated runner service
  - Runner v1: WebAssembly (WasmEdge/Wasmtime) for “demo-safe”
  - Runner v2: gVisor/Kata for container workloads
  - Runner v3: Firecracker microVM pool for stronger isolation
- Observability: Prometheus + Loki + OpenTelemetry
- Moderation: ticket system + audit log, DSA-style notice/action

## Workstreams and staffing (estimated effort)
Roles:
- Product lead (PL)
- Tech lead (TL)
- Security lead (Sec)
- DevOps/SRE (SRE)
- UX/content (UX)
- Community & partnerships (Comms)
- Legal/privacy (Legal)

Total MVP team size: 6–8 people part-time or 4–5 full-time equivalents.

## MVP scope (8–12 weeks)
- Catalog listings: publiccode.yml validation + indexing
- Citizen view: plain-language summaries + “what data does it use”
- Developer onboarding: templates + CLI “publish” tool (optional)
- Trust badges v1: Listed, Demo-safe
- Wasm demo runner MVP:
  - no outbound network
  - time + memory quotas
  - read-only filesystem
  - synthetic datasets only
- Moderation basics:
  - report button on every page/demo
  - takedown workflow + transparency log

## 100% launch checklist (with responsibilities, effort, budget ranges)
Budget ranges are minimal and assume you already have hardware; currency unspecified.

### Governance and legal
- [ ] (Legal, 0.25 pm, 0–1k) Terms of service + acceptable use + demo disclaimers
- [ ] (Legal, 0.25 pm, 0–2k) Privacy notice + cookie policy + DPIA template
- [ ] (PL+Comms, 0.25 pm, 0–1k) Governance: maintainers, decision process, security policy
- [ ] (Sec, 0.25 pm, 0–5k) Vulnerability disclosure policy + intake channel + SLA

### Metadata and catalog
- [ ] (TL, 0.5 pm, 0–1k) publiccode.yml validator + portal extension schema v0.1
- [ ] (UX, 0.25 pm, 0–1k) Citizen-readable “tool card” template
- [ ] (TL, 0.5 pm, 0–2k) Search indexing + filters (service domain, maturity, trust level)

### Demo runtime
- [ ] (Sec+SRE, 0.75 pm, 0–3k) Wasm runtime chosen + hardening profile documented
- [ ] (TL, 0.75 pm, 0–2k) Demo packaging format (OCI artifact or zip with manifest)
- [ ] (SRE, 0.5 pm, 0–2k) Resource quotas + isolated namespaces + per-demo sandbox ID
- [ ] (Sec, 0.5 pm, 0–2k) Outbound network policy enforcement (default deny)

### Supply chain
- [ ] (Sec+SRE, 0.75 pm, 0–3k) CI isolated builders + minimal base images
- [ ] (Sec, 0.5 pm, 0–2k) SBOM generation in pipeline (SPDX/CycloneDX)
- [ ] (Sec, 0.5 pm, 0–2k) Signing + attestation with Cosign
- [ ] (Sec, 0.5 pm, 0–2k) Admission policy: only signed artifacts can run

### Observability and ops
- [ ] (SRE, 0.5 pm, 0–2k) Central logging + retention policy
- [ ] (SRE, 0.5 pm, 0–2k) Metrics dashboards for sandbox and portal
- [ ] (SRE, 0.25 pm, 0–1k) Backup + restore test for core databases

### Content and launch readiness
- [ ] (Comms, 0.5 pm, 0–2k) Seed 30–50 listings (including Romania anchors)
- [ ] (UX, 0.25 pm, 0–1k) Accessibility audit of portal UI
- [ ] (PL, 0.25 pm, 0–1k) “How to publish” guide + example repo

### Partnerships and adoption
- [ ] (Comms, 0.5 pm, 0–5k) Identify 3 pilot institutions and sign lightweight pilot MoUs
- [ ] (PL+Legal, 0.5 pm, 0–3k) Pilot pack template: security + privacy + deployment
- [ ] (PL, 0.25 pm, 0–2k) Publish pilot evaluation rubric (scoring + evidence)

## Post-launch (weeks 12–24)
- Expand trust ladder: Verified supply chain, Pilot-verified
- Add microVM runner for higher-risk demos
- Federation: export compatible feeds for EU OSS Catalogue patterns
- Run first “pilot cohort” and publish case studies
```

## Multi-AI review prompt for iterative consolidation

```text
You are an expert panel reviewing a plan for an open-source govtech aggregator portal (EU/Romania) that lists and hosts runnable AI/civic tools with a secure sandbox and a trust badge ladder.

INPUTS:
1) The attached report (treat it as the baseline).
2) Your task: produce an alternative analysis and improvements.

REQUIRED OUTPUT FORMAT:
A. Critical gaps (top 10) — include why each matters.
B. Architecture critique — specifically: sandbox isolation, multi-tenancy threats, supply-chain controls, and the run pipeline.
C. Compliance critique — GDPR, EU AI Act, DSA, accessibility, Interoperable Europe Act; identify missed obligations and propose mitigations.
D. Product critique — personas, IA, taxonomy/metadata (publiccode.yml superset), trust badges; propose simplifications.
E. Feasibility — identify the MVP that can ship in 8–12 weeks with strong safety.
F. Risk register — add 10 risks not covered and mitigations.
G. Recommendations — a prioritized list of changes (must be actionable).

COMPARISON INSTRUCTIONS (IMPORTANT):
- Identify where your conclusions differ from the baseline; label each difference as:
  (i) Correction (baseline is wrong),
  (ii) Enhancement (baseline is good but incomplete),
  (iii) Alternative (different but viable approach).
- If you propose removing something from baseline, propose what replaces it.

MERGE INSTRUCTIONS (FOR FINAL CONSOLIDATION STEP):
- After generating your response, produce a “Merged Plan Delta” section:
  - Keep: items you agree with.
  - Change: items to modify (include new wording).
  - Add: items missing from baseline.
  - Remove: items to drop and why.
- Your goal is to help converge to a single unified plan that is safer, simpler, and more adoptable.

CONSTRAINTS:
- Assume no vendor lock-in; must be open source friendly.
- Assume attackers will submit malicious demos; security must be default-deny.
- Prefer primary/official standards and laws; cite them when possible.
```

## Primary sources and references

Key EU-level reuse and interoperability anchors: EU OSS Catalogue pages and its evolution, plus publiccode.yml as a prerequisite and reference spec. citeturn6search0turn6search1turn6search8turn6search4turn5search0

Legal obligations: GDPR, DSA, AI Act, Web Accessibility Directive, and Interoperable Europe Act plus implementing rules for interoperability regulatory sandboxes. citeturn15view1turn12view1turn19view2turn33view1turn21view1turn23view2

Security framework anchors: NIST SSDF and container security guidance; SLSA provenance and verification; Sigstore keyless signing and transparency. citeturn26view0turn29view1turn34search0turn34search4turn34search6turn34search13

Romanian ecosystem anchors: ADR platforms and national services (payments, identity, open data, ROePAS single access point). citeturn0search3turn7search8turn7search33turn7search5turn0search4