Harness-Based Operation Routine v0.1
This document is a draft for moving June operations from conversation-centered AI work into a repeatable operating system. It does not expose internal prompts or detailed automation settings. It only defines the public-safe purpose, flow, and validation criteria.
Recover whispering into an operating system
Until May, I used conversations with Meta Chulbuji to clarify thoughts and decide execution direction. Starting in June, I will recover those conversations into a repeatable operating structure through harnesses, skills, workflows, and evals.
The goal is not to build a perfect system. The goal is to start with small tasks, define purpose and validation criteria, and record the results as Log, Insight, SOP, or Board entries.
Validation targets for the June operating system
| Project | Operating View |
|---|---|
| AI Content Assistant | Validate market response and delivery flow for a small-business promotional content generation service |
| AI Blog / AdSense | Record publishing routines, SEO checks, and ad-review preparation against clear criteria |
| chulbuji.com Home Base | Assetize operating experience through Log, Insight, SOP, and Board |
| Marketing Experiments | Validate Kmong, blog, search traffic, and product-description improvements in small units |
| Auto-Trading Record Assetization | Accumulate operating experiments and validation records, not investment decision suggestions |
From thought to operating asset
- Clarify the current position Use Meta Chulbuji to organize the owner's thoughts or execution experience. Identify the problem and the judgment needed now.
- Write the harness Write the purpose, roles, scope, validation criteria, and record location first. If the criteria are unclear, reduce the execution scope and strengthen the harness.
- Assign the execution AI GPT and Meta Chulbuji handle judgment and structure. Claude and Codex handle development and edits. Gemini supports Google ecosystem and marketing checks. NotebookLM supports source organization and SOP work.
- Execute Work inside the defined scope. If the scope grows, split it into a new harness or defer it.
- Eval Judge the result against predefined criteria instead of only relying on feeling.
- Reflect the record Leave meaningful process records in Log, Insight, SOP, or Board depending on the type of result.
Questions to ask before starting work
| Item | Question |
|---|---|
| Purpose | Why am I doing this? |
| Roles | What does the owner, Meta Chulbuji, Claude, Codex, and Gemini each handle? |
| Scope | How far does this work go, and where does it stop? |
| Validation | What determines success, failure, or pending status? |
| Record | Where will the result be recorded: Log, Insight, SOP, or Board? |
Minimum criteria to check this month
| Item | Standard |
|---|---|
| Harness cards | Write at least 5 |
| Skill candidates | Identify at least 3 |
| Workflows | Run at least 2 in practice |
| Eval criteria | Write at least 2 |
| Log / Insight | Publish at least 2 operating-system records |
| SOP | Publish Harness-Based Operation Routine v0.1 |
Build small and use it in real work
- Write the five harness questions before starting new work
Work that starts without criteria is hard to turn into a repeatable operating asset.
- Mark repeated work as a skill candidate
If a task is likely to happen again, leave it in a form that reduces the next execution.
- One-off work ends as a Log
Do not over-document everything. Leave the necessary judgment and result.
- Work repeated more than once becomes an SOP
Start with a v0.1 standard that helps the next repetition instead of waiting for a perfect manual.
- Judge results by eval criteria, not only by feel
If no criteria existed beforehand, record the result as pending instead of forcing success or failure.
- Reflect progress on the Board once a week
Recover project execution into the monthly operating direction instead of leaving it scattered.