Architecture Portfolio · 2025–2026 · Page 01

The document that writes
itself — explained,
reviewed, and owned
by its author.

An explainability-first, human-gated documentation pipeline for technical writers — designed for both feature-release authoring and document-driven development, from intake through to a Google Style Guide-compliant first draft. Five agentic stages. One human gate. Zero black-box decisions.

XAI — Explainability First Client-Side · Zero Server Google Developer Style Guide Groq · Llama 3.1 LangGraph Pattern · JS GitHub Pages · Free Tier Agile + Waterfall 2 Personas · 1 Pipeline
5
Agentic
Pipeline Stages
80
Style Guide
Rules Enforced
2
Writer
Personas Served
0
Black-Box
Decisions Made
01 — Why Now

Three forces converged.
Simultaneously.

For an autonomous documentation pipeline to be architecturally viable, three conditions had to be true at once: LLM output quality had to reach professional-grade for technical prose, a widely-adopted style guide had to be machine-checkable with sufficient specificity, and agentic tooling had to be mature enough to support stateful multi-step workflows without bespoke orchestration infrastructure. In 2025, all three arrived.

2022 2023 2024 2024 Q3 2025 Q1 2025 Q3 LLM output quality Style guide machine-checkability Agentic tooling maturity CONVERGENCE WINDOW CAPABILITY MATURITY
Diagram 01 Three enabling forces — LLM output quality, style guide machine-checkability, agentic tooling maturity — converging in 2025 Q3
Force — 01

LLMs reached professional-grade technical prose

Llama 3.1 405B and Mixtral 8x22B produce technical documentation that satisfies style guide requirements without extensive post-editing. This isn't incremental — it crosses the threshold from "assisted drafting" to "first-draft quality" for well-defined document types. The accuracy ceiling for hallucination-prone content (API endpoints, parameter types) is managed by grounding the Draft Agent in context the writer provides, not model memory.

Llama 3.1 · 2024–25
Force — 02

The Google Developer Style Guide is machine-checkable

Unlike generic style guides, the Google Developer Style Guide for technical writers is specific enough to encode as deterministic rules. Active vs passive voice, second-person address, present-tense verbs, heading capitalisation, Latin abbreviation avoidance — these are binary checks, not aesthetic judgments. For the first time, "does this document comply?" is a question an LLM can answer with citations, not a question that requires a human editor.

Google Style Guide · 2024
Force — 03

Agentic pipelines are production-grade without infra overhead

LangGraph's stateful agent graph pattern, adapted to JavaScript, enables a multi-agent pipeline that runs entirely in a browser — no orchestration server, no managed infrastructure, no vendor lock-in. Each agent has defined inputs, outputs, and a state machine. The pipeline is inspectable, testable, and reproducible from a static GitHub Pages deploy. This is architecturally significant: agentic maturity no longer requires a cloud backend.

LangGraph · JS · 2025
Force — 04

Client-side AI is fast enough to be useful

Groq's inference API delivers Llama 3.1 responses at 300+ tokens/second. A full five-agent pipeline — intake, research clarification, draft, compliance check, review prep — completes in under 45 seconds on a standard internet connection. The Autonomous Author's entire pipeline runs from the browser, calling Groq directly. No server round-trips. No data leaving the writer's session without their knowledge. Speed and privacy are now simultaneously achievable.

Groq API · 300+ tok/s · 2025
02 — The Problem

Two writers. Two broken
workflows.

Technical writing dysfunction manifests differently depending on whether the writer is downstream or upstream of code. Both are real, both are costly, and existing tools address neither with architectural rigour.

PERSONA 1 — FEATURE RELEASE WRITER (AGILE) PERSONA 2 — DDD AUTHOR (WATERFALL) Ticket / PR arrives Context gathering 2–3 day SME wait First draft written Review cycle 3–5 days avg 2.4 rounds Compliance check (skipped) Published (style violations) Feature intent statement Spec draft (ambiguous terms) No ambiguity detection Dev builds wrong thing Dev review gate No compliance check Approved (defects shipped) Latency / failure point Absent / skipped step Neutral step
Diagram 02 As-Is DDLC pain map — both personas. Red nodes = latency or failure points. Dashed = absent steps in current workflow.

Context starvation

The writer is last to know. Ticket arrives, SMEs are in standups. The first 2–3 days of every doc sprint are spent chasing context that should have been packaged with the feature work.

→ Intake + Research Agents address this directly

Compliance as afterthought

Style guide checks happen informally in review, if at all. Violations accumulate. Published docs carry passive voice, Latin abbreviations, inconsistent second-person address — all detectable, all preventable.

→ 80-rule Compliance Agent, mandatory before review

DDD ambiguity ships as code

A spec that says "the system should respond quickly" causes a developer to make a judgment call. That judgment call becomes a bug. The DDD author has no tool that treats vagueness as a defect before the spec leaves their hands.

→ Ambiguity Detector — DDD-exclusive second pass
03 — Philosophy

Four principles. The design
cannot break them.

These are not best-practice guidelines. They are architectural constraints that every component of The Autonomous Author must satisfy. Any design decision that violates a principle requires a documented rebuttal explaining the trade-off and the alternative considered.

I
Augment the writer — never replace their authorship

The Autonomous Author drafts, checks, and structures. The writer authors. Every agent in the pipeline produces material for the writer's review, not for direct publication. The human gate — review and approval — is not optional, not bypassable, not a checkbox. It is the architectural contract between the pipeline and the writer. The tool makes the writer faster, better-informed, and more consistent. It does not make decisions on their behalf.

Human Gate — Non-negotiable · XAI Layer
II
Explainability by default — every suggestion has a why

Every agent in the pipeline surfaces a reasoning card before passing control to the next stage. The card states what the agent understood, what it decided, why it decided it, and what it was uncertain about. Compliance violations are cited against named rules. Draft decisions are traceable to context the writer provided. Confidence scores accompany every output. The writer should be able to audit the pipeline's reasoning without running it again.

XAI — Explainability First · Reasoning Cards
III
Compliance is a property of the document — not a final check

Style guide compliance is enforced during the pipeline, before the writer sees the draft. The Compliance Agent runs against every draft before review prep begins — not as a linting step the writer can skip, but as a mandatory pipeline stage that annotates violations, cites the rule number, and suggests a fix. The writer receives a document that has already been checked, annotated, and is ready for their decisions on each flagged item. Compliance is structural, not optional.

Google Developer Style Guide · 80-Rule Enforcer
IV
Fit the groove — workflow-neutral, not workflow-replacing

The Autonomous Author does not require the writer to adopt a new system, learn a new process, or restructure their existing workflow. Intake accepts whatever the writer currently works from — a Jira ticket, a PR description, a Notion brief, free text. Output is Markdown, HTML, or clipboard-ready text. The pipeline wraps around existing motion; it does not redirect it. An individual writer at any enterprise, using any documentation system, can run the pipeline from a browser tab and return to their normal tools with a compliant first draft.

Workflow-Neutral · Client-Side · Zero Install
04 — Architecture

Three layers. One
coherent contract.

Each layer has a single responsibility and a clean interface to the layers above and below it. XAI reasoning cards and compliance reports flow upward from Layer 2 to Layer 1. The writer's input and decisions flow downward from Layer 1 into Layer 2. Security and persistence constraints are enforced at Layer 3 — they cannot be overridden by the application layer above them.

This is a concept overview. The full technical architecture — client-side stack, agent topology, state management, Groq API integration, and GitHub Pages deployment — is developed in Page 03 (Design) and Page 06 (Infrastructure).

LAYER 01 — WRITER INTERFACE Intake Form Ticket / PR / Free text Pipeline Monitor Live agent reasoning Review & Edit UI Human gate · Diff view Compliance Report 80-rule annotations Export Panel MD · HTML · Clipboard HUMAN GATE XAI Reasoning Cards · Writer decisions · Persona selection · Session history · Groq API key · Export to any format Agent outputs · Reasoning cards · Compliance reports LAYER 02 — AGENT PIPELINE Intake Agent Doc brief Research Agent Context pack Draft Agent P1 / P2 mode Compliance Agent 80-rule check Review Prep Agent Writer-ready view Ambiguity Detector (DDD) P2 only XAI Layer All agents x API calls · State reads · Session writes LAYER 03 — CLIENT-SIDE INFRASTRUCTURE GitHub Pages Static hosting · CDN Groq API Llama 3.1 · Free tier IndexedDB Session state · History localStorage API key · Preferences Compliance Rule JSON 80 rules · Versioned asset Zero Server No data leaves browser GitHub Actions CI/CD · Writer's API key in localStorage · No backend · No auth server · No data store except writer's own browser Security guarantee: Document content passes only to Groq API during active session · Writer retains full custody of all materials
Diagram 03 Three-layer architecture overview — Writer Interface · Agent Pipeline · Client-Side Infrastructure. Full technical detail on Page 03 and Page 06.
Layer 01

Presentation & Experience

Intake form, live pipeline monitor, review UI with diff view, compliance report, export panel. The only thing the writer sees. Persona selection (P1/P2) and Agile/Waterfall mode live here.

Layer 02

Agent Pipeline

Five sequential agents — Intake, Research, Draft, Compliance, Review Prep — plus the DDD-exclusive Ambiguity Detector. Each agent has a defined input contract, output schema, and XAI reasoning card. Full detail on Page 04.

Layer 03

Client-Side Infrastructure

GitHub Pages hosting, Groq API (writer-provided key, localStorage), IndexedDB for session persistence, compliance rule JSON as a versioned static asset. Zero server. No data exfiltration beyond the writer's own API calls. Full detail on Page 06.

Six properties this architecture delivers — by design
01
Persona-aware pipelineThe same pipeline serves two fundamentally different workflows without compromise. P1 mode produces feature docs. P2 mode produces DDD specs. The Ambiguity Detector fires only in P2 mode.
02
Workflow-mode awareAgile mode is delta-aware, fast, and assumes an existing doc may need updating. Waterfall mode is rigorous, gated, and treats each document as a formal artifact with version history.
03
Compliance-grounded80 Google Developer Style Guide rules encoded as a structured JSON asset. Every check cites the rule. No hallucinated citations. The writer can look up every flagged item.
04
Genuinely multi-agentNot one LLM with a long prompt. Five agents with single responsibilities, defined output contracts, and visible reasoning. Each stage is independently testable and replaceable.
05
XAI-transparentEvery agent surfaces a reasoning card. Confidence scores accompany every output. The writer audits the pipeline's logic without re-running it. Trust is earned through visibility, not assumed.
06
Zero-server security modelThe writer's API key never touches our infrastructure. Document content passes only to Groq during an active session. Sessions persist in the writer's own browser. This is the enterprise security argument for client-side architecture.