Last updated Jun 14, 2026

No-op confirmation

A surprising amount of compliance work is a no-op. A SAFE issued to a $50K angel does not change BOI beneficial owners. An officer change replaces a non-control-person VP. An entity's headcount stays under 50 FTE so it remains a non-ALE for the year. A jurisdictional address change moves the office down the street, still in the same state. In each case the right answer is "nothing to do" — but the agent driving the decision needs proof of the no-op, not silence.

A platform that returns nothing when nothing is owed is indistinguishable from a platform that forgot to check. Matter solves this with a uniform pattern: every compliance surface that might require an action returns a structured answer that includes the no-op case as a first-class outcome with its own evidence shape.

The pattern

GET /entities/{id}/<surface>           ← read state
POST /entities/{id}/<surface>/check    ← evaluate the change against state

The check endpoint returns one of three outcomes:

• action_required — a Filing or Document or Resolution is needed. Returns the obligation + the deadline + the cause.
• no_action_required — the proposed change does not trip any threshold. Returns an evidence{} block citing the specific test that was evaluated and the value that satisfied it.
• indeterminate — the platform cannot reach a verdict from the data on hand (e.g., third-party data has not yet been ingested). Returns the missing inputs.

The no_action_required outcome is the load-bearing one. It is the no-op-confirmation, queryable, evidence-bearing, attributable to a specific test result.

Why this matters

Without the pattern, every "did I forget something?" check requires the caller to reproduce Matter's own logic. With the pattern, the caller posts the proposed change, reads back a structured verdict, and stores the verdict as an audit-trail Document. The verdict is its own line in the compliance log — not a silent absence.

The pattern also makes the agent-native UX clean. An agent can ask "do I need to update BOI after issuing this SAFE?" and get a verdict in one call — no_action_required: investor_below_25_pct_threshold, with the structured evidence inline — rather than re-implementing FinCEN's beneficial-owner test.

Where it shows up

The following surfaces follow the pattern:

Compliance.boi_roster_delta_since_last_filing

After every event that might change the BOI roster (SAFE issuance, officer change, address change, share-class amendment), Compliance exposes a boi_roster_delta_since_last_filing block. When the delta is empty, the block returns no_action_required with evidence: { last_filing_id, roster_unchanged_since, considered_events } — proof that the relevant events were considered and none crossed the threshold.

Compliance.ale_status_evidence

Whether the entity is an Applicable Large Employer (50+ FTE) for ACA purposes is computed from headcount and hours data the payroll provider holds. Matter does not expose /v1/entities/{id}/ale_status (that would cross the payroll-and-benefits handoff boundary). What Matter does expose is Compliance.ale_status_evidence{} — the latest provider-attested ALE status + the assertion date + the confidence (provider-confirmed vs. estimated). When ALE status hasn't changed across an event that could conceivably move it, the agent reads the evidence block as a no-op confirmation.

Compliance.governance_invariants

Some governance facts are statutorily required to hold continuously — every director seat must be filled, the corporation must have a registered agent in the state of incorporation, the BOI roster must reflect every 25%+ beneficial owner. After every governance mutation, Compliance re-evaluates each invariant and returns either held (with the test result) or violated (with the action required). The held outcome is the no-op confirmation.

Entity.jurisdictional_addresses

Every Entity carries a jurisdictional_addresses sub-resource keyed by (state, role) (e.g., principal-office NY, registered-agent DE). After an address change, comparing the before and after snapshots produces either a "same jurisdiction, no Filing" verdict (no-op confirmation) or a "jurisdiction changed, BOI/SoS update required" verdict.

Format of the evidence{} block

{
  "outcome": "no_action_required",
  "evidence": {
    "test": "investor_below_25_pct_threshold",
    "value_observed": "0.04",
    "threshold": "0.25",
    "evaluation_date": "2026-04-27",
    "considered_events": ["evt_n7K3...", "evt_p2M9..."]
  },
  "as_of": 1769529600
}

Every no-op evidence block carries:

• test — a stable identifier for the rule that was evaluated.
• value_observed — the value that came out of evaluating the test.
• threshold (when applicable) — the cutoff the value did not cross.
• evaluation_date — when the check ran.
• considered_events[] — the platform Events the check folded in. Lets the caller verify nothing was missed.
• as_of — Unix timestamp of the snapshot.

What this is NOT

• Not a way to suppress real obligations. A no-op confirmation is a positive verdict that the test was evaluated and did not trip; it is not silence. If the test cannot be evaluated, the outcome is indeterminate, not no_action_required.
• Not a substitute for a Filing. When action_required returns, the caller must still create the Filing. The pattern surfaces decisions; it does not file them.
• Not a substitute for the Compliance calendar. Recurring obligations (annual report, franchise tax) live on Compliance regardless of whether any event-driven re-evaluation has fired.

Related

• Payroll and benefits handoff — explains why ALE status and many other employment-side facts live with the provider, with the no-op-confirmation pattern bridging the boundary.
• Lifecycle — the broader Create / Manage / Exit framing this pattern fits inside.