The Governed Static Publishing Lane Tony Malott · Source dated 2026-07-30 https://shareplane.malott.ai/architecture/governed-static-publishing-lane/ Skip to the recommendation Public SharePlane architecture microsite. Derived mechanically from accepted PR #221 head ef64a658cb302262afc21f3cbaaf74c787633e2a . Packages and receipts Classify Architecture Controls Azure Roadmap Kit 01 · The absurdity The Governed Static Publishing Lane A qualifying static site should inherit an approved publishing system rather than implement its own delivery pipeline. The deliverable is a directory of HTML, CSS, JavaScript, images, and approved downloads. The process often arrives dressed as a transactional application: container images, bespoke pipelines, manual credentials, security tickets, infrastructure handoffs, and evidence rebuilt from scratch. Security checks are legitimate. Rebuilding the same mechanics, controls, credentials, and proof in every repository is not. A bad process written in YAML remains a bad process, merely with better indentation. Classify a workload Download the implementation kit This candidate proves Runtime Static files only Dependencies Zero external runtime dependencies Outputs Canonical, directory, and single-file Promotion Build once; preserve exact bytes Authority Educational reference, not corporate approval 02 · The actual problem Six decisions were welded into one opaque process. 01 Hosting Where immutable files are served. 02 CI orchestration What invokes the reusable contract. 03 Security controls Which checks apply to this risk tier. 04 Release approval Who authorizes an environment transition. 05 Evidence What proves the artifact and checks. 06 Ownership Who supports, reviews, and retires it. The governing principle: encode the applicable controls once, publish them as a versioned product, and let repositories declare intent through a thin adapter. 03 · Choose your view View this recommendation as Each view changes the nearby summary, proof signals, objections, and actions. Your explicit choice persists on this device. Engineering Platform and DevOps Security and compliance Cloud and network Operations and service ownership Leadership Engineering view selected Provide a deterministic artifact root, not a new platform. Commit the source, declare the output directory, keep secrets and server behavior out, run the same checks locally, and receive an immutable preview plus receipt. Provide HTML, CSS, JS, images, approved downloads Frameworks Plain files or deterministic React, Astro, Vue, and equivalents Failure Fail closed with a named check and local reproduction Rollback Redeploy a previously receipted checksum Recommended actions Declare outputPath and runtime. Run the qualification command locally. Keep environment-specific content out of built bytes. Objection answered: “Every site is unique” does not mean every site needs unique delivery mechanics. Platform and DevOps view selected Own the template as a versioned product with thin, replaceable adapters. The central team owns qualification, build, evidence, immutable versioning, credentials, promotion, observability, and template upgrades. Jenkins, Azure DevOps, GitHub Actions, and GitLab CI remain interchangeable callers. Primary metric Repository-specific pipeline lines Failure domain Template version or adapter, named separately Upgrade Pin, test, then deliberately advance Credentials Environment-scoped and centrally managed Recommended actions Publish a generic adapter contract. Separate artifact creation from deployment. Onboard a second CI engine before claiming portability. Objection answered: standardizing Jenkins is not the same as standardizing the operating model. Security and compliance view selected Reduce variance while preserving content and runtime risk as separate decisions. Mandatory inherited controls, central versions, deterministic failure, traceable exceptions, artifact integrity, and automatic evidence strengthen review. Static content can still be confidential, regulated, proprietary, malicious, or simply wrong. Runtime risk Code, APIs, state, secrets, and execution surface Content risk Classification, legality, harm, accuracy, and audience Variance signal Percentage of controls inherited centrally Exception posture Named owner, expiry, reason, and compensating control Recommended actions Approve the S0/S1 baseline as policy. Keep content approval independent. Prove negative fixtures and expired exceptions. Objection answered: “Security requires the current pipeline” is a claim to test against controls, not a reason to preserve duplication. Cloud and network view selected Choose hosting, identity, and network posture from requirements—not habit. Start with a purpose-built static host. Treat subscription placement, resource groups, Entra authentication, private endpoints, DNS, certificates, diagnostics, ingress, egress, and environment separation as explicit policy inputs. Primary target Purpose-built static hosting Azure example Static Web Apps Standard when its capability set fits Fallback App Service Linux without a container Boundary Private endpoint is network reachability, not user authorization Recommended actions Publish supported exposure patterns. Name DNS and certificate ownership. Test Development, UAT, and Production isolation. Objection answered: private endpoints narrow ingress; they do not decide who an authenticated user may be. Operations and service ownership view selected Make ownership, deployed identity, recovery, and retirement visible. Every site needs an accountable owner, support route, deployed version, history, health check, incident path, rollback target, review date, decommission process, and stale-site signal. Identity Version + checksum + source + template Recovery Known-good immutable artifact Lifecycle Review date and decommission owner Health Route, headers, content marker, and access tests Recommended actions Define support and incident routes. Exercise checksum-bound rollback. Alert on stale ownership and expired review dates. Objection answered: a static site is operationally simpler, not operationally ownerless. Leadership view selected Standardize the paved road and measure whether friction actually falls. The outcome is shorter lead time with equal or stronger control: fewer manual actions, handoffs, credentials, bespoke pipeline lines, and specialist dependencies—without making the central team a ticket queue. Lead indicator Commit-to-Development elapsed time Cost signal Pipeline maintenance per repository Control signal Inherited-control percentage Scale signal Second-repository onboarding effort Recommended actions Fund a 90-day Development pilot. Set service-level targets for the lane. Require measured comparison before Production approval. Objection answered: a central platform becomes a bottleneck only when it is operated as a bespoke approval desk instead of a self-service product. 04 · Classify the workload A deterministic educational decision aid This guide identifies a likely lane. It is not an authoritative corporate approval engine and cannot replace local architecture, security, privacy, legal, or records review. Runtime and state Executes server-side code Stores or modifies data Accepts user-submitted data Requires runtime secrets Browser and environment Uses client-side application logic Calls approved external APIs Contains controlled or nonpublic content Requires private network access Classify this workload Reset S0 Current deterministic result Static content lane Recommended hosting Purpose-built static hosting; evaluate authentication and network posture separately. Minimum controls Secrets and content checks HTML, links, accessibility, and headers Ownership, checksum, and receipt Disqualifying conditions Any server runtime, state mutation, user-submitted data, or runtime secret moves the workload to S2. Unresolved local review Confirm content classification, audience, identity, network, records, and release requirements. Read the classifier rules without JavaScript If server code, state mutation, user-submitted data, background work, sensitive processing, or runtime secrets exist, classify S2 and exit this lane. Otherwise, if client-side logic or approved API calls exist, classify S1 and add dependency, SBOM, CSP, endpoint, and browser-security controls. Otherwise classify S0 and apply the baseline static-content controls. Controlled content and private-network requirements do not change S0/S1/S2 by themselves; they add unresolved local authorization, hosting, and network decisions. 05 · Current versus target Move the system boundary Current state Target state Current state selected Every repository rebuilds the delivery system. Control intent may be legitimate, but implementations, credentials, evidence, approvals, and failures fragment across repositories. Current: repeated application-scale delivery Repository A Bespoke Jenkinsfile Repository B Different YAML and credentials Repository C Container added for static files Security review Evidence reassembled repeatedly Manual release Portal action and unclear rollback Failure signature: the organization standardizes tools while preserving implementation variance. Target: one governed contract, many thin adapters Repository Files + site manifest Thin CI adapter Jenkins, Azure DevOps, GitHub Actions, GitLab CI Qualification gate S0, S1, or reject as S2 Central template Build, controls, policy, evidence Immutable artifact Version + checksum + source + template Development host Authenticated route and negative tests Receipts Human and machine evidence Success signature: the second repository inherits the same controls with less bespoke code and no weaker evidence. 06 · The pipeline contract The repository declares intent. The platform supplies mechanics. Illustrative site-manifest.yaml schemaVersion: 1 site: name: example-architecture-guide owner: platform-engineering classification: internal runtime: type: static outputPath: dist authentication: mode: enterprise-identity network: exposure: private Illustrative thin Jenkins adapter governedStaticSite { outputPath = "dist" classification = "internal" runtime = "none" authentication = "entra" targetEnvironment = "development" } Reference patterns only. Map fields, identity, controls, credentials, and approvals to local policy and tooling. These are not drop-in corporate configurations. Repository supplies Artifact root Classification Owner Runtime declaration Approved exceptions Platform inherits Qualification Security controls Build and package Immutable promotion Credentials Evidence and rollback metadata Failure returns Named failed control Template version Local reproduction Artifact identity Exception route 07 · Security without repetition Risk-tiered controls, inherited centrally Control area S0 · static content S1 · static application S2 · dynamic application Qualification Static files; no client application logic Client-side logic or approved API consumption Server, state, secrets, writes, input, or sensitive processing Baseline Secrets, file types, malware, HTML, links, classification, headers, accessibility, ownership, checksum, receipt All S0 controls Exit the Static Publishing Lane Software supply chain Generated-file provenance where applicable Locked dependencies, SCA, SBOM, license policy, client static analysis Organization application-delivery policy Browser security Header policy and no unexpected origins CSP validation, endpoint allowlist, browser security tests Application threat model and runtime testing Content risk Classification, accuracy, privacy, legal, records, export, harm, and audience review remain independent of runtime tier. Exceptions Named owner, justification, scope, compensating control, approval, and expiry Handled by the receiving application lane Mandatory inheritance A repository cannot silently omit a required control. Central versioning Control changes are pinned, tested, receipted, and deliberately adopted. Fail closed Unknown runtime, missing owner, invalid classification, and unmatched bytes stop the lane. Traceable exceptions Exceptions are records with expiry, not comments that outlive their context. 08 · Why not Docker? Portability is valuable. Unnecessary runtime is not. Containers are justified when the workload needs a server process, runtime-specific behavior, controlled native dependencies, a consistent application execution environment, or an accepted platform boundary. They are weak justification when the only job is serving immutable files. Question Static host Container runtime Server process required? No Yes, or a documented platform constraint requires it Operational additions Artifact, host, headers, access, receipt Registry, image scanning, base-image patching, runtime health, orchestration, capacity Rollback unit Immutable file artifact Image plus runtime configuration Good reason Simple static delivery Real server/runtime requirement or approved uniform platform contract Bad reason “Everything goes in Docker” without measuring the additional control and operational surface. Balanced decision: do not prohibit containers. Require the requirement that earns them. 09 · Azure worked example A practical hierarchy, not a product advertisement Capabilities, plan availability, regions, tenant configuration, network design, and enterprise policy can change. Verify the linked Microsoft documentation and local standards during implementation. Primary Azure Static Web Apps Standard Use when purpose-built static hosting, route/header configuration, supported authentication, and the required network posture fit. Microsoft documents preconfigured GitHub and Microsoft Entra ID authentication, route authorization in staticwebapp.config.json , and Standard-plan private endpoints. Fallback Azure App Service Linux without a container Use when Static Web Apps cannot satisfy a requirement but a container still adds no value. App Service documents built-in authentication, private endpoints, access restrictions, diagnostic logs, and deployment slots on supported tiers. Limited Azure Storage static website Use only for deliberately public, anonymous, low-complexity content when limitations are acceptable. Microsoft states that the static website feature does not provide AuthN/AuthZ and cannot configure headers without another service such as CDN. Exit Application platform Use Container Apps, App Service runtime, Kubernetes, or another application platform when server execution, state, secrets, transactions, background work, or sensitive processing makes the workload S2. External CI Static Web Apps supports custom source providers through a build job and deployment job using a deployment token. Store the token in the approved secret system, scope access, rotate on exposure or lifecycle policy, and update the calling pipeline after reset. Identity and network Authentication identifies a user; route rules authorize access. A private endpoint restricts network reachability and does not replace user authorization. DNS is part of the private-endpoint design. Central enforcement Azure DevOps required-template checks can fail a pipeline that does not extend the required template. Approvals and checks live on protected resources rather than in pipeline YAML and can stop a stage before execution. Promotion Preserve one artifact checksum across environments. Keep environment routing, identity, and policy outside the artifact where possible; if bytes change, call it a new artifact rather than “the same build.” Official Microsoft source notes Static Web Apps authentication and authorization Static Web Apps private endpoint Static Web Apps external providers Static Web Apps deployment-token management Static Web Apps configuration App Service authentication and authorization App Service private endpoints App Service access restrictions App Service deployment slots Azure Pipelines security templates Azure Pipelines approvals and checks Azure Storage static website hosting Documentation reviewed for this candidate on 2026-07-30. The bibliography download records page titles, URLs, and bounded claims used. 10 · Other platforms Keep the architecture platform-neutral Purpose-built static host Managed static-site products, object storage plus an edge layer, or a governed internal static-hosting service. Replaceable adapter Jenkins, Azure DevOps, GitHub Actions, GitLab CI, Buildkite, or another approved orchestrator. Policy and evidence Central templates, reusable actions, policy engines, signed attestations, and immutable artifact registries. Decision criteria Identity, private reachability, headers, custom domains, observability, immutable promotion, cost, support, and exit portability. 11 · Metrics and proof One successful page is not the success condition. Baseline the current path before the pilot. Compare the same workload and report the result without manufacturing a victory. Measure Current baseline 90-day target evidence Commit to Development Elapsed and queue time Same start/stop definition; lower median and tail Human work Manual actions and handoffs Fewer, with approvals preserved where required Repository burden Pipeline lines and credential count Thin adapter and centrally held environment credentials Reliability Failed deployment rate and diagnosis time Named failure domains and faster reproduction Evidence Assembly time and missing artifacts Automatic human and machine receipts Recovery Rollback steps and elapsed time Redeploy exact known-good checksum Scale Second-repository onboarding effort Materially lower than the first without weaker controls Governance Exceptions and inherited controls Exceptions visible; inherited percentage rising 12 · Serious objections Challenge the assumption without caricaturing the team “Security requires the current pipeline.” List the required controls and prove which mechanism enforces each one. Preserve the controls; replace repository-specific mechanics only when the new lane provides equal or stronger evidence. “Containers make everything portable.” They make a runtime portable. A static artifact is already portable across conforming HTTP hosts. Add a container only when its runtime contract earns the cost. “Static means low risk.” Static narrows runtime risk. It says nothing about confidentiality, accuracy, malicious content, regulated material, intellectual property, or inappropriate public release. “Azure DevOps would solve this.” A new orchestrator can host the same fragmented model. The solution is the reusable contract, qualification, controls, artifact identity, and evidence—not the logo on the YAML runner. “Build once cannot handle environment configuration.” Move host, identity, DNS, headers, and environment policy into the deployment plane where possible. When environment-specific bytes are unavoidable, produce a new checksum and stop calling it the same artifact. “A central platform will become another bottleneck.” It will if it requires bespoke tickets. Operate it as a self-service product with versioned contracts, clear service levels, observable failures, bounded exceptions, and contribution paths. 13 · Adoption roadmap Prove the lane in Development before asking for Production 30 Baseline and contract Measure one current workflow. Provision a Development landing zone. Define S0/S1/S2 and content classification. Lock the artifact, receipt, ownership, and rollback contracts. Exit: agreed baseline and approved Development experiment. 60 Template and negative proof Implement the central publishing template. Create the first thin CI adapter. Prove secret, classification, missing-owner, S2, integrity, access, and rollback failures. Generate human and machine receipts. Exit: exact artifact reaches Development without portal deployment. 90 Second repository and decision Onboard a materially different second repository. Compare lead time, handoffs, failures, evidence, and credentials. Exercise template upgrade and rollback. Seek local governance approval before any Production use. Exit: evidence-backed go, revise, or stop decision. 14 · Download the implementation kit Reusable contracts, examples, receipts, runbooks, and checklists Sanitized reference material. No credentials, employer-specific policy, production endpoint, or claim of enterprise validation is included. Implementation kit ADR, diagrams, manifests, examples, receipts, runbooks, checklists, and bibliography Portable static-directory ZIP Copy-only output with local assets, resources, inventory, and publishing contract Standalone HTML One HTML payload, served as a download-safe asset because protected SharePlane CSP prohibits inline presentation routes Architecture Decision Record Reference architecture diagram Workload qualification tree S0/S1/S2 control matrix site-manifest.yaml Thin Jenkins adapter Azure DevOps consumer Generic CI adapter contract Artifact manifest schema Human and machine receipts Adoption backlog Operator and rollback runbooks Developer onboarding checklist Production-readiness checklist Source bibliography Static-directory publishing contract Deterministic inventories and hashes Reference-only limitations 15 · Recommendation Standardize the publishing system, not the shape of every site. Give teams a narrow contract, inherited controls, immutable artifacts, observable failures, usable receipts, and a real rollback path. Keep content authority, security judgment, and Production approval intact. This Development candidate demonstrates the static mechanics. It does not prove adoption results, validate a real enterprise environment, authorize a cloud design, or justify public publication. Those decisions require local evidence and separate authority. 16 · Exact source and portability The protected evidence stays immutable. The public shell is the adapter. The accepted Development HTML, CSS, JavaScript, implementation kit, static-directory archive, and standalone HTML remain hash-bound to PR #221. This public derivative removes only Development chrome and the route-local theme controller, then composes the canonical SharePlane shell and global theme state around the approved interaction model. Inspect public integrity Inspect accepted Development hashes Open the Evidence Desk SOURCE REFERENCES The Governed Static Publishing Lane https://github.com/pinklon/shareplane-platform/issues/220 Issue #220 Development implementation https://github.com/pinklon/shareplane-platform/pull/221 Promote The Governed Static Publishing Lane to public SharePlane Production https://github.com/pinklon/shareplane-platform/issues/225