MixShift · operations layer
The scheduled automation running under my lane at MixShift, as filed in the company's automation registry. I wrote the schema for registering an automation, then filed the first one against it, risk notes included.
What is shown here is the shape of it: how much ran, when, and the rules every job was written under. The contents stay where they belong.
Pick a day. Green marks a job that only runs on that one.
Two more run monthly: one extends a scheduling calendar, one rolls up the month's analytics.
Rules that recur across the job specs. Nobody handed these down. They accumulated, mostly after something went wrong once.
Agents write files. A human owns every commit and every push. The boundary is in almost every spec, in the same words.
A house style rule is checked by codepoint before a write counts. A violation skips the file and logs it, so the source gets fixed instead of the symptom.
Re-running produces no second write. The guard is named per job: a content hash, an upstream id, a file that already exists, a modification time.
No candidates is a valid outcome with its own exit path. No job pads its output to look productive.
Stamped before any work begins, so a stale timestamp is an unambiguous "did not run" rather than an ambiguous "ran and found nothing".
A failed step ends that unit of work. Partial success is reported as partial, never rounded up.
Named destinations that no job may write, declared per job rather than assumed.
Where a figure was not stated in the source, the report says so and names the last known value with its date.
Drawn from the registry as filed, July 2026. Job names, destinations, credentials, contents and the incidents behind individual rules are not shown. Counts are out of the 25 specs the registry mirrors.