Four documents. Zero blank pages.
An AI delivery portal that turns a signed Statement of Work and its readiness checklist into grounded, review-ready implementation documents, with a consultant approving every section that reaches the customer.
- Built on the contract: SOW scope, discovery answers and checklist values flow in from a shared database.
- Grounded, never guessed: nearly 120,000 indexed chunks of the client's knowledge, and explicit flags for what it doesn't know.
- Nothing ships unreviewed: approval is blocked until every open question is resolved.
Meet our client
- Client
- PE-backed DevOps software company
- Industry
- Enterprise software, DevOps & configuration management
- Market
- Global enterprise
In a nutshell
Every implementation of the client's DevOps platform needs the same four customer documents, and consultants wrote them by hand from a blank page. We built the Implementation Execution Portal, the third system in a services chain we delivered for the client. It takes the signed SOW and the completed readiness checklist, generates Requirements, Solution Design, Implementation Runbook and User Documentation grounded in the client's own knowledge, and supports consultants with five specialist AI assistants, an AI Review Center and live management reporting.
Every engagement started on a blank page
Four documents per engagement, written by the same consultants who were running the implementation. Every section meant hunting across disconnected sources. Watch one section get written both ways.
- Blank page, four times over: Requirements, Solution Design, Runbook and User Documentation, hand-written on every engagement.
- Quality drifted: structure and depth varied between consultants and between engagements.
- No traceability: nothing linked a written section back to product docs, the signed SOW or the customer's checklist.
- Version risk: guidance could quietly come from the wrong platform release.
- Questions buried in prose: open items weren't tracked to resolution.
- No portfolio view: leadership couldn't see what was drafted, reviewed or approved, or what it cost.
- Step 1Open the engagementStart from the signed SOW written in the SOW Generator. One click opens the project, with SOW scope and checklist values already in.02 · Data chain →
- Step 2Generate the draftsRequirements generate first, per technology in scope, grounded in the client's own knowledge, the SOW and the checklist.03 · Grounding →
- Step 3Resolve open questionsAnswer each TO CONFIRM, add requested screenshots and regenerate incomplete content. An answer given once fills the same question everywhere.05 · Review →
- Step 4Approve and checkApprove each group once its flags are clear. Approved Requirements start Solution Design, and the Review Center shows what is still open across all four documents.07 · Review Center →
- Step 5Release to the customerA document downloads as a Word file once every section in it is approved. The customer receives the documents, not access to the portal.08 · Reporting →
From signed contract to delivered documentation
The portal is the third system we built for the client. It sits downstream of the SOW Generator and the Implementation Readiness Checklist, and all three share one PostgreSQL database. Step through what flows along the chain.
Grounded, never guessed
Every section is written from the client's own knowledge, retrieved for the exact scope and an approved product version. Pick a section and watch its context get built.
- Versioned platform & Configuration Management docs (Confluence)
- Freshdesk & Jira support history
- Per-technology knowledge base
- Git branching guidance & product site
- Approved sections from past engagements
- This customer's SOW & checklist
The retrieval steps are real. Queries, pages and counts in this demo are illustrative.
Four documents, generated in the right order
Headings come from versioned outline templates; the AI writes section bodies only. Generation runs as durable background jobs, and an ordering gate makes sure Solution Design never runs ahead of approved Requirements.
- Requirements: the implementation requirements for each technology in scope. Approved first, because Solution Design builds on them.
- Solution Design: how the scope will be built, generated from the approved Requirements so the two stay consistent.
- Implementation Runbook: step-by-step guidance for the actual build and configuration work, drawn from the project scope and approved design, in the same workspace as the SOW, checklist, Requirements and Solution Design.
- User Documentation: the guides needed after implementation, for end users, administrators, approvers and auditors.
It flags what it doesn't know. You approve what ships.
Instead of inventing facts, the AI writes explicit callouts into the section. A group can't be approved while any flag remains, and an answer given once fills the same question everywhere. Clear the flags and approve the group.
Only approved or consultant-refined sections of the same document type are offered. An exemplar steers the structure of the draft. Scope still comes from this engagement's signed SOW, and the prompt discourages adding technologies or integrations outside it.
Five specialists, not one chatbot
Each assistant searches different material and answers in a different shape. Each carries a project-specific description generated from the SOW, keeps per-project threads, and lets the consultant choose the model and effort.
Questions and answers are sample content, abbreviated. Sources and answer shapes match each tool.
A second pair of eyes across every document
The AI Assist tools help a consultant with one task at a time. The Review Center works across the whole engagement: cross-document checks for what's unresolved, what's at risk, how healthy the engagement is, and whether anything was approved that shouldn't have been. Open each check.
Figures from one sample engagement.
Leadership sees every engagement, live
No extra reporting effort. Weekly snapshots, activity history and AI cost are captured as the work happens, and customer downloads unlock only when a document is fully approved.
Portfolio totals are real; engagement names, people and weekly progress are illustrative. The Portfolio tab covers every engagement; the other tabs show a single engagement.
Credentials never touch the portal
Enterprise identity at the front door, every model call brokered through n8n, and every action attributed to a consultant, an AI agent or a system process. Trace a request.
- Microsoft Entra ID SSO: sign-in restricted to the client's accounts.
- Deny by default: network-level middleware blocks every route, plus an auth guard on every API route.
- Keys stay in n8n: the portal holds no Anthropic or OpenAI credentials and makes no direct provider call.
- Isolated data: portal data lives in its own schema; upstream SOW tables are read-only.
- Attributed actions: every event is recorded against a user, an AI agent or a system process.
- Self-hosted: Docker with nginx TLS termination, on the client's own infrastructure.
Inside the portal
Real screens from the Implementation Execution Portal. Customer names, consultant names, photos and internal URLs are blurred.
Grounded, reviewed, visible end to end
The Execution Portal is in production for the client's delivery consultants and runs across the active engagement portfolio.
Draft with AI. Ship with confidence.
Grounded generation, explicit unknowns, and a consultant approval between the AI and your customer.
- 01Your business objective
- 02The technical context
- 03The right next step