Proofreader console

@@ -7,48 +7,28 @@ type: app
content_type: topic
quality: complete
index_group: knowledge-and-editorial-applications
short_description: "Operator-facing web interface for the service-proofreader pipeline, with two-tier design tokens for tenant branding and a pure-Rust apprenticeship distillation tool."
short_description: "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."
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-06-30
last_edited: 2026-08-22
editor: pointsav-engineering
cites: []
references: []
paired_with: radical-proofreader-ui.es.md
---

**Correction (2026-08-02):** the real implementation, `app-console-content`, is a **terminal UI** — `Cargo.toml` describes it as "os-console F4 Content Cartridge," depending on `ratatui`/`crossterm`, not a server-rendered HTML application. The "two-tier design token architecture" section below has no basis in this TUI. Separately, the training-pipeline claim further down (a Rust `cargo run` distillation tool producing `training_dataset.jsonl` from draft-created/draft-refined/creative-edited verdicts) is also wrong — the real distillation tool, `service-slm/router-trainer/scripts/distill_knowledge.py`, is Python, and processes an unrelated subject (Woodfine corporate email-classification skeletons), not proofreader verdicts; no such Rust binary or schema exists anywhere in the codebase. The real `/v1/verdict` POST call itself is accurate for Accept/Reject dispositions, but no "Edit" disposition call was found. **Flagged, not resolved** — needs a rewrite around the real TUI cartridge, not a wording fix.
The **proofreader console**, `app-console-content`, is the F4 content cartridge in
[[os-console]] — a terminal interface, not a web application. Operators use it to
submit text to the `service-proofreader` pipeline, review the structured findings and rewrite
it returns, and record a verdict that feeds the platform's [[apprenticeship-substrate|apprenticeship learning corpus]].

The **proofreader console** is the operator-facing web interface for the `service-proofreader`
editorial pipeline. Operators use the console to submit text for staged analysis, review
structured findings, apply or reject suggested rewrites, and record verdict dispositions that
feed the platform's [[apprenticeship-substrate|apprenticeship learning corpus]]. The console is implemented as a
server-rendered HTML application with no client-side JavaScript framework dependency; all
state transitions are handled at the server layer.

## Design token architecture

The console implements a two-tier design token architecture that decouples the platform's
visual language from any specific tenant's brand identity. The first tier consists of generic
tokens — baseline CSS variables, spacing primitives, and typographic scales — distributed
from the `pointsav-design-system` repository. These tokens establish the structural vocabulary
of the interface: grid layout, component sizing, state colours for finding severity levels, and
typographic hierarchy for the three-level finding display (Banned, Mechanical, Generative).

The second tier consists of tenant override tokens sourced from the tenant's media asset
repository. These tokens carry branding decisions — typography faces, colour palette
substitutions, and logo assets — that adapt the interface to the tenant's visual identity
without modifying the console's source code. The two tiers are applied in sequence at render
time: generic tokens establish defaults; tenant overrides substitute values where the brand
requires it. A deployment with no tenant override file falls back entirely to the generic tier,
producing a consistent baseline presentation.

This layering allows the same console codebase to serve multiple tenants under distinct brand
identities. A future `media-proofreader-pointsav` deployment would carry the vendor account's
own token overrides against the same generic substrate as the `media-proofreader-woodfinegroup`
deployment.
## Verdict recording and the apprenticeship loop

## The no-train-on-tenant-text guarantee
After the pipeline returns its findings and rewrite, the operator reviews them from the
terminal and records a verdict with a single keystroke: **accept** the rewrite, or **reject**
it and keep the original. Each verdict posts the request, the tenant, and the disposition back
to the pipeline as a typed event. There is no third "edit and resubmit" disposition — the
choice is binary.

The console surfaces the platform's data-handling commitment at the point of text submission.
The no-train-on-tenant-text guarantee is a structural property of the corpus write path, not a
@@ -61,44 +41,6 @@ The guarantee is made explicit in the submission interface because operators req
before submitting sensitive editorial material. The console surfaces it as a disclosure notice
— permanent, not dismissible — adjacent to the text submission area.

## Verdict recording and the apprenticeship loop

After the three-stage pipeline produces its findings and whole-text rewrite, the operator
interacts with the console through a verdict interface. The interface presents the original
text, the Stage-3 rewrite, and the annotated finding set simultaneously. Three disposition
controls are available: Accept (take the rewrite as-is), Reject (discard the rewrite and
retain the original), or Edit (submit a hand-modified version as the final text, with the
modification visible to the platform).

The submitted verdict triggers a `/v1/verdict` write that records the input, the chosen
output, and the operator's disposition as a typed event-pair tuple. Accepted and edited
verdicts are the highest-value training signal: they represent operator confirmation that a
specific rewrite direction was correct. Rejected verdicts are retained as negative examples
for the Stage-1 Direct Preference Optimisation pipeline. Together, these three disposition
types form the apprenticeship corpus that drives continued model refinement under the
reverse-funnel editorial pattern.

## Rust implementation and corpus distillation

The platform's training pipeline is implemented in Rust rather than a scripting language. The
distillation tool processes the raw JSONL event records written by the verdict endpoint to
extract verified input/output pairs based on operator dispositions. The tool enforces type
safety when parsing the event-pair schema — `draft-created`, `draft-refined`,
`creative-edited` — and produces a `training_dataset.jsonl` file in the format consumed by
`service-slm` for LoRA fine-tuning.

The Rust implementation unifies the operational tooling ecosystem: a single `cargo run`
invocation replaces a pipeline of shell scripts and Python preprocessing steps. It also
eliminates a class of parsing errors that can arise when the event-pair schema evolves —
schema changes require updating the Rust type definitions, which the compiler enforces at
build time rather than at runtime.

The distillation pass isolates operator-confirmed instruction/output pairs. These pairs are
the per-tenant adapter inputs for the student fine-tuning sequence, distinct from the broader
knowledge distillation run that involves the teacher model. The two training paths can run
independently or be integrated into a combined session depending on the corpus size and the
degree of adaptation desired.

## See also

- [[editorial-pipeline-three-stages]] — the three-stage pipeline the console interfaces with