Checks

A work item's acceptance criteria are sentences a person ticks. A check is the same idea in a form Mochi can test. “The Campaign Code field exists, is single-line text, and is registered on Vehicle” becomes a handful of conditions, and running the check reads the environment and says whether each one passes, with the value it found.

Checks are for configuration, and for what that configuration does to records. Mochi manages your configuration, not your content, assets or workflows. A check can read records to prove a rule or a default value behaves, but it doesn't change them.

Two kinds of check

• Configuration checks read the environment's fields, content types, classifications, rules, settings, file types, user groups and languages. “VIN is required.” “The Region list has EMEA.” “The Set release date rule is on.”
• Record checks find records with an Aprimo search and test each one. “Every press release created since June has an asset type.” “No released record under Public is missing a rights expiry.” This is how you prove a rule or a reference works: by looking at what it did to real records, rather than by creating a test one. The newest 500 matching records are read, and the result says so when a larger set was sampled.

What a check names

A condition names a configuration item by its name and one of its attributes, using the same names you see under Configuration. Leave the attribute as “the item itself” and the condition is about whether the item exists. The builder offers the items Mochi tracks and the attributes it has seen on them. Once the workspace tracks items of a kind, a condition naming an attribute Mochi hasn't seen on that kind is refused at save and the attributes that do exist are listed. Before then there is nothing to compare against, so the name is taken as written and the run says what it finds.

A check can name an item Mochi doesn't track yet. That's allowed. The check runs and reports what it finds in the environment either way.

The items a check names are how it shows up elsewhere. A configuration item's page lists the checks that name it, with their newest result in each environment. Deleting, renaming or untracking an item doesn't change a check. The check keeps running and fails with “does not exist,” which is what you'd want to know.

See what a check can read for the full list, including what a record check can look at on each record.

Where a check runs

A check doesn't belong to an environment. It runs in whichever one you point it at, in three ways.

1. When you choose. Open an environment and choose Run checks to run every check that's on there, or only the ones with a tag; the Checks page can start one too. Open a check and run it on its own, or open a configuration item's page to run the checks that name it. You pick the environment each time. A checks run is listed under the environment, not among deliveries, and counts against the same delivery minutes.
2. After a change set becomes part of your configuration. The checks that name any of its items, or that belong to a work item it's linked to, run in the environment the change set was captured from. The result shows on the change set's page. A change set that stops tracking an item, or undoes an earlier one, wasn't captured from an environment, so it gets no run of this kind.
3. During a delivery. Each stage of a pipeline chooses what to do with checks: run them and record the results, run them and stop the run if any fail, or skip them. A stage can run only the checks with a particular tag, so a sandbox might run a quick set and production the whole set.

Around a delivery, configuration checks run twice. Before anything is written, Mochi works out what the environment would look like afterwards and tests those checks against that. If the stage is set to stop on a failure, the run stops there, before it changes anything. After the update lands, every selected check runs against the environment as it now is. If one fails at that point on a stage set to stop, the run is marked failed and the next stage doesn't start. The update itself stays in place; putting the environment back is a person's decision.

A check that's switched off is skipped by all three.

Reading a result

A result is a measurement. It says which conditions held and which didn't, and for each one that didn't, what Mochi found:

field "_AltText" label is "Alt text (for accessibility)" (observed: "Alt text (accessibility)")

A record check names the first twenty records that failed, with the condition each one missed. A check that says none of the records may pass names the first twenty that did. Mochi doesn't suggest a fix; it tells you what it saw.

A record check with nothing to read doesn't pass quietly. If the search matches no records, a check that says “all of them must pass” or “at least one must pass” fails with “No records matched the search.” Only a check that says “none of them may pass” passes on an empty search.

A third outcome is could not run. Mochi couldn't read the environment, or Aprimo turned the search expression down. The message says which. It isn't a pass and it isn't a fail; the check simply has no answer yet.

The Checks page shows every check with its newest result in each environment. The Failing tab collects the ones whose newest result somewhere isn't a pass, and Off the ones that are switched off.

Checks have a history

Every save is a new version, with who saved it and when. The check's page shows them all, and every result records which version ran. Switching a check off is a save like any other, so it's in the history too. A check that no longer applies is switched off or deleted from its own page, by a person. Deleting a check removes its versions and every result it recorded; switch it off instead if the results should stay readable on the change sets and runs they were part of.

Checks aren't part of a change set and don't move with a delivery. If an environment is put back to an earlier version, a check written for a newer one simply fails there until the newer version arrives again. That's the point: it's telling you the environment is behind.

Tags and work items

A check can carry a few tags, like smoke or slow. Tags are how a pipeline stage picks which checks to run, and how an AI agent runs a set at once. A check can also be linked to one work item, and a work item can have many checks. Its card on the board shows how many are passing, and its edit form lists them, with a link to start a new one already attached to it.

Writing one as text

The builder is the usual way. For the curious, and for an AI agent, a check is also plain text in a structured form: a name, optional tags, an optional record search, and conditions. A condition's field is the kind of thing, the item's name, and the attribute, separated by a bar. An empty attribute means the item itself, so “is set” on it means “exists.” Values are written as text and compared as whatever the attribute is: true or false, a number, or words.

{
  "name": "Campaign Code field as specified",
  "tags": [
    "smoke"
  ],
  "conditions": {
    "combinator": "and",
    "rules": [
      {
        "field": "fieldDefinition|CampaignCode|",
        "operator": "notNull"
      },
      {
        "field": "fieldDefinition|CampaignCode|dataType",
        "operator": "=",
        "value": "SingleLineText"
      },
      {
        "field": "fieldDefinition|CampaignCode|label",
        "operator": "=",
        "value": "Campaign Code"
      },
      {
        "field": "contentType|Vehicle|registeredFields.fieldId",
        "operator": "contains",
        "value": "CampaignCode"
      }
    ]
  }
}

A record check adds the search and says which of the matching records must pass. A field is named by its label or its system name. When two fields share a label, use the system name; a check that names a shared label stops with the fields it could have meant, rather than reading a different one on each record.

{
  "name": "Press releases carry an asset type",
  "records": {
    "search": "ContentType = 'Press release' AND CreatedOn > 2026-06-01",
    "quantifier": "all"
  },
  "conditions": {
    "combinator": "and",
    "rules": [
      {
        "field": "record|field|Asset type",
        "operator": "=",
        "value": "Press Release"
      },
      {
        "field": "record|classifications|",
        "operator": "contains",
        "value": "/Public/Web"
      }
    ]
  }
}