Phase 1: content source of truth — 40 documents across six areas
Satisfies the Phase 1 Definition of Done: - content/ validates cleanly against the frozen schema. `make validate` reports OK: 40 document(s) validated, 0 violations. - Six areas exist, each with an L1 entry: ai-overview, platform-overview, edge-overview, products-overview, history-overview, about-overview. - All six areas have an L2 entry: ai-systems, platform-estate, edge-fleet, products-business, history-engagements, about-narrative. - 28 L3 artefact stubs under content/<area>/l3/. Every artefacts[].url in every document resolves to one of them; the validator proves there are no dangling references (and a deliberately broken copy exits 1). - Every metric value traces to a source line in the evidence notes or the approved metric set in reference/content-map.md (per-metric citations are recorded in the AUD-131 completion comment). - Every document carries confidence and last_verified=2026-10-26; the validator rejects a missing or non-canonical value. - docs/content-redaction.md records the redaction pass: identifiers, third party personal data, credentials and infrastructure detail excluded, with reasons, plus the two numbers that are reported rather than smoothed. Honesty positions held: 3 businesses active (12 adoptions over time), Where-Woof deployed and pre-market, failures kept in (edge-failures), no promotion of in-progress work to delivered. No site code, no templates, no CSS, no rendering (Phase 2).
This commit is contained in:
Documenter
35
content/platform/l3/platform-backups.md
Normal file
35
content/platform/l3/platform-backups.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: platform-backups
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — Backups and restore runbook"
|
||||
claim: "Three tiers — local snapshots · a copy on another machine · an offsite copy — with retention stated in the job and a restore runbook kept beside them."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [Borg, Kopia, Backrest, AWS S3, systemd, NFS]
|
||||
metrics: [{label: "backup tiers", value: 3}, {label: "retention windows in the primary job", value: 3}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, backups, restore, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Backups and restore runbook
|
||||
|
||||
**Status: stub.** Redacted job definitions and the restore runbook land in Phase 7. Passphrase locations and remote paths are removed before publication.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The backup design: Borg jobs on the two desktop hosts to local storage with a network copy, Kopia and Backrest on the edge host to network storage, an offsite copy in object storage, and retention expressed in the job (seven daily, four weekly, three monthly, plus annual on the edge). Beside it, the restore runbook and the list of what is deliberately not covered.
|
||||
|
||||
## What it proves
|
||||
|
||||
That failure was designed for: three tiers cover disk loss, machine loss and site loss, and the restore path is written down rather than recovered from memory at the worst possible moment.
|
||||
|
||||
## Limits stated on the page
|
||||
|
||||
Not everything is covered, and the page says so — one storage host is itself a single point of failure for some repositories, and the file server has no backup of its own. Those are known gaps with owners, not oversights to be hidden.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source: the infrastructure reference and the backup system notes, read 2026-10-26.
|
||||
31
content/platform/l3/platform-containers.md
Normal file
31
content/platform/l3/platform-containers.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: platform-containers
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — Container inventory"
|
||||
claim: "Fifty or more containers across the estate — each with its own port · its own folder · and a memory cap equal to its swap cap."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [Docker, Compose, Caddy, Proxmox]
|
||||
metrics: [{label: "containers in the estate", value: 50}, {label: "memory cap rule", value: "mem_limit equals memswap_limit"}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, docker, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Container inventory
|
||||
|
||||
**Status: stub.** A digest of the inventory — grouped by purpose, with addresses removed — lands in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The inventory generated from the hosts, grouped by purpose: media and file services, home automation, the AI services, the public edge, and the build tooling. For each service the same three facts are recorded — port, configuration folder, memory cap.
|
||||
|
||||
## What it proves
|
||||
|
||||
That the estate is inventoried rather than accumulated, and that the resource rules are applied per service instead of being a policy on a wiki page.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7, generated from the live hosts. Counts follow the approved metric set; the exact number is regenerated at capture time.
|
||||
31
content/platform/l3/platform-network.md
Normal file
31
content/platform/l3/platform-network.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: platform-network
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — Network layout and remote access"
|
||||
claim: "A private mesh and SSH everywhere · services bound to loopback · and one public listener at the edge terminating TLS for the sites that are allowed to be seen."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [Tailscale, SSH, Caddy, DNS, Termux]
|
||||
metrics: [{label: "public listeners per service", value: 1}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, networking, security, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Network layout and remote access
|
||||
|
||||
**Status: stub.** The topology diagram lands in Phase 7 with addresses and hostnames redacted.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The layout: hosts on a private mesh for remote access, SSH on every machine, a phone used as a terminal, and an edge host that terminates TLS and proxies to loopback-bound services. New services bind to loopback by default; making something public is an explicit edge change, not a side effect of starting a container.
|
||||
|
||||
## What it proves
|
||||
|
||||
Security posture chosen rather than inherited: no service is reachable because it happened to bind to all interfaces, and there is exactly one place where the outside world meets the estate.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Internal addressing, hostnames and public DNS names are excluded from publication by the redaction pass.
|
||||
35
content/platform/l3/platform-nixos.md
Normal file
35
content/platform/l3/platform-nixos.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: platform-nixos
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — Declarative multi-host configuration"
|
||||
claim: "Machines are described rather than assembled — a shared NixOS base · a replicated desktop and terminal · and Proxmox underneath the virtualised side."
|
||||
confidence: running
|
||||
period: "2020–"
|
||||
tech: [NixOS, Niri, Proxmox, Neovim, Zsh, Ghostty]
|
||||
metrics: [{label: "hosts on the declarative base", value: 4}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, nixos, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Declarative multi-host configuration
|
||||
|
||||
**Status: stub.** A redacted excerpt of the configuration tree lands in Phase 7. No hostnames, addresses or keys are published.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The shape of the configuration: one shared base, per-host modules, and the parts that make the desktop and the terminal identical everywhere — window manager, editor, shell and the plugins that carry the work. Proxmox hosts the virtualised side, including the file server and the home automation appliance.
|
||||
|
||||
## What it proves
|
||||
|
||||
That a machine can be rebuilt from a description, and that the same environment follows the person between machines instead of being re-created by memory.
|
||||
|
||||
## Limits stated on the page
|
||||
|
||||
The terminal-first setup is deliberate: a heavier desktop was downgraded to the terminal on one machine for memory headroom. A phone-as-server experiment is on hold, not shipped, and is described as on hold.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. Source facts: evidence notes section 3.
|
||||
31
content/platform/l3/platform-signage.md
Normal file
31
content/platform/l3/platform-signage.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: platform-signage
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — Signage infrastructure · screens as a managed fleet"
|
||||
claim: "HDMI-CEC control of power · rotation · mirroring and multi-screen layout — so a display fleet is driven by the platform rather than by a remote control."
|
||||
confidence: delivered
|
||||
period: "2014–"
|
||||
tech: [HDMI-CEC, Raspberry Pi, Python, JavaScript, FFmpeg]
|
||||
metrics: [{label: "commercial deployments evidenced", value: "salon · financial services business"}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, signage, hdmi-cec, artefact]
|
||||
---
|
||||
|
||||
# Artefact — Signage infrastructure · screens as a managed fleet
|
||||
|
||||
**Status: stub.** The CEC command set and a layout diagram land in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
The platform side of the signage product: the codes and control path that switch screens on and off, rotate and mirror output, and lay out multi-screen displays, including synchronised playback across screens in one site.
|
||||
|
||||
## What it proves
|
||||
|
||||
Device-level control combined with fleet management. This is the same skill the edge pages show on small devices, applied to physical displays that other people depend on.
|
||||
|
||||
## Confidence
|
||||
|
||||
`delivered` — this ran in commercial deployments. The product's business status is stated separately on the Products pages, where the honest position is that the software is being rebuilt and three businesses still run it.
|
||||
31
content/platform/l3/platform-tuios-package.md
Normal file
31
content/platform/l3/platform-tuios-package.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: platform-tuios-package
|
||||
area: platform
|
||||
level: 3
|
||||
title: "Artefact — A hand-written Nix package with an exit plan"
|
||||
claim: "Twenty-five lines of Nix that pin a tool at 0.10.1 over nixpkgs' 0.7.0 — with a verified hash · a written reason and a written condition for deleting the file."
|
||||
confidence: running
|
||||
period: "2026–"
|
||||
tech: [Nix, NixOS]
|
||||
metrics: [{label: "pinned version", value: "0.10.1"}, {label: "nixpkgs version it overrides", value: "0.7.0"}]
|
||||
artefacts: []
|
||||
public: true
|
||||
last_verified: 2026-10-26
|
||||
tags: [platform, nix, packaging, artefact]
|
||||
---
|
||||
|
||||
# Artefact — A hand-written Nix package with an exit plan
|
||||
|
||||
**Status: stub.** The whole file is short enough to publish verbatim; it lands in Phase 7.
|
||||
|
||||
## What the artefact is
|
||||
|
||||
A package definition for the agent operations console: `fetchurl` against a released artifact with a verified hash, a documented reason for overriding nixpkgs, an `installPhase` that stages the binary, and a comment stating the condition under which the file should be deleted.
|
||||
|
||||
## What it proves
|
||||
|
||||
More than knowing Nix exists. The signals are that someone noticed a version gap, fixed it locally instead of waiting, pinned it so the fleet is reproducible, and wrote down when to remove their own patch. Knowing when to delete your own override is the senior part.
|
||||
|
||||
## When it is delivered
|
||||
|
||||
Phase 7. The file is in the infrastructure repository; source fact: content spine section 4.2.
|
||||
Reference in New Issue
Block a user