Ops Safety: Running the Operation for Real

The gap between "works" and "safe to run unattended"

Every lesson in this track up to this point describes a component that works correctly on the happy path: the vault registers an asset, the grader scores a draft, the publisher posts it. None of that is the hard part. The hard part is what happens when a component doesn't fail loudly -- when a call succeeds, an exit code is zero, and the thing that actually mattered quietly didn't happen. An operation that runs unattended for a week has to assume that failure mode is normal, not exceptional, and build detection for it deliberately.

Rate limits and backoff

Every outbound call this operation makes -- publishing, engagement lane sends, comment mining -- shares a platform-imposed budget. A pipeline that sends in a tight burst without watching the remaining-quota signal will eventually blow through that budget all at once, and the failure shows up as a sudden wave of rejected calls across an entire batch rather than a single graceful slowdown. The fix isn't reactive retry logic bolted on after the first failure; it's tracking the quota signal on every call and backing off exponentially before it hits zero, so a temporary limit never escalates into a burst of hard failures or, worse, an account-level penalty for hammering the platform.

Token and permission hygiene

Credentials belong in environment variables, never hardcoded into a repository -- that part is table stakes. The harder discipline is that tokens and scopes drift silently over time: a long-lived token expires on its own schedule, or a human changes an app's permission scopes for an unrelated reason and doesn't realize a content lane depends on that exact scope. Neither shows up as a code change, which is exactly why a lane that worked Monday can 403 by Thursday with nobody having touched anything. The fix is a scheduled token-health probe that runs before any lane executes, catching drift on a schedule instead of discovering it mid-publish, when the failure is already live.

Disclosure compliance is non-negotiable

AI-generated media is always disclosed through the platform's native toggle -- not a caption line, not a bio disclaimer, the actual platform-provided mechanism. This isn't framed as a best practice in this operation; it's a hard precondition on the publish path, exactly like the human GO token. A new engagement or publish lane that gets wired in without that precondition attached is a defect the moment it ships, whether or not anyone notices right away. The correct implementation fails closed: no disclosure flag set, no publish, full stop -- never a warning that logs and lets the post through anyway.

Silent-failure detection

The single hardest category of bug in this whole system is the one where everything reports success and the actual outcome didn't happen. A publish call returning 200 doesn't prove a post is live -- it proves the platform accepted the request. The only reliable way to close that gap is a read-after-write pattern: after every publish, poll the live surface and diff what's actually there against what the vault recorded as published. The same logic applies anywhere a "successful" response is trusted without verification -- trust is earned by checking, not by the absence of a thrown error.

The incident drill

When something goes wrong badly enough that the account itself is at risk -- a leaked token, a disclosure failure that shipped across multiple posts, a strategy mutator that got bypassed and auto-chased an off-axis spike -- the response has to match the actual blast radius, not the first alarming symptom noticed. A single bad grade that slipped through is a one-post fix: pull it, log the miss in the rubric. A compromised token is an entirely different scale, because it grants outbound write access to the whole account regardless of which lane first revealed it: revoke the token at the platform, rotate the secret, halt every lane, not just the one where the symptom showed up first.

When the platform changes the rules

Platforms change their APIs, their rate limits, and their disclosure requirements without asking the pipelines built on top of them. An operation that treats today's contract as permanent will eventually break in exactly the silent way this lesson has been describing -- a call that used to work stops behaving the same way, and nothing throws an obvious error to announce it. The same probes that catch token drift and silent publish failures are what catch a platform-side rule change early: verify actual outcomes against expectations continuously, not just at the moment a pipeline was first built and tested.

That habit of continuous verification is also what keeps a rule change from becoming a full incident. A platform tightening a rate limit shows up first as more 429s than usual on the same probe already watching for the rate-limit cliff; a platform requiring a new disclosure field shows up as the pre-publish check starting to fail closed more often than it used to, not as a wave of live posts violating a rule nobody knew had changed. The probes built for the failure modes above don't just catch bugs in this pipeline's own code -- they're the same instruments that notice the ground shifting underneath it.

None of the components built earlier in this track are less correct for having these failure modes possible around them. They're incomplete without this lesson's discipline wired in, because a component that's correct on the happy path and silent on the failure path is, in an unattended system, indistinguishable from one that's simply broken -- until the week someone finally notices the gap between what the dashboard says and what actually shipped.