Multi-Stage Knowledge Publishing Workflow

Mission

Make Self Help publishing less slow and less inconsistent without handing publication authority to a model.

Problem

This project was created at Chelan County PUD on the service desk, the team I was part of. Preparing ServiceNow Self Help content was slow and inconsistent: formatting varied between authors, metadata was thin enough to hurt search and discoverability, and converting finished guides into publishable HTML was manual work.

Constraints

• Each custom GPT owned one narrow stage of the publishing process.
• An operator drove the sequence by hand — this is a fixed LLM workflow, not an agent.
• No content reached ServiceNow unreviewed.

My role

A senior IT specialist led this work and I joined as a team member. He designed the multi-GPT approach and owned the stage definitions; I worked alongside him running content through the pipeline, testing output against real self-help guides, and feeding back where formatting, metadata, or HTML generation broke down. I did not lead this project. It was my first hands-on exposure to AI as something you architect in stages rather than prompt in one shot.

Architecture

Specialization of LLM roles: standardize, extract metadata, generate HTML. Downstream stages received predictable input because formatting standards were enforced upstream. Metadata extraction was its own stage because search in ServiceNow depended on it.

Build process

1. Stage definitions owned by the specialist leading the work.
2. Content run through standardize → metadata → HTML against live guides.
3. Failure modes reported back; prompts and stage boundaries refined from there.

Validation

Lessons

• Who determines the next action

  This was a strong LLM workflow but not a full agent, because a person decided each next step. Recognizing exactly where that line falls is the single most useful concept I took from this project.

Cybersecurity equivalent

• Human review before publicationmaps toPrivileged change authorization
• Inspectable stage outputmaps toDetective control at each hop, not only at the end
• Operator-driven sequencemaps toLimited blast radius, limited adaptability

AI principles applied

• LLMs as bounded components

  Models draft, classify, and summarize. They do not own authority, publication, or remediation.

  Where learned: First as specialized GPTs on a service-desk publishing workflow, then as Gemini inside TinyClaw and a domain Gem.

  See in the AI map →

• Prompt and role configuration

  Persistent role, rules, and output contracts — not a one-shot instruction.

  Where learned: Applied as a specialized Gemini Gem for a specific vehicle-maintenance domain.

  See in the AI map →

• LLM workflows

  A predefined sequence of LLM and non-LLM steps. Reliable, path largely fixed.

  Where learned: Chelan County PUD Self Help pipeline; TinyClaw scheduled reporting.

  See in the AI map →

• Structured outputs

  Contracts the next stage can consume: HTML stages, morning reports, triage JSON, workbook tables.

  Where learned: If formatting can drift, downstream consumption silently breaks.

  See in the AI map →

Security principles applied

• Change control

  Publication, packaging, and deploy are privileged transitions with a human on the gate.

  Where learned: Clearward release architecture; Basaltborne draft vs published; Self Help human review.

  See in the security map →

• Physical / operational security systems

  Operational security thinking from service-desk work and from treating a lab VM as hostile rather than trusted.

  Where learned: Professional context at Chelan County PUD; host-side separation during triage testing.

  See in the security map →

Technologies

• Custom GPTs
• ServiceNow Knowledge
• HTML
• Documentation standards

Skills demonstrated

• Multi-Stage LLM Workflow Design
• Role Specialization
• Prompt Design
• Metadata Extraction
• Documentation Standards
• HTML Generation
• ServiceNow Knowledge Publishing
• Human Review Gates