Key Result Sync
Some key results are opinions that need a weekly human check-in. Some are just counts the company already produces. This job takes the second kind off the calendar: every night it computes the number from the system that owns it, writes it onto the KR, and leaves a log row signed by the agent. Humans keep the target and the status; the machine keeps the number honest.
Count in, KR out
The goals model runs strategy, then company objectives, then key results, then each person’s FAST goals laddered back to a KR. This job sits at the KR layer only. Four steps: a human names the KR, the machine counts, writes and logs, and the goals page reads the result.
How each step works
A key result joins this job by being added to a short list in the cron’s code: the row it keeps, a label, and a function that returns the value and a one-line note. Today the list has one entry, the objective to build 88 workflows into the 8 Edges Open Source System, whose number is the count of managed routines. Adding a second computed KR is a code change, deliberately: the list is the statement of which numbers the company trusts a system to read off.
The job loads the same catalogue Settings → Agents renders: every scheduled path in the deploy config, the on-demand routines the app calls itself, and the jobs on the office Mac mini. The value is the length of that list, and the note breaks it down by host. Nothing is estimated; if a routine is on the page, it counts, and if it is not, it does not.
For each computed KR the job reads the row first, so a deleted KR fails loudly instead of being skipped forever. It then writes the current value and the updated-at stamp, and appends one log row keyed to the Monday of the current week, with the value, the note, and the author recorded as the devops agent. Status is never touched. The response lists every KR with its new and previous value, and any failure turns the whole run red on Settings → Agents.
KRs without a computed source are checked in by hand on the goals page: the owner enters the current value and picks a status, and the audit log records who did it. A computed KR arrives at that same check-in with its value already current, so the only human decision left is the status. The log trail shows agent rows for computed KRs; that is how a reader tells a number the machine read off from one a person typed in.
Every exception has an owner
The job is small enough that every failure has one home: the run row on Settings → Agents. The two rows at the bottom are not failures; they are the boundary between what the agent does and what a human does.
| Condition | What happens | Where you hear about it |
|---|---|---|
| KR row deleted or replaced | “key result not found”; the run fails rather than silently doing nothing forever | Settings → Agents, as an error run |
| KR read fails | That KR is recorded as failed; the loop continues to the next computed KR | Settings → Agents, as an error run |
| Value write fails | No log row is appended; the KR keeps its previous value | Settings → Agents, as an error run |
| Log insert fails after the value was written | Value stands, log missing; error prefixed “log:” so the two cases read differently | Settings → Agents, as an error run |
| Run triggered twice in a day | Same value written again and a second log row for the same week; there is no per-run key | The KR’s log |
| A cron is added to the deploy config without metadata | Still counted; the catalogue lists every scheduled path, named or not | Settings → Agents shows the unnamed entry |
| Target reached or passed | Nothing special; the agent only reports the number | The goals page, when a human reads it |
| Status needs changing | Never touched by the agent; only a human check-in sets status | The goals page |
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
Time. 03:45 (+07) every day. The KR is refreshed before anyone opens the goals page.
The list of computed KRs in code (one today), the KR row itself, and the routine catalogue: every cron in the deploy config, the on-demand routines, and the Mac mini jobs.
The machine decides the number. A human decides the target, the status (on track, at risk, off track, done) and which KRs are worth computing at all.
One KR, one row, one write. There is no notification: the value shows up where the KR is read.
The KR’s current value, its updated-at stamp, and one log row with the value, the week, and a note that breaks the count down by host.
The goals page and the 8 Edges views read the KR row; the log trail sits beside it, attributed to the devops agent rather than a person.
The run row on Settings → Agents carries updated and failed counts. Any failed run is the alarm; the routine catalogue is the source, so the number can only be wrong if the catalogue is.
Reads and writes
- Reads: the computed-KR list in code, the KR row (id and current value), the routine catalogue
- Writes: the KR’s current value and updated-at; one KR log row per KR per run, author kind agent, author the devops agent; one routine run row
- Never writes: status, target, or any KR not on the list
- Week key: the Monday (UTC) of the run’s week; nightly runs in the same week append, they do not replace
The standing rules
- The number comes from the system that owns it, never from a spreadsheet
- A KR is computed only when someone adds it to the list in code
- Status stays human: the agent reports, it does not judge
- A missing KR row fails the run; silence is never the outcome
This is the quiet cousin of the Daily Check-in Agent: the same refusal to guess, applied to a single number. The check-in agent reads the cards so nobody writes a stand-up; this job reads the catalogue so nobody counts routines by hand.