KnowledgeForge: mining gold from the ITSM ticket graveyard

KnowledgeForge is built around a familiar enterprise mess: support teams solve the same problems over and over, but the fix lives and dies inside ticket history. The project tries to pull that knowledge out of resolved ITSM tickets and turn it into something reusable, while also scrubbing the existing knowledge base so it stops feeding people stale or duplicated answers.

The design has two halves that feed each other. Generation takes clusters of related incident tickets and turns them into draft knowledge base articles and root cause analysis documents. Curation then sorts articles by type, checks for duplicates, scores quality, and rewrites weak content before sending the result to ServiceNow for a knowledge manager’s review. That human approval step stays in the loop. So does the memory: curation stores vectors for every article, and generation reads them back as grounding on the next run.

On the generation side, the workflow starts when an upstream process groups resolved incidents by problem and writes them to Amazon S3 as a customer-scoped JSON file. A new file triggers Amazon SQS, an Amazon ECS service on AWS Fargate picks up the queue, and each task can process up to five themes at once. Before the model writes anything, it retrieves the five most similar existing articles from that customer’s Amazon S3 Vectors index, using them as reference context. If there are no suitable reference articles yet, it falls back to the ticket data alone and flags the procedures for review. The model is Anthropic Claude Sonnet 4.5 in Amazon Bedrock, and it streams output so the container can assemble the article as tokens arrive.

The article format is fixed. One output is a knowledge base article with title, summary, symptoms, root cause, resolution steps, prevention, and related topics. The other is a root cause analysis document with executive summary, problem description, customer impact, five-why analysis, workaround, resolution, corrective and preventive actions, timeline, and cause code. AWS Fargate was chosen because this work is bursty and long-running: a single theme can take several minutes, and a busy file can hold many themes. A long-lived container service that scales with queue depth fits that shape better than short-lived functions.

Curation is where the pipeline gets picky. Every article gets a 1,024-dimension embedding from Amazon Titan Text Embeddings V2 and lands in a per-customer Amazon S3 Vectors index. That same index doubles as a duplicate detector. The system looks for near neighbors using cosine distance, starts with a threshold of 0.05, and keeps the fresher article when it finds a duplicate pair. Then AWS Step Functions runs a two-phase distributed map to classify, embed, deduplicate, score, and improve articles, with retries, failure handling, and a daily trigger from Amazon EventBridge. It keeps state small by passing S3 pointers instead of stuffing article bodies into the workflow, and it uses a FIFO queue plus sequential deduplication inside each batch to keep duplicate handling consistent.

The whole thing is a neat example of boring infrastructure doing useful work. Not flashy, just practical: old tickets in, cleaner knowledge out, with the model kept on a short leash and a human still signing off. That’s the part worth copying.