Portal Execution Roadmap in-progress
This is the standing work plan for keeping the documentation portal complete and useful. The internal portal foundation is implemented. The remaining roadmap is about depth, external publication hardening, and long-term maintenance.
Workstreams
| Workstream | Goal | Status |
|---|---|---|
| Content consolidation | Promote high-value source docs into portal-native pages | Implemented baseline; continue incrementally |
| Visual layer | Add diagrams and maintained images for mixed audiences | Implemented baseline; deepen where needed |
| Developer/API experience | Sync contracts and expose developer/App SDK reference paths | Implemented baseline |
| Metadata and ownership | Enforce owner, review cadence, freshness, and publication readiness | Implemented |
| Internal onboarding | Keep persona paths current for product, architecture, CISO, ops, infra, developers | Active maintenance |
| Publication tracks | Prepare public/customer/partner/internal filtering | Internal track implemented; external tracks remain future work |
| Review and packaging | Create repeatable review paths and later export packages | Implemented baseline |
See Portal Epics And Backlog for the Fairway-ready backlog that should be activated one task at a time.
Current Completion Line
| Slice | Current outcome |
|---|---|
| Audience-first landing and section map | Implemented |
| Architecture, shared-services, and proof pages | Implemented |
| Security, evidence, and production-readiness pages | Implemented |
| Operator, release, and deployment model pages | Implemented |
| App SDK, developer, and builder reference spine | Implemented |
| Publication tracks, quality gates, and Cloudflare static publish path | Implemented |
| Build metadata, inventory, and source sync | Implemented |
Remaining Roadmap
The remaining portal work is intentionally narrower:
- add deeper diagrams where runtime or ops readers still need more shape;
- add filtered external builds only when the sharing model justifies them;
- keep screenshots, source links, and synced contract artifacts current;
- extend portal automation only when a real stale-content miss escapes the current gate.
Completion Definition
The portal is "complete enough" when each internal audience can answer:
- what GPUaaS is,
- what has been built,
- how users interact with it,
- how the control plane works,
- how operators manage it,
- what security controls and gaps exist,
- how developers build on it,
- how changes are governed,
- where generated API and SDK references live,
- what is internal-only versus publishable.