Architecture - How Wire is Built

Wire's internals for developers who want to extend, debug, or understand the system. The architecture is intentionally simple: fourteen modules with clear responsibilities, a three-layer prompt system, and three dataclasses that map directly to the file system.

Wire's design philosophy: analyze locally (free), then act with Claude (paid). Every batch command starts with database queries and local math before making any API calls. This means the expensive decisions (which pages need work, what keywords to target, which overlaps to resolve) are made before spending money.

This is not a philosophical preference. It is a cost engineering decision. The analysis phase (keyword routing, BM25 scoring, overlap detection, amendment brief generation) would cost $0.02-$0.05 per page if done through an LLM. At 500 pages, that is $10-$25 per analysis cycle. Wire does it for zero because the analysis uses local computation: SQL queries, Python math, cached database reads. Over a year of weekly cycles, the savings compound to thousands of dollars.

The architecture also reflects a lesson from the Google API leak: ranking signals are quantitative. NavBoost uses click data. siteAuthority is a numeric score. titleMatchScore is a computed metric. Content decisions based on these signals should use math, not LLM judgment. Wire reserves Claude for what LLMs do well, generating prose, and uses deterministic computation for everything else.

Editorial Model

The editorial model explains why Wire is built as three collaborating roles — Chief, Reporter, Editor — instead of a single agent. This is not a metaphor. The code was designed this way because newsroom-style separation produces better output, clearer debugging, and lower cost than a monolithic prompt. For developers building integrations, the three roles map directly to the API surface.

Modules

The module architecture explains what each of the fourteen core modules does, how they communicate, and where to find key functions. Modules share data through function calls and dataclasses, not through global state or message passing.

The module map includes the content pipeline (content.py), news intelligence (news.py), batch orchestration (chief.py), local analysis (analyze.py), GSC integration (gsc.py, db.py), shared infrastructure (tools.py), the static site generator (build.py), build-time linter (lint.py), automated QA (qa.py), discovery reading system (discovery.py), and WordPress migration (wp.py).

Prompt System

The prompt system documents the three-layer resolution: styleguide, topic prompt, and fallback template. Every Claude call goes through this pipeline. Understanding it is essential for customizing output quality. The 18 built-in prompts cover content creation, SEO optimization, news evaluation, and market intelligence reporting. The prompt architecture encodes findings from the LfM-Band 60 journalism study (verification accounts for only 7.9% of research time) and the Zyppy title study (61.6% of titles rewritten by Google).

Data Model

The data model describes the three core dataclasses (Site, Topic, Content), the file system layout, the frontmatter contract, and the GSC database schema. The validation pipeline that runs on every save is documented here: five steps from frontmatter validation through the nine auto-fixes in _sanitize_content() to quality warnings and disk write. The pipeline catches the 5% of cases where Claude's output has structural issues. At 500 pages, that is 25 pages that would ship with problems without automated validation.

Self-Assessment

The self-assessment is Wire being honest about itself: what works, what surprised us, and what we are still improving. Most tools hide their limitations behind marketing copy. Wire documents them alongside the strengths, because customers making infrastructure decisions deserve honest evaluation criteria, not sales pitches.