Define the decentralization roadmap and trust boundaries

[flo2517]

Create an accepted ADR and staged plan for decentralizing OpenInfra without putting unsuitable data on-chain. Classify identity, leases, offers, reputation, payments, workload metadata, metrics, logs, secrets, images, dashboard assets, and audit evidence by required integrity, availability, privacy, and retention.

Acceptance criteria:

• explicit trust model and threat model for providers, Workers, Network Validators, Chain Authorities, Control Plane replicas, gateways, and storage nodes;
• define which facts are on-chain, content-addressed, replicated, encrypted, cached, or local-only;
• define finality, conflict resolution, replay protection, data availability, erasure, GDPR/privacy, and key recovery;
• define migration stages from PostgreSQL/Redis and centralized API to replicated services;
• document performance, cost, liveness, governance, and rollback trade-offs;
• no architecture implementation starts before ADR acceptance.

[flo2517]

ADR-012 is proposed in #65 (docs/adr/012-decentralization-roadmap-and-trust-boundaries.md).

How it maps onto this issue's acceptance criteria:

Criterion	Where
Explicit trust and threat model for providers, Workers, Network Validators, Chain Authorities, Control Plane replicas, gateways, and storage nodes	§1 (vocabulary — fixes Worker vs Network Validator vs Chain Authority once) and §2 (per-role table: what each may assert, is trusted for, must never be trusted for, and its adversarial modes)
Which facts are on-chain, content-addressed, replicated, encrypted, cached, or local-only	§3 — the 12 data classes named here, each with integrity/availability/privacy/retention, a Stage 0 placement and a target placement
Finality, conflict resolution, replay protection, data availability, erasure, GDPR/privacy, key recovery	§4
Migration stages from PostgreSQL/Redis and a centralized API to replicated services	§5 — five stages mapped onto milestones v3.0–v6.0 so the roadmap and the tracker cannot drift
Performance, cost, liveness, governance, and rollback trade-offs	§7
No architecture implementation starts before ADR acceptance	§6 — ADR-012 authorizes nothing itself; it names eight follow-up gates (ADR-013…ADR-020), and AGENTS.md now states that a prohibition is lifted only by accepting the gate named there

Two decisions in it worth flagging for review:

• ADR-008 is not superseded. It stays accepted and operative for Stage 0; ADR-012 refines its boundary per class and adds the target column. Nothing moves from off-chain to on-chain.
• A permanent constraint was added, not just a roadmap: no tenant payload, log, secret, or personal data ever goes on-chain, only hashes and commitments, because consensus state cannot be erased. AGENTS.md now lists this among the prohibitions that no ADR lifts.

Issues #50–#63 have been rewritten to the repository's issue convention, each naming the gate it waits on, with the original French text preserved verbatim at the bottom. ROADMAP.md now covers v1.1 through v6.0 and matches the GitHub milestones.

Leaving this issue open for you to close once #65 is reviewed and merged.

[flo2517]

Resolved by ADR-012 (accepted, merged in #65): docs/adr/012-decentralization-roadmap-and-trust-boundaries.md defines the trust/threat model per role, the 12-class data classification with the one-way on-chain rule, finality/conflict-resolution/replay/availability/erasure/key-recovery guarantees, the five-stage migration mapped onto the GitHub milestones, and the ADR-013..ADR-020 gate table naming which prohibition each later stage lifts and under what accepted ADR. AGENTS.md's prohibited-changes list now points to it instead of standing as an unconditional ban.