Personal Information Systems

One of the phrases I've started using for the kind of work I do is "Creating Clarity From Complexity." Most of my professional examples are communications, operations, reporting, dashboards, knowledge systems, and digital experience, but I've realized I bring the same thinking to my own projects. I'm a musician. I play keyboards in a few rock-leaning bands across a pretty wide range of repertoires, rooms, and musical demands, and I own a pile of keyboards. Three of my main gigging instruments (the Korg Triton, the Korg Nautilus, and the Roland AX-Edge) each posed a genuinely interesting information-management problem. Every one of them has its own capabilities, limitations, documentation, sounds, custom patches, set lists, performance notes, and accumulated lore. The information wasn't missing. There was just too much of it, and none of it was organized around how I actually use the instruments.

The Problem

Keyboard manufacturers document their instruments well, and the manuals will happily tell me exactly what a given parameter does. That's rarely the question I'm asking, though. My question is more like: I've got rehearsal tomorrow, I need a sound for this part of this song, and which of these thousands of programs do I even start with?

I've got rehearsal tomorrow. I need a sound for this particular part of this particular song. Which of these thousands of programs should I start with?

Those are completely different questions. The manufacturer's documentation is built to explain the instrument, and I needed something built around using it. On top of that, I had information that lives nowhere in any manual: my own patches, set lists, performance notes, backup history, hardware worries, and plans for projects I haven't built yet. So I built systems that pulled all of it into one place.

The Solution

Using Kiro, an AI-powered development environment, I built personalized local reference sites for each instrument. These aren't copies of the manuals. They're purpose-built information systems that fold together three layers of knowledge:

Manufacturer documentation

Manuals, parameter guides, voice lists, editor documentation, and other reference material are extracted and reorganized into searchable web content.

Personal instrument data

My actual programs, combinations, set lists, performance notes, backup information, hardware details, and other instrument-specific information become part of the system.

Creative workflow

The sites also support the work I'm actually trying to get done: finding candidate sounds for songs, planning layers, auditioning patches, tracking progress, and writing down decisions. The result is a reference system organized around my workflow instead of the manufacturer's information architecture.

Turning Documentation Into Usable Information

There's a lot of source material behind these instruments. Across the three systems I've processed more than 1,500 pages of manufacturer documentation along with thousands of individual program and sound definitions. For the Korg Nautilus alone, the system covers:

• 269 pages of Operation Guide material
• 965 pages of Parameter Guide material
• 309 pages of Voice Name List information
• 1,792 individual program entries
• Information covering multiple sound engines and instrument modes

Instead of searching through PDFs over and over, the information gets turned into structured data the site can search, filter, organize, and present in the context of the instrument. This is one of the places AI-assisted development really earned its keep. The hard part was never writing a web page. It was the tedious work of extracting, interpreting, structuring, and organizing a huge amount of information.

Making the Keyboard's Own Data Accessible

The Nautilus posed a different problem. It stores its configuration in a proprietary .PCG backup file that holds programs, combinations, set lists, and other instrument state, and that file isn't something I can just open and browse on my computer. I used Kiro to dig into the binary structure of the files and build tools that pull useful information out of them, which let the support site surface things that used to live only inside the keyboard. The system can identify custom combinations, their bank and slot locations, their set-list relationships, and the performance notes I've attached to them, and it can show which banks are in use and which are free for future work. That matters. The project isn't about writing better documentation. It's about taking information that was locked away or scattered and turning it into something I can actually work with.

From Reference Tool to Creative Workspace

The most interesting turn was moving past reference material entirely. I'm preparing sounds for a new musical project right now, and for each song I can describe the kinds of sounds I need and give the musical context, and the system works through the available programs to find candidates. Instead of searching "bass" and scrolling, I can describe the character I'm after in the setting of the song, and then audition the candidates on the actual keyboard. The Nautilus also lets me build combinations from multiple timbres, so the system helps me think past individual programs toward layers that complement each other. The workflow becomes:

Identify → Search → Evaluate → Audition → Select → Build → Document

As I move through the songs, the system tracks progress and records the decisions I've made. By that point the support site has stopped being a manual. It's part of the creative process.

Three Instruments, Three Approaches

The three systems aren't identical, because the three instruments aren't either.

Korg Triton

The Triton is a 1999-era instrument with aging hardware, legacy operating-system limitations, and a very different approach to backup and configuration. Its support system therefore places more emphasis on hardware considerations, documentation, programs, combinations, and practical reference information.

Korg Nautilus

The Nautilus presented the largest information-management challenge. Its support system incorporates extensive searchable documentation, thousands of programs, proprietary backup-file extraction, set-list cross-referencing, performance notes, backup tracking, and creative sound-development workflows.

Roland AX-Edge

The AX-Edge required a different approach because much of its editing workflow is built around its companion mobile application. Rather than reproducing a large parameter database, the support system focuses more heavily on the editor workflow, connectivity, patch management, and practical operating procedures.

The principle held across all three. The implementation changed to fit the problem.

What AI Changed

I could have built these systems by hand. I probably wouldn't have. The sheer amount of extracting, parsing, restructuring, cross-referencing, and repetitive development would have made the whole thing impractical for a personal tool. AI-assisted development changed that math. Kiro let me move between very different kinds of work:

• Extracting information from hundreds of pages of PDFs
• Transforming documentation into structured data
• Analyzing proprietary binary files
• Identifying relationships between different data sources
• Generating interfaces around those data structures
• Building search and filtering functionality
• Organizing creative workflow information
• Iterating on the systems as I discovered new requirements

The important part isn't that AI built the sites for me. I still had to understand the problem, decide what the system needed to do, judge the results, and work out what information was actually useful. AI just made it practical to turn those ideas into working tools.

The Broader Lesson

This project reinforced something I've seen again and again in my professional work: complexity isn't the problem. Unstructured complexity is. The information already existed. It was in the manuals, in the backup files, in the keyboards, in my notes, and some of it was only in my head. The challenge was building a system that connected those pieces in a way that matched the work I was actually trying to do. That's what I mean by Creating Clarity From Complexity. At work the "user" might be a stakeholder, an editor, a developer, a leader, or a whole operating team. Here the user is me, and the domain happens to be keyboards and music instead of enterprise operations, but the approach underneath is the same:

Understand the information. Understand the workflow. Find the friction. Build the system that makes the complexity useful.

What This Project Demonstrates

This personal project combines several capabilities that also inform my professional work:

Information Architecture

Structuring large amounts of information around how people actually need to use it.

Systems Thinking

Understanding relationships between documentation, data, tools, and workflow rather than treating each as an isolated problem.

AI-Assisted Development

Using AI to accelerate exploration, data transformation, development, and iteration.

Workflow Design

Designing tools around the actual sequence of decisions a user needs to make.

Data Transformation

Turning PDFs, proprietary data, and other difficult-to-use sources into structured, accessible information.

Human-Centered Design

Starting with the user's real-world need rather than the structure of the source material.

Creating Clarity From Complexity

I didn't set out to build three information systems for my keyboards as some demonstration of professional method. I built them because I needed them, and that's probably why the project is so satisfying. The same instinct that makes me build a dashboard instead of answering the same status question for the hundredth time, or turn a pile of Word documents into a living knowledge system, is what made me look at thousands of sounds and hundreds of pages of manuals and think there had to be a better way to work with all of this. So I built one.