I Turned a Meeting Summary into a Verifiable Delivery Loop

I'm myself organizing our team's meeting notes. The process is very fixed, but every time I have to manually give step-by-step instructions and confirm each step, which is tiring. In fact, how to do each step and to what standard I already wrote into skill packages, but they are scattered in different places. This article explains how I turned these existing rule modules into a loop that can be triggered with a single command and will also leave verification evidence.

Real-time

I'm myself organizing our team's meeting notes. Every time, it's the same fixed sequence of actions.

Store the original verbatim draft. Store a cleaned version separately. Then organize and analyze it, turn it into a readable webpage layout, deploy it to our team's internal website, so everyone can see it by opening it. Finally, update the to-do items generated from this meeting to the tracking list.

The process is fixed to the point that I know the next step even with my eyes closed. However, every time, I still have to manually give step-by-step instructions and confirm each step. After organizing, I remember to store the cleaned version, after storing, I remember to do the webpage, after doing the webpage, I remember to deploy it, after deploying, I remember to update the to-do items. Missing one step, that step will be left blank.

The same thing, I have to manually re-run it every week. This is the problem I want to solve.

I don't lack methods, what I lack is connecting the methods together

Here I need to mention something first, so you can understand what the loop is saving.

Every step in this process is not ad-hoc. Over this period of time, I have written each step into a skill package, which contains very detailed rules, standards, and judgments.

For cleaning the verbatim transcript, I have rules for different levels: which level to clean to, whether to split by speaker, and how much original text to retain. For meeting analysis, I have a fixed method: first capture resolutions and pending tasks, then look at the discussion context and positions, and finally make a strategic judgment. For webpage layout, I have my own layout rules, which segment to place first and which to fold, are all set. Deployment and updating pending tasks also have their own SOPs.

What I have never lacked is a method. Every step of how to do it, what standard to reach, and how to judge when encountering issues, the answers are all written down and stored in the respective skill packages.

What I lack is connecting them. Previously, these skill packages were separate, and each time I had to call them one by one, step by step push and step by step confirm. The methods are already in place, but the effort is repeated every time.

Mechanism solution: connect the existing rules into a chain that can run automatically.

What the loop does is simple: it connects these already existing, complete rule modules into a chain. Call a trigger word, add the verbatim transcript, and six steps run automatically.

The judgment used in every step is still the same as the original skill package. The loop does not replace them, it only transforms 'I have to manually push one by one' into 'call out a sound, and it runs automatically according to the rules.'

It guarantees what, and does not guarantee what

How to start

You don't need to think about building an entire system from the start. The loop grows, it is not designed.

The first minimal step is like this: pick a knowledge task you need to redo every week, and do it honestly once. During the process, note down every instance where you almost made a mistake. After finishing, turn each of these notes into a sentence like 'Next time, definitely do this first' or 'Next time, definitely do not do this.'

These sentences accumulate over time and become the rules for each step. When you find the same sequence of steps repeating and each step's rule is fixed, you can bundle them into a loop: give it a trigger word, so that yourself or AI can call it and run through it automatically, leaving verifiable evidence at the end.

By this point, the separate approaches you have in your hand are connected into a loop that can run automatically and gets more stable as it runs.

Moving toward safe automation

With this loop, I finally started moving toward automation. Previously, I was not confident in letting the process run automatically because I was afraid it would go off track and I wouldn't know. Now I am confident because the loop has a layer of protection: important judgments are marked as not yet reviewed by a second person, and the end must have verifiable evidence that the machine can detect, which can catch errors.

I call this layer of protection 'Driving Engineering.' Loop Engineering is responsible for letting the process run automatically, while Driving Engineering is responsible for making it run safely. Together, they form the automation I want: safe, with protective mechanisms.

In the early stage, building rules one by one is indeed more troublesome. However, once they are built, safety is greatly improved. Moreover, these rules can be reused: the level rules for cleaning verbatim transcripts, the three-layer sorting method, and the format rules are not only used in the meeting sorting loop. They can be applied to another process as well.

Reminders for your own positioning

What truly accumulates is the rules, standards, and judgments. They are the assets. The loop is just a way to let these assets run automatically without me manually moving them each time.

Tools will keep changing. However, a set of rules you personally accumulate and can reuse, along with a loop that connects them, can be carried over even when you change tools.