Publication Tracks implemented
The first portal is internal and the track model is already active in the page
metadata and portal checker. The content model carries visibility metadata so
the same architecture can later publish sanitized tracks.
Tracks
| Track | Audience | Default access | Examples |
|---|---|---|---|
| Public | Prospective users, external developers, public API consumers | unauthenticated | Product overview, selected getting-started docs, public API overview, App SDK quickstarts |
| Customer | Customers, tenant admins, customer reviewers | customer-authenticated or review pack | User docs, tenant/project docs, billing, safe security model, customer-safe runbooks |
| Partner | Partner app developers and integration teams | partner-authenticated | App SDK, manifest contracts, app promotion, API/SDK references, integration guides |
| Internal | GPUaaS team, operators, product, security, architecture, infra, app developers | authenticated internal | Release gates, internal runbooks, environment profiles, sensitive evidence, agent coordination |
| Ops | Operators, SRE, infra, release engineers | authenticated operator | deploy runbooks, diagnostics, tool access, smoke evidence |
| Governance | Architecture, security, product governance, reviewers | authenticated governance/review | review gates, publication policy, evidence quality, change-control rules |
The metadata field is still named visibility, but the allowed values now model
publication tracks: public, customer, partner, internal, ops, and
governance.
Review Gates
| Track | Required review | API playground posture | Evidence posture |
|---|---|---|---|
| Public | Product and security, plus legal/comms when needed | mock by default | no internal evidence |
| Customer | Product, security, architecture | approved customer sandbox only | curated evidence only |
| Partner | Product, developer experience, security | approved partner sandbox only | SDK and integration evidence only |
| Internal | Content owner | dev/UAT targets allowed | complete internal evidence allowed |
| Ops | Ops plus security when secrets, access, or network posture is involved | dev/UAT targets allowed | full operational evidence allowed with redaction |
| Governance | Governance plus owning domain | mock or internal only unless a publication decision approves more | decision evidence, review records, and policy rationale |
The track model follows the platform-foundation Phase 5 contract: portal pages
publish from portal-native metadata, not directly from raw doc/** files.
External tracks require source-doc review, redaction review, and freshness
metadata before publication.
Current Publication Decision
The selected first iteration is an internal static portal published through Cloudflare Pages. This is the default operating model until a later task introduces filtered external tracks or an authenticated internal-only variant.
Why this shape:
- it keeps the portal build static and cheap to maintain;
- it avoids binding the first release to product auth or runtime coupling;
- it supports internal product, architecture, security, IAM, infra, and ops audiences immediately;
- it preserves the later option to add filtered public/customer/partner builds from the same source-doc model.
Internal publication does not mean dumping raw internal files. The portal still uses page-level audience, review, and visibility metadata so later external filtering does not require a redesign.
Current short-term access rule
The first internal portal should sit behind Cloudflare Access using one-time email passcodes with this coarse allowlist:
@core42.ai@g42.aisubahsram@gmail.com
This is an operational convenience model, not a long-term role boundary. The portal content still needs publication-track discipline because domain-level allow access is broader than the intended initial sharing set.
First Publication Recommendation
Publish the internal static artifact first. Use that to validate navigation, source links, ownership, and audience fit. After that, add filtering or separate builds for public/customer/partner tracks.
Use the Publication Filtering model for the concrete track rules, redaction posture, API playground behavior, and future checker direction. Use the deployment runbook as the operating path for the current internal static publication.
Deterministic Gate
make docs-portal-check runs packages/docs/scripts/check-source-docs.mjs.
That check now enforces the first publication-track guard:
| Guard | Tracks |
|---|---|
| Allowed metadata values include all six tracks | all |
| Non-internal pages include content review metadata | public, customer, partner, ops, governance |
| Customer pages route to product, security, or ops review | customer |
| Partner pages route to app-developer or architecture review | partner |
| Public/customer pages reject unresolved readiness status | public, customer |
| Public/customer pages reject internal-only source paths | public, customer |
| Public/customer/partner pages reject private URLs, local file paths, raw key material, and token/secret text | public, customer, partner |
| Non-internal visual pages require architecture, product, security, or frontend review | public, customer, partner, ops, governance |
This is intentionally conservative. The checker does not prove that a page is publication-ready; it prevents the common unsafe cases from entering the portal without review.
External Readiness
Before publishing any external track, complete the External Publication Readiness checklist and review the draft External Viewer Paths.
Security Review Rules
- Public and partner pages must avoid internal environment names, sensitive ops evidence, break-glass details, and private infrastructure paths.
- Customer pages may include security posture and operational commitments, but only after source docs are reviewed for shareability.
- Internal pages remain the complete operating view.