Applications
See all 18 articles in Applications →
Applications sit above the three-ring service layer. They consume deterministic data and optional AI output from the rings and present it through a defined interface. An application holds no canonical data — it is a view over the service layer, and can be re-provisioned without data loss by pointing a fresh instance at the immutable data underneath. The articles in this category cover both the named applications themselves and the design-intent material that explains how each surface is composed.
Each application here corresponds to an app-* directory in the monorepo and inherits the Three-ring architecture separation; none holds the authoritative record. Reader-facing chrome and design rationale articles are gathered alongside the application articles so that operators evaluating a surface can move from the engineering article to the design intent without leaving the category.
Where to start
Eighteen applications are documented here, from the public knowledge sites to the internal consoles. These six take one application from each family and are the ones other articles reference most.
- MediaKit knowledge application — The single-binary Rust wiki engine serving this site: git commits are canonical and the running binary is disposable.
- app-console-keys — console chassis and F-key framework — The always-installed base of os-console: the Cartridge trait, the F-key strip, and the status bar every other cartridge plugs into.
- Console input application — The F12 surface: the mandatory gate every external file passes through before it is sealed into the verified ledger.
- The financial and construction tool family — How tool-accounting, tool-construction, and tool-payroll share one double-entry design and connect only by one-way feeds.
- tool-accounting — double-entry ledger and audit-ready statements — The most complete of the three: a flat-file, owner-held accounting engine verified against real multi-entity historical data.
- Location intelligence platform — The customer-owned flat-file GIS application: a nightly scoring pipeline paired with an interactive rendering layer.
Knowledge and editorial applications
The wiki engine, the marketing surface, and the design-intent articles that describe their reader-facing chrome.
- MediaKit knowledge application — Single-binary Rust wiki engine serving documentation.pointsav.com — a view over a markdown tree where git commits are canonical and the running binary is disposable.
- app-mediakit-marketing — agent-authored marketing landing server — app-mediakit-marketing is a Rust web server delivering marketing landing sites from typed page manifests — AI authors via MCP, a human approves before anything publishes. Serves home.woodfinegroup.com and home.pointsav.com.
- Knowledge wiki home page — design intent — How the documentation.pointsav.com home page inherits Wikipedia's structural conventions and extends them for engineering and financial-community readers.
- Wikipedia leapfrog design — muscle memory and 5% headroom — What the app-mediakit-knowledge wiki engine inherits from Wikipedia, what it adds beyond it, and what the 5% leapfrog headroom means for readers and engineers.
- documentation.pointsav.com goes live — 2026-04-27 — The April 2026 TLS launch of documentation.pointsav.com: serving stack, placeholder posture, BCSC disclosure rationale, and verification commands.
- Proofreader console — Terminal content cartridge for the service-proofreader pipeline — operators submit text, review findings, and record a binary accept/reject verdict that feeds the apprenticeship corpus.
Location intelligence applications
The GIS analytics engine, the platform article that frames it alongside the rendering layer, and the user-experience design intent.
- GIS orchestration application — The Python data pipeline that produces the Woodfine co-location rankings and interactive map — cluster geometry rebuilt on a nightly schedule from source datasets, published as static map tiles.
- Location intelligence platform — Customer-owned flat-file GIS application for retail cluster analysis and strategic site selection, pairing a nightly scoring pipeline with an interactive rendering layer.
Input and developer surfaces
The structured-input gate that admits external files to a Totebox, and the browser workbench for working with archive files outside a terminal.
- Console input application — app-console-input is the F12 surface in os-console — a path, a confirm prompt, and a submission, through which raw external files enter a Totebox before being sealed into the verified ledger.
- Browser developer workbench — Browser-based file editor in os-privategit presenting a three-column file tree, viewer, and editor for working across the cluster archive tree without a terminal.
- app-console-keys — console chassis and F-key framework — app-console-keys is the always-installed base chassis of os-console, providing the Cartridge trait, F-key navigation strip, status bar, and auth client.
- app-console-email — communications cartridge — app-console-email is the F3 communications cartridge for os-console, providing inbox listing, message reading, and compose-and-send via service-email.
- app-console-slm — inference infrastructure monitoring console — Terminal console cartridge showing live AI inference infrastructure state — model health, the burst-GPU fleet, queue depth, and daily spend — read-only, with no controls of its own.
Domain applications
Surfaces dedicated to a specific operational domain — Building Information Modelling and real-property workflows.
- BIM and real property surfaces — How PointSav treats Building Information Modelling as a distinct operational domain — a separate customer-tier design system, a real Chart of Accounts placement, and BIM-specific console surfaces still at the research stage.
Additional planned articles for this domain — design-system tooling for BIM, AEC interface conventions, and the gap between BIM authoring tools and property-manager workflows — are not yet written.
Financial and construction tools
A family of owner-held ledger tools sharing one double-entry design: accounting, construction cost/schedule/quality control, and payroll. All three now have real, running code — tool-accounting's ledger engine, tool-construction's cost/schedule/reporting engine, and tool-payroll's first report — though the depth of what's built varies widely across the three.
- The financial and construction tool family — a shared design across three products — How tool-accounting, tool-construction, and tool-payroll relate as one product family — a shared double-entry design, one-way data feeds between them, and a shared free/paid architecture boundary.
- tool-accounting — double-entry ledger and audit-ready financial statements — A flat-file, owner-held double-entry accounting engine producing audit-ready financial statements from plain-text journals; its core engine and PDF/HTML renderer are built, verified against real historical multi-entity data, and driven by a real CLI toolchain of statement, ledger, narrative, and timeline report binaries, plus a construction-industry draw-workbook extension — CLI-only, with no console surface yet.
- tool-construction — construction cost, schedule, and quality ledger — A flat-file, owner-held ledger for construction cost, schedule, and quality control, built on the same double-entry discipline as tool-accounting; both the quantity and money ledgers now run as a real CLI against a live pilot, rendering more than a dozen reports across kick-off, ongoing-monitoring, and job-completion cadences — no console surface yet.
- tool-payroll — jurisdiction-aware payroll and statutory remittance — A jurisdiction-aware payroll and statutory-remittance engine whose first real report — a division-level Payroll Register aggregating the construction pilot's budgeted labour hours under a cited single-jurisdiction wage-rules row — is built and running; gross-to-net pay, pay frequency, and remittance computation remain design-only.
See also
- Platform Services — the service layer that applications build on
- Operating Systems — the operating systems that host applications
- Architecture — the three-ring model and the customer-ownership principles
- Design System — the token and component vocabulary the application chrome inherits