Publication Filtering implemented
The first portal is internal. The filtering model is already partially implemented through page metadata, source-doc validation, publication-track checks, and a static Cloudflare publication path. What remains is generating separate customer, partner, and public artifacts from the same curated portal.
Filtering must happen from portal-native pages, not from the raw doc/**
corpus.
Current Published Baseline
- internal static portal only;
- publication track carried in page metadata and build metadata;
make docs-portal-checkenforces the current first-line publication guard;- Cloudflare Pages preflight/publish wrappers exist for the internal track.
| Commit | 9725f0e5236d |
|---|---|
| Full SHA | 9725f0e5236dc0f3f14d9a5c89d15ecd5a64dc1b |
| Build timestamp | 2026-06-18T03:36:53.921Z |
| Published timestamp | 2026-06-18T03:36:51Z |
| Publication track | internal |
| Public URL | https://docs.aicloud.core42.dev |
Tracks
| Track | Audience | Default posture |
|---|---|---|
| Public | Prospects and general readers | Product overview, high-level architecture, safe developer landing, no sensitive operations |
| Customer | Customer admins, security reviewers, operators | Product, security posture, operational model, selected architecture, customer-safe runbooks |
| Partner | App developers, integration partners | App SDK, APIs, auth, manifests, examples, selected architecture, safe playground |
| Internal | Product, architecture, engineering, CISO, ops, infra, app developers | Full portal, including implementation detail, gaps, runbooks, and evidence |
| Ops | Operators, SRE, infra, release engineers | Full operational track, including protected diagnostics and runbook detail |
| Governance | Architecture, security, product governance, reviewers | Decision records, review gates, publication policy, evidence quality, and change-control rules |
Filtering Rules
| Content type | Internal | Customer | Partner | Public |
|---|---|---|---|---|
| Product overview and user journeys | yes | yes | yes | selected |
| Architecture overview | yes | selected | selected | high-level only |
| Production gaps and residual risk | yes | reviewed summary | no | no |
| Security controls | yes | reviewed summary | selected | high-level only |
| Runbooks and incident flows | yes | selected/sanitized | no | no |
| App SDK and manifests | yes | selected | yes | selected |
| API references | yes | selected | yes | selected |
| API playground | sandbox/UAT allowed | customer sandbox only | partner sandbox only | mock only |
| Evidence artifacts | yes | curated only | curated only | no |
| Internal Fairway/agent process | yes | no | no | no |
| Ops diagnostics and tool access | yes | selected/sanitized | no | no |
| Governance review gates | yes | selected | selected | no |
Redaction Rules
- Remove internal hostnames, private URLs, credentials, tokens, and operational secrets.
- Remove incident details that reveal tenant/customer names, topology, or unresolved controls.
- Replace exact internal runbook commands with safe summaries for non-internal tracks.
- Keep architecture diagrams high-level unless security and architecture approve deeper publication.
- Treat screenshots as internal until visibility review approves them.
Build Direction
The first implementation can keep one internal build. The next stage should add metadata-aware filtering:
Checker Direction
The current source-doc checker includes an initial publication readiness guard. It validates non-internal review ownership, customer/partner review routing, public/customer status posture, obvious sensitive text patterns, internal-only source paths for public/customer tracks, and visual-page review domains. Future versions should extend that guard to validate:
- each non-internal page has an approved review domain,
- public/customer/partner pages do not link to internal-only pages,
- image assets have publication review metadata,
- API playground behavior matches the track,
- source docs exist and are approved for the track,
- pages with
freshness_risk: highare inside review cadence.
Practical Next Step
Do not jump straight to broad public publication. The next safe implementation step is:
- generate a visibility report from the current internal portal;
- define the first
customerandpartnersubsets; - build filtered artifacts without changing hostname exposure;
- review those artifacts before exposing any new track on a public URL.