Building a mechanism

Creating a mechanism in Mechanic is not a form to fill in — it is a diagnostic exercise. The components you populate tell you what the mechanism actually is; the ones you cannot populate tell you what is missing from your governance.

Creating a mechanism

From the Mechanic home page, select New mechanism. Give it a name that describes the governance function it represents — "Incident Response", "Model Risk Classification", "Data Quality Review". Clear, functional names are more useful than abstract ones.

The mechanism editor opens. Work through the components in whatever order makes sense for your starting point — there is no required sequence.

The components

Objective

The objective is the mechanism's purpose statement: what it achieves, and which governance controls it supports. This is the most important component to get right first, because it anchors everything else. A mechanism without a clear objective tends to drift.

Link the objective to one or more controls from the unified framework. This creates the traceable connection between a regulatory obligation and an operational process — the link that changes a control's coverage state in Nexus from Gap to Covered.

Inputs

Inputs are what triggers or feeds the mechanism: the data, signals, reports, or escalations that start it running or sustain it over time.

For an incident management mechanism, inputs might include automated monitoring alerts, manual incident reports from users, and escalations from other mechanisms. For a data quality review, inputs might include a scheduled data pipeline trigger and a data completeness report.

Inputs come from a shared IO library within your workspace, so the same input can feed multiple mechanisms. This makes dependencies between mechanisms explicit — and makes it obvious when a change to an input source will affect more than one process.

A mechanism should have at least one trigger input — the input that starts the mechanism running. Without a trigger, the mechanism has no defined entry point, which is a structural gap regardless of how well other components are configured.

Outputs

Outputs are what the mechanism produces and who consumes it downstream. Outputs are where chains become visible: one mechanism's output becomes another mechanism's input.

Documenting outputs carefully is important for two reasons. First, it makes dependencies explicit — if this mechanism's output feeds another's input, a weakness here has downstream consequences. Second, outputs are often where compliance evidence is produced: an incident investigation mechanism that produces a documented root cause analysis is generating the kind of evidence that an audit will ask for.

Like inputs, outputs are shared across the workspace via the IO library.

Scope

Scope defines which AI systems this mechanism applies to. A mechanism might cover every system in your portfolio or only a specific subset — the scope is where proportionality becomes explicit.

The same governance control might need a more rigorous mechanism for a high-risk system than for a lower-risk advisory tool. Scope lets you track that calibration: you can see which systems each mechanism covers, and ensure that high-risk systems have adequate coverage across the full set of controls they require.

Tooling

Tooling is the concrete capability that makes the mechanism operational. This covers software platforms, process documents, templates, meeting structures, registries, and playbooks — anything that a person actually uses to execute the mechanism.

The tooling component includes a playbook: an ordered sequence of steps that describes how the mechanism is executed in practice. The playbook is where abstract intent becomes a concrete procedure that someone can follow.

A mechanism with tooling documented is significantly more durable than one that relies on individual practitioners knowing what to do. It is also more auditable.

Metrics

Metrics are quantitative measures that tell you whether the mechanism is working. Two types:

• Leading indicators — measure whether the mechanism is running (coverage). Is it being triggered? Is it completing? Is it reaching all the systems it is scoped to?
• Lagging indicators — measure whether the mechanism is producing results (outcomes). Are the outputs reaching their intended consumers? Are the governance objectives being met?

Metrics that have defined target values are more useful than metrics without them, because they give the mechanism a standard against which to be evaluated rather than just a record that it happened.

Metrics added to a mechanism feed into dashboards and the API ingestion workflow for automated data collection.

Ownership

Ownership is a single named person whose success depends on the mechanism's effectiveness. Not a team, not a committee — one person. If you cannot name one person, that is a governance finding in itself.

A mechanism without a clear owner is likely to degrade over time, because there is no one who feels accountable when it starts to drift. Distributed ownership tends to mean no ownership in practice.

Working with incomplete mechanisms

You do not need to fill in all components to start. In fact, working with a partially documented mechanism is informative: the gaps tell you something real about the current state of your governance.

A useful starting approach is to document what you know exists — the objective and whatever tooling or processes you can describe — and treat the empty components as explicit findings rather than things to be filled in generically.

See Mechanism health to understand how the pattern of component completeness is interpreted.