Per-AC Translation Diffs: The Audit Trail Every ServiceNow Deploy Needs

The Missing Link Between AC and Artifact

For most of ServiceNow's history, the chain of custody from a user story to a deployed artifact has been informal at best. An analyst writes an acceptance criterion in a Jira ticket. A developer reads it, writes a Business Rule or a Flow, hopes the intent is preserved, and pushes an update set. By the time a CAB asks "why does this script set priority that way?", the AC and the code are two unconnected documents.

Per-AC translation diffs close that gap. Every acceptance criterion produced by SnowCoder's Yeti Build Agent is recorded alongside the exact Fluent SDK statements it generated, removed, or modified during translation. The result is a deploy artifact that any auditor, architect, or QA engineer can read backwards from code to intent.

That sounds modest until you sit through a change advisory meeting that hinges on a single line in a Script Include. Then it sounds essential.

What a Per-AC Diff Actually Contains

A per-AC diff is a structured record, not a free-text comment. The Yeti Build Agent emits one per acceptance criterion, attaches it to the build run, and persists it next to the generated Fluent SDK code. Every entry contains:

• The full text of the acceptance criterion as it was input.
• The artifact class (one of the 42 supported by the Fluent SDK).
• The exact Fluent SDK statements that were added, removed, or modified for this AC.
• The validation outcome on the target instance, with timing data.
• The heal cycle attempt count if the AC required healing to pass.

The structured form means you can query it. Per-AC diffs are stored as records, not log lines, so a QA team can pull a CSV of every AC across 50 stories, or a compliance reviewer can ask "show me every translation that touched the sys_user table this quarter."

A Real Example

Suppose a story carries this acceptance criterion:

The Yeti Build Agent translates that into Fluent SDK statements and records the diff:

// per-ac diff record (abbreviated)
{
  "acId": "STORY-2418-AC03",
  "acText": "When an Incident with category 'Network' is created by a VIP caller...",
  "artifactClass": "BusinessRule",
  "translation": {
    "added": [
      "br.when('before').on('insert')",
      "  .where(current.category.is('Network'))",
      "  .where(current.caller_id.vip.is(true))",
      "  .set(current.assignment_group, 'Network Operations')",
      "  .set(current.priority, 1)"
    ],
    "removed": [],
    "modified": []
  },
  "validation": {
    "instance": "dev92841",
    "result": "PASS",
    "elapsedMs": 412
  },
  "healAttempts": 0
}

Six months later when a developer asks "why does this Business Rule check VIP status?", the answer is a single record lookup, not a guess. The AC is right there, the validation result is right there, the timing is right there.

Why This Matters for CAB and Compliance

ServiceNow is the system of record for ITIL operations at most organizations that use it. That places the platform inside SOX, HIPAA, PCI, and GDPR audit boundaries depending on the workloads it touches. Auditors do not ask "does the script work". They ask "can you show me why the script does what it does, who authorized it, and how you verified it".

Per-AC diffs answer all three questions with one record set:

• Why: the AC text itself.
• Who: the story owner and approver as captured in the project metadata.
• How verified: the validation result against the target instance, with the heal cycle history.

Compare that to the typical alternative, which is a developer pasting screenshots into a ticket comment. The audit cost difference is not subtle.

How Per-AC Diffs Power the Heal Loop

Per-AC diffs are not only an audit artifact. They are the input that the auto-heal loop uses to decide what to retry. When the Yeti Build Agent runs validation and an AC fails, the diff entry for that AC captures the failure trace and the validator's expected vs actual result. The heal step is then constrained to that AC.

This is what makes auto-heal cheap enough to run inside the HealBudget cap. The model is not asked to regenerate the entire artifact. It is asked to amend the specific Fluent SDK statements that this AC owns, given the failure trace and the original AC text.

// heal step input, derived directly from per-ac diff
{
  "acId": "STORY-2418-AC03",
  "acText": "When an Incident with category 'Network'...",
  "previousTranslation": [
    "br.when('before').on('insert')",
    "  .where(current.category.is('Network'))",
    "  ..."
  ],
  "failureTrace": {
    "validator": "atf_runner",
    "expected": "priority == 1",
    "actual": "priority == 3",
    "rootCauseHint": "missing where clause on caller_id.vip"
  }
}

The Cross-Story View

Single-story diffs are useful. Cross-story diffs are where teams start to find structural problems. Because per-AC records are queryable, the Yeti Build Agent run summary can surface aggregate signals that no individual story would reveal:

• Which artifact classes from the Fluent SDK's 42 supported types are generating the most heal attempts.
• Which tables are touched most often, and by how many distinct ACs.
• Which ACs took more than one heal attempt, suggesting ambiguous requirements.
• Which validation gates from the 500+ checkpoints used by Instance Audit are firing most.

That last one matters because it lets a platform team feed insights from per-AC diffs back into Instance Audit thresholds without leaving the SnowCoder console.

Working with Per-AC Diffs Day to Day

The Yeti Build Agent surfaces per-AC diffs in three places. Each one is sized for a different consumer:

• Story view. The narrative form. Developers reviewing a single story see the AC, the Fluent SDK, and the validation outcome inline.
• Run summary. The roll-up form. Project managers see pass rate, heal counts, and budget consumption per AC class.
• Export. The audit form. JSON or CSV, queryable by AC ID, artifact class, table, or validation result.

The export is the one that matters at audit time. Hand the JSON to a reviewer and they have everything they need to trace any line of deployed code back to a written acceptance criterion and a passing validation.

Why This Is Hard Without AI

You could build per-AC traceability by hand. Some shops do, with code comments and Jira fields. It does not survive scale. Once a single Business Rule starts servicing five ACs, the manual approach falls apart. Comments drift, ACs are split or merged, refactors happen, and the link between intent and code rots silently.

The Yeti Build Agent treats the AC as the unit of work and the Fluent SDK as the output. Per-AC diffs fall out of that architecture for free. The translation is not a side effect of the build. The translation is the build.

Related reading

• Yeti Build Agent overview explains the Fluent SDK generation pipeline end to end.
• HealBudget shows how diff-driven heal cycles stay inside a cost ceiling.
• Instance Auditing covers the 500+ checkpoints that validation hooks into.