Project Summary: Creating the NZ API Standard

A Non-Technical Explanation

What We Did

The task was to transform a large collection of New Zealand government guidelines about APIs (Application Programming Interfaces) into one comprehensive, well-organized document that people can actually use.

The original guidelines were split across three separate parts with thousands of individual pieces of information. Government agencies needed these consolidated into a single standard document that follows a logical order based on how APIs are actually built and managed.

The Challenge

Imagine you have a library with 5,612 books, and you need to write a new book that combines the most important information from all of them. The catch? You can only keep about 100-200 books open on your desk at any one time.

This project faced a similar limitation. The AI system had a "memory limit" - it could only work with a certain amount of information at once. The source material was 10-20 times larger than what could fit in that memory.

The Solution: Smart Research and Organization

Instead of trying to read everything at once, the project used a three-step approach:

Step 1: Ask targeted questions and save the answers Rather than loading all the information at once, the system asked specific questions (47 questions total) and saved the answers to organized files. Think of it like creating a card catalog for a library - you don't need all the books open, just a good index of what's in them.

Step 2: Write the document using saved research When writing each section of the new document, only the relevant research files were opened. This kept the working memory clear while still having access to all the necessary information.

Step 3: Add finishing touches After the initial document was complete, additional searches found external reference links, and formatting was adjusted to meet specifications.

How the Technology Works

Two key technologies made this possible:

GraphRAG: The Smart Librarian

Think of GraphRAG as a highly skilled librarian who has read and memorized every document in the collection, knows exactly where every fact is located, and understands how different topics connect to each other.

How it works:

• All 5,612 pieces of the original guidelines are stored in a special database (called a "graph database") where every piece knows what it's related to
• When you ask a question, the system searches not just for keywords but for meaning - like asking a librarian "where's information about securing APIs?" instead of just "find the word 'security'"
• Every answer comes with a citation - a link back to the exact source - so you can verify where the information came from

Real example from this project: When the system searched for "OAuth authentication and authorization," it found 40 relevant pieces of information across all three parts of the guidelines, even though they used different wording. A simple keyword search would have missed many of these.

MCP Server: The Translator

MCP (Model Context Protocol) Server acts like a translator between the AI and the specialized database.

The analogy: Imagine you speak English, and you need information from a Japanese library. You can't read the catalog or ask the librarians directly. So you use a translator who:

1. Takes your questions in English
2. Translates them into Japanese
3. Searches the Japanese catalog
4. Gets the results
5. Translates the answers back to English

That's what the MCP server does. The AI asks questions in its language, the MCP server translates those into database queries, retrieves the information, and sends formatted results back to the AI.

Technical detail (simplified): The MCP server in this project connected to a remote database containing all the NZ API Guidelines. It provided 6 different ways to search (by topic, by type of requirement, across all sections, etc.) without the AI needing to know the technical details of how the database works.

The Process in Plain Language

Planning (30 seconds - 13:05)

Figured out the strategy: Don't try to read everything at once. Instead, organize research by topic, save results, and work section by section.

Research (35 minutes - 13:05 to 13:41)

Asked the system 47 targeted questions about different aspects of API guidelines:

• 5 questions about design principles
• 7 questions about development practices
• 7 questions about security
• 5 questions about deployment
• 8 questions about operations and management
• 4 questions about definitions
• 4 questions about patterns
• 7 questions about best practices

All answers were saved to 8 organized files by topic. Total findings: about 1,073 pieces of information with source citations.

Writing (35 minutes - 13:41 to 14:16)

Combined the research into a draft document:

• Organized by the natural progression of building an API (Design → Develop → Secure → Deploy → Operate)
• Included practical examples and code samples
• Preserved all citations so readers can trace back to original sources
• Applied judgment about what should be mandatory vs. recommended
• Result: 13,805-word document with 232 citations

Enhancement (16 minutes - 14:16 to 14:32)

Did one more search to find external reference links (like web addresses for standards organizations, tools, and best practice guides). Added 50+ complete URLs to the references section.

• Result: 14,657 words with 280 citations

Formatting (32 minutes - 14:32 to 15:04)

Created an alternative format and adjusted styling to meet specification requirements.

The Results

What was created:

• A 14,657-word comprehensive standard document
• 280 citations linking back to original sources
• 7 main sections covering the entire API lifecycle
• 5 appendices with patterns, examples, and references
• 8 research files documenting the source material

Time taken:

• Total: 1 hour 59 minutes from start to finish
• No breaks or extended gaps - continuous active work

Quality measures:

• Every statement in the document can be traced back to the original guidelines
• The "memory limit" was never exceeded (stayed at 76% of capacity)
• The document reorganizes the content in a more logical way than the original three-part structure

Why This Approach Worked

Breaking down a big problem: Instead of trying to tackle everything at once, the work was divided into manageable pieces. This is similar to how you might approach organizing a large room - you don't try to sort everything simultaneously; you work area by area.

Using the right tools: The GraphRAG system and MCP server acted like specialized assistants, each doing what they do best. The database system handled storage and search, while the AI handled synthesis and writing.

Systematic organization: By saving research in organized files, the information remained accessible without overwhelming the working memory. Like using a filing cabinet - you don't need every file on your desk, but you need to know where to find them.

Maintaining traceability: Every piece of information kept its citation, like footnotes in an academic paper. This means readers can verify any statement by checking the original source.

Comparing to Traditional Methods

Traditional approach: A person would need to read all three parts of the guidelines (thousands of pages), take notes, organize themes, write drafts, check citations manually. This would typically take weeks or months.

This approach: The AI system, aided by the smart search tools, completed the research and drafting in under 2 hours of continuous work. The systematic approach and external memory strategy made it possible to handle a volume of information that would be impractical for a human to process in that timeframe.

The trade-off: While the AI worked quickly, human oversight was essential for:

• Designing the methodology
• Deciding what information to include
• Judging which requirements should be mandatory
• Verifying the final document meets quality standards

What Made This Possible

1. Pre-organized source material: The original guidelines were already in a structured database with metadata tags
2. Citation preservation: The search system automatically included source links with every result
3. Systematic planning: The execution plan prevented the "try everything at once" approach that would have failed
4. Right-sized chunks: Breaking the work into 8 research areas meant each area was manageable
5. Clear requirements: Knowing the target audience and format from the start guided all decisions

Key Takeaway

This project demonstrates that with the right tools and methodology, AI systems can handle information synthesis tasks that would be impractical due to volume, while maintaining the quality and traceability that make documents trustworthy. The combination of smart search technology (GraphRAG), standardized data access (MCP Server), and strategic planning enabled transformation of 5,612 source documents into one cohesive standard in approximately 2 hours.