The original NS POS engineering brief was designed as a stakeholder-facing artifact: visually rich, highly narrative, and meant to be shared as a static document. In the new Astro structure, its role becomes clearer. It now serves as the longform anchor for the NS POS archive.

What the brief is for

This piece exists to answer a different question than a dashboard or a dependency graph. It is not for quick inspection. It is for alignment.

• It explains how architecture decisions show up in delivery outcomes.
• It gives non-implementation readers a route into technical context.
• It frames risk, change impact, and complexity in a way that can survive outside the engineering team.

What changes in the Astro version

The old artifact treated the brief as an isolated file. The Astro version turns it into part of a system.

• It becomes discoverable through the blog archive.
• It can sit beside related artifacts such as the dashboard and graph views.
• It gains a canonical URL and a cleaner entry point for future updates.

Why keep the legacy artifact around

The original HTML still has value because it captures the exact visual tone of the briefing material. Instead of discarding it, the new site keeps that artifact accessible through the project section while this post acts as the editorial summary.

That split is intentional:

• the legacy HTML preserves the original authored experience
• the Astro post makes the content easier to catalogue, link, and maintain

Migration takeaway

This is the broader pattern for the whole archive. The migration does not flatten every artifact into markdown. It gives each asset a better role:

• narrative work becomes a post
• reference work becomes a project page
• interactive work stays interactive