Every program on Ironmark ships with a customer-facing portal — the surface a reader uses to browse the technical manual without an authoring seat. It reads the same source-of-record modules as the IETP viewer; separation is at the auth boundary, not the content boundary.
Portal landing — a customer sees only the programs they've been granted access to.
Program detail on the portal — TOC, per-asset applicability filter, download + redline actions.
What portal users see
Browse — TOC-driven navigation. Same tree the author sees, minus in-progress cycles.
Search — full-text across published DMs. Result rows link into the IETP viewer.
Applicability filter — pick asset (serial / tail / MDS). Portal renders only what applies. Filter can persist across sessions per user.
Download — PDF snapshot of a DM or a section. Uses the same publish pipeline as scheduled publish.
Redlines — file a line-level markup against a DM. Redlines land in the internal review queue.
Change Requests — raise a CR against the manual. Same first-class CR entity the internal team works with.
Auth separation
Portal readers hold the customer role on the same auth stack the authors use — the same enabled providers (local, LDAP, OIDC, CAC, WebAuthn) are available to them, and the separation is at the role + project-membership boundary, not a distinct portal IdP.
What this means in practice:
Different accounts — a customer signs in as a customer-role user; an author signs in as an author-role user. They can authenticate via the same or different methods depending on what the sysadmin has enabled.
Different project scope — a customer with access to one program's portal doesn't automatically see any other program's portal. Project membership is enforced at the API layer.
Different UI — customer-role users land on the portal surface, not the authoring surface, regardless of how they authenticated.
Redlines triage — where portal-filed markups land for the internal team. Each row keeps source-DM, portal user, and asset-filter context.
Feedback flow
Portal redlines and CRs flow into the same review queue the internal team uses. Reviewers see redline provenance (which portal user, which asset filter was active) alongside the markup. Redline resolution updates the underlying DM through the normal change-cycle path — no separate "portal-triggered" write path.
Portal is not a static-site export. The reader sees the current published state of the source modules, with applicability filtering applied at read time. Update the DM + issue → the portal reflects it on the next publish cycle.