documentation.pointsav.com goes live — 2026-04-27
https://documentation.pointsav.com went live with TLS at 16:25 UTC on 2026-04-27. The deployment served the PointSav engineering wiki over a Let's Encrypt certificate, with automatic renewal enabled. This article is the historical record of that launch day; it does not describe the wiki's current content.
What launched on 2026-04-27
At launch, four placeholder TOPIC pages rendered at the public URL — a deliberate placeholder posture (see below), not the corpus in its current form. /wiki/welcome was the landing topic, explaining the public-preview status. /wiki/sample-article exercised the rendering chrome — table of contents, per-section edit pencils, footer block with categories, masthead band, collapsible left-rail table of contents, language switcher, and the Wikipedia layout conventions. /wiki/sample-forward-looking exercised the forward-looking-information cautionary banner and cited both [ni-51-102] and [np-51-201]. /wiki/sample-citations exercised inline citation references including the clause-reference form.
Beyond article-rendering paths, the wiki served the same operational routes it serves today: /healthz (liveness check); / (index page listing all articles); /search?q= (full-text search over the on-disk Tantivy index); /feed.atom (RFC 4287 syndication feed); /sitemap.xml; /robots.txt; and /llms.txt. There was no edit route and no collaborative-editing feature at launch — the engine has no write surface at all; every article is edited in its source git repository and picked up on the next render.
The corpus has since grown substantially: a 2026-09-04 baseline recorded 644 documents across 15 categories on this same wiki, including the applications category this article itself belongs to. What follows describes the launch-day placeholder state, not the wiki's current content.
Serving stack
Binary. A single MediaKit knowledge application binary installed at /usr/local/bin/app-mediakit-knowledge, built on the cluster feature branch. Build duration was 1 minute 54 seconds.
systemd unit. The unit runs the binary as a dedicated unprivileged system user (local-knowledge:local-knowledge) on port 9090. Hardening flags include NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, and PrivateTmp=true, with ReadWritePaths scoped to the service's own state directory and ReadOnlyPaths scoped to its configuration and content sources.
Content directory. At launch, the production --content-dir flag pointed at a four-file placeholder subdirectory, with the then-30+-article legacy TOPIC corpus held in the parent directory pending editorial refinement. That refinement has since completed and the flag now points at the ratified, substantially larger corpus described above.
nginx. Port 443 terminates TLS and reverse-proxies to the loopback service on port 9090. Port 80 serves only the Let's Encrypt HTTP-01 challenge and issues a 301 redirect to HTTPS.
OS firewall. The workspace VM runs ufw. The first certbot run failed because the VM allowed only port 22 at the OS layer, despite the GCP firewall permitting 80 and 443. The fix added ufw allow 80/tcp and ufw allow 443/tcp to the infrastructure provisioning script so future deployments inherit these ports.
DNS. documentation.pointsav.com resolves to the workspace VM's public IPv4 address via a DreamHost A record.
Placeholder posture — disclosure rationale
The four-file placeholder subtree was authored specifically to enable the public TLS launch without exposing the legacy TOPIC corpus. At the time, the legacy corpus carried known editorial debt: forward-looking framings without cautionary-banner discipline per [ni-51-102], and vocabulary items not yet compliant with the continuous-disclosure posture for each substantive edit.
The placeholder posture collapsed that surface. Four files, written to be clean from the first line, exposed only structural prose (no business-outcome claims), only verified facts, and forward-looking framings only inside the explicit demonstration topic where the cautionary-banner pattern is the point of the page. The intent was for the eventual publication of the refined corpus to land as one material-change event rather than many.
This pattern is generalizable. Any deployment that depends on a corpus being editorially ready can launch with a placeholder content tree, swap --content-dir once the corpus is ratified, and avoid an all-or-nothing flip. The source-of-truth inversion — the Markdown tree is canonical; the running binary is a view — makes this swap a single service reload.
Forward-looking items
The following are planned or intended, not committed. Cautionary language applies per [ni-51-102] and [np-51-201]. Material assumptions include the continued availability of the workspace VM and sustained editorial-pipeline activity.
The editorial-pipeline refinement this article originally anticipated has since occurred: the ratified corpus described above replaced the placeholder tree via a --content-dir swap, consistent with the single-swap pattern this article describes below.
The wiki engine is planned for further development through phases covering git2 commit-on-edit, a wikilink graph, a content-addressed federation layer, an MCP server, and a linter that hardens disclosure-class invariants.
Verification
The following checks were reproducible from any external host with TCP/443 connectivity at launch, and the routes remain live today (only the certificate dates below are launch-day snapshots, not a current, reproducible result — see the note beneath the block):
$ curl -I https://documentation.pointsav.com/healthz
HTTP/2 200
$ curl https://documentation.pointsav.com/healthz
ok
$ curl -I https://documentation.pointsav.com/wiki/welcome
HTTP/2 200
$ curl -I http://documentation.pointsav.com/
HTTP/1.1 301 Moved Permanently
$ openssl s_client -connect documentation.pointsav.com:443 \
-servername documentation.pointsav.com 2>/dev/null \
| openssl x509 -noout -dates
notBefore=Apr 27 16:24:00 2026 GMT
notAfter=Jul 26 16:24:00 2026 GMT
The certificate dates above are the original launch-day issuance window, kept as the historical record. Let's Encrypt certificates renew automatically on a 90-day cycle (per the automatic renewal noted in the opening paragraph); a live check today will show a materially later notAfter date, not the one printed here.
See Also
Cite this record: /wiki/documentation-pointsav-com-launch-2026-04-27 — revision 859f2029, last updated 5 September 2026.