Publishing Agent.
A home-lab architecture study using fictional documents and a mock catalog to separate document preparation, deterministic validation, and human publication approval.
State model, tool boundary & validation design
A home-lab design for state-aware document preparation.
HUMAN DIRECTION → CONSIDERED SYSTEMSSpecify state-aware tool selection without granting the model publication authority.
Not every document needs every step
The applied Knowledge Publishing workflow separates useful transformations, but a person decides which one to run next. A clean document, a document missing metadata, and a document with broken links should not necessarily follow the same path.
Casey’s home-lab architecture study asks how a system could select the next useful transformation while preserving human publication authority. It uses fictional documents and a mock catalog as the design setting. It is an architecture study, not a proven completed implementation; the case study describes decisions and planned validation rather than operational results.
Specify responsibility before implementation
Casey defined the agent’s responsibilities, state model, approved-tool boundary, validation and retry behavior, and approval and audit requirements. The design builds on a documented observation from the earlier workflow: the human operator was responsible for selecting each next action.
The proposed model would interpret document state and choose among approved transformations. Deterministic validators and an enforced approval transition would carry the requirements that must hold regardless of the model’s interpretation. The contribution is architecture and control design; no completed implementation, model training, or deployment is claimed.
Inspect state, choose a tool, validate the result
The specified flow begins with untrusted document content. The agent would classify article type, identify missing sections or metadata, detect link issues, and select an approved template or transformation. It would then submit the result to required-field, structure, link, and style checks implemented in deterministic code.
A failed check would lead to a bounded correction attempt. Reaching a retry limit would cause a safe stop and escalation, not unrestricted improvisation. A valid result would move to a human approval request. An audit trail and versioned output artifacts would preserve the tools used, decisions, retries, and final disposition.
Adapt the path without widening the authority
The design gives the model discretion over which approved transformation to choose, rather than permission to invent tools or publish. An allowlist limits the capability set, and a constrained service identity is part of the proposed security boundary.
Deterministic checks introduce implementation work and require clear rules, but they make validation independent of the model that generated the content. Human approval also creates a deliberate stopping point. The goal is a more adaptive preparation process, not the removal of every human interaction.
An approval request is not an approval control
A source document could contain instructions that conflict with the system’s tool policy. The design treats that content as data to inspect, not authority to change capabilities. The prompt-injection defense is expressed as a proposed control boundary, not as a tested guarantee.
Similarly, “ask a human before publishing” would be insufficient if it were only a sentence in a prompt. The specified state machine makes approval a required transition and keeps publication separate from content generation. Retry limits and safe stopping define what happens when the system cannot reach a valid result.
Define the tests without claiming they ran
Planned validation covers known-good guides, malformed or incomplete documents, injected instructions in source content, tool failures, and retry-limit cases. The expected behavior is to choose only approved actions, surface validation failures, and stop safely instead of guessing or bypassing approval.
These tests have been specified, not executed for a completed implementation. The current outcome is a documented architecture with defined responsibilities and control requirements. This makes the design reviewable while keeping the distinction between an architectural proposal and demonstrated operational behavior explicit.
Make human oversight a property of the system
Translating the earlier workflow into states, tool boundaries, validation rules, and stop conditions demonstrates a progression from operating AI stages to specifying agent behavior. The design identifies which decisions can use probabilistic interpretation and which need deterministic enforcement.
The skill developed is architectural precision: naming the authority a model may hold, identifying untrusted inputs, and defining evidence needed before release. Human oversight becomes a state transition that can eventually be tested, rather than a reassuring phrase attached to an otherwise unconstrained system.
Home-lab architecture study using fictional documents and a mock catalog. Operational implementation and validation are not claimed.
↖ Return to the world Keep exploring