Write a check

This walks through two checks end to end. The first proves a field is set up the way a work item asked for. The second proves a rule did its job, by reading the records it should have touched. Read Checks first if you want the idea before the steps.

A configuration check

The work item says: “Campaign Code is a single-line text field, and it's on the Vehicle content type.” That's three facts, so it's three conditions.

1. Open Checks. It's in the left-hand menu, under Track.
2. Choose New check. You get a blank check to fill in.
3. Give it a name. Something a colleague would recognise in a list, like “Campaign Code field as specified”. Names are unique within the workspace.
4. Leave What it checks on The configuration. This kind of check reads fields, content types, classifications, rules, settings and the rest as they are in the environment.
5. Add the first condition. Choose Add condition. Each condition is one row: the kind of thing, which one, which attribute, how to compare, and the value. Pick Field, type CampaignCode (the list offers the fields Mochi tracks), leave the attribute as the item itself, and choose is set. That reads as “field CampaignCode exists.”
6. Add the second. Same field, attribute data type, comparison is, value SingleLineText. The attribute list shows what Mochi has seen on tracked fields, so you're choosing from real names rather than guessing.
7. Add the third. Kind Content type, which one Vehicle, attribute registered fields, comparison contains, value CampaignCode. Anything that points at another item reads as that item's name, so you write the field's name here, not an id.
8. Choose Save. If the workspace tracks items of that kind and a condition names an attribute Mochi hasn't seen on them, the save is refused and the attributes that do exist are listed under the conditions. Fix the row and save again.

The check's page opens with nothing under Results yet, then the rule as sentences under What it checks, and the configuration items it names. Time to run it.

Run it

1. Choose Run in… on the check's page. With one environment in the workspace the button names it, like Run in Sandbox, and runs straight away.
2. Pick the environment and choose Run. Any environment in the workspace. Mochi reads it and compares; nothing in it is changed.
3. Read the result. It appears under Results a few seconds later, with the environment it came from and how long ago it ran. The Checks list shows the same next to the check, one line per environment it has run in.

To run every check that's on, or only the ones with a tag, open the environment and choose Run checks, or start one from the Checks page. A checks run is listed under the environment, shows each check's result, and counts against your delivery minutes. A configuration item's own page has Run these in… for the checks that name it.

A record check

A rule sets Asset type to “Press Release” whenever a press release is created. To prove it's working, read the press releases created since it went live and confirm each one carries that value.

1. Choose New check and give it a name, like “Press releases carry an asset type”.
2. Set What it checks to Records found by a search. The form gains a search box and a choice of how many records must pass.
3. Write the search. Under Records matching, type an Aprimo search expression, for example ContentType = 'Press release' AND CreatedOn > 2026-06-01. The newest 500 matching records are read.
4. Choose Test search. With more than one environment, pick which beside the button. Mochi runs the search read-only and tells you how many records match and a few of their titles, so you know the expression means what you meant before you save. If Aprimo turns the expression down, the message says why.
5. Choose when it passes. Every record passes is the usual choice. At least one record passes proves something happened somewhere. No record passes proves something did not happen, which is how you show a rule stayed out of records it shouldn't touch.
6. Add a condition about the record. The first picker is fixed to the record. Choose a field's value, type the field's label or system name, Asset type, then is and Press Release. Option lists compare by option name and classification lists by path, so you write what you'd see on the record.
7. Choose Save, then Run in… and pick the environment, as before.

Reading a failure

A result on the check's page is marked Passed, Failed or Could not run, with when it ran, what started it, and which version of the check it was. Under a failure you'll see:

• For a configuration check, how many conditions failed and each one as a sentence with what Mochi found: “field CampaignCode dataType is SingleLineText (observed: Text).” A missing item reads as “does not exist.”
• For a record check, how many records failed out of how many were read, such as “3 of 500 of 823 records, newest first fail”, then the first twenty of those records by title, each with the condition it missed. If the search matched nothing, a check that needs all or any of them to pass fails with “No records matched the search.”
• Could not run means Mochi couldn't read the environment, or Aprimo refused the search. The message says which. Fix the cause and run again.

Every result is a measurement of that environment at that moment. Fix the configuration, or the check if it was wrong, and run again. Each save of the check is a new version, and the History section on its page keeps every one.

Link it to a work item

A check usually comes from a work item's acceptance criteria, and linking the two keeps them together.

1. Open the work item from the board and choose to edit it.
2. Choose New check for this item in the Checks section. The check's form opens with the work item already chosen. For an existing check, open it, choose Edit, and pick the work item under Work item instead.
3. Save the check. The work item's form now lists it with its newest result, and once it has run, the card on the board reads “Checks 2/3 passing”.

Once a change set linked to that work item becomes part of your configuration, the work item's checks run on their own in the environment the change set was captured from, and the result shows on the change set's page. The same happens for any check that names one of the change set's items.

Run it at a pipeline stage

Checks tied to a stage run when a delivery reaches it, so a bad update is caught where it lands. See Pipelines for how stages work.

1. Open Pipelines, open the pipeline, and choose Edit pipeline.
2. Open the stage's settings and find Checks. New stages start on Run them and record the results.
3. Choose what a failure means. Run them and record the results writes the results on the run and stops nothing. Run them and stop the delivery if any fail tests the configuration checks before the update, against what it would produce, and stops the delivery before anything is written if one fails. After the update lands, every selected check runs against the environment, and a failure marks the run failed so the next stage doesn't start. Don't run them skips checks at this stage.
4. Narrow it with tags if you want. Under Only checks with these tags, type one or more tags, comma-separated. Leave it empty to run every check that's on. A sandbox stage might run just the checks tagged smoke; production the lot.
5. Choose Save pipeline.

On the run's page, Safety checks are Mochi's own gates, and the Checks section under them lists each of yours twice: what it said before the update, against what the update would produce, and what it found afterwards, in the environment. A run stopped by a check says so: “A check failed.”