Colophon

How this site is built.

A site that argues for maintainability should be able to describe its own construction without embarrassment. This is that description — and, at the end, the shape of the platform it describes.

Build01

Build details

Framework
Angular, standalone components, signals for all page state
Rendering
Static prerender — 10 routes written to HTML at build time
Content
Typed objects, not Markdown. No parser ships to the browser
Styling
SCSS partials and custom properties. No CSS framework
Runtime deps
Angular and RxJS only. Nothing added for the redesign
Hosting
AWS Amplify, Route 53 for DNS
Type
Instrument Serif, Inter, JetBrains Mono
Imagery
The eye and every rule are SVG or CSS. No image assets
Choices02

Three decisions worth stating

Content is typed objects, not Markdown

A Markdown pipeline means a parser, a sanitiser, and a build step, and it moves content errors from compile time to render time. Typed content blocks give the compiler the chance to catch a malformed entry and keep the browser bundle free of a renderer it does not need. Inline markup is limited to bold, italic, code, and links — parsed into typed runs and rendered through template bindings, so authored content never reaches innerHTML.

Motion is added by JavaScript, never removed by CSS

Scroll reveals are applied at runtime by a directive. The prerendered HTML contains fully visible content, so a crawler, a reader with JavaScript disabled, or anyone whose bundle failed to load still gets the page. The usual arrangement — hide in CSS, reveal in JavaScript — makes content invisible exactly when the enhancement fails.

Reading time is measured, not authored

Every reading estimate on a record is computed from the actual word count of the rendered blocks. It is a small thing, and it is the same principle as the status labels: a number on a page should be something the system knows rather than something someone typed.

The stack it describes03

Nexus, layer by layer

Six layers, from hardware on the wire up to the surface a person talks to. The platform owns what everything needs; modules own one concern each. A module may depend on the platform — the platform may never depend on a module.

  • Operational built and running
  • In progress real code, still moving
  • Experiment a scoped trial
  • Planned specified, not built
  • Concept an idea being reasoned about

Select a component for detail. Every node states how far along it is.

Interface

Where a person meets the system.

Modules

One functional concern each. Removable without a migration.

Platform services

What every module needs and none should implement itself.

Host & runtime

The machine, the container runtime, and the single way in.

Transport

How state and commands move between devices and services.

Devices & edge

Physical hardware that produces state and accepts commands.

No component selected

Standing rule04

On the status labels

Every project, layer, and capability on this site carries a state: operational, in progress, experiment, planned, or concept. They are not decoration. They exist so that a reader can tell what runs from what is designed, without having to guess which sentences are load-bearing.

There are no metrics on this site, no uptime figures, and no customers, because there is nothing honest to put in those places. Argus is a specification with real infrastructure underneath it. When that changes, the labels change.