Organization role compliance status
Purpose
Role compliance describes whether effective representatives satisfy the expectations configured for an organization’s type. Harbor West Chapter may require one billing contact and a bounded number of officers. A stored violation explains the unmet responsibility and count, while an organization with no applicable policy has no such assessment.
Our reading is that explicit assessment states make gaps understandable without implying that compliance is an editable certification. They also determine when a notice may be submitted. An unchanged calculation, continuing noncompliance with different violations, and a new transition into noncompliance are distinct situations for persistence and communication.
Ownership and Authority
The evaluator owns the stored assessment. Contact relationship work, deletion, date settlement and a requested reprocess provide its triggers; staff do not directly select the desired outcome on the organization. Ordinary organization payloads cannot make the assessment authoritative by echoing a preferred status or violation list.
Organization updaters can request reprocessing, and editors change the underlying people and dated responsibilities under their own permissions. The deterministic role-count calculation uses no inference operation. Platform owns notice delivery after submission and does not decide the CRM compliance state from mail success or failure.
The Lifecycle
The diagram distinguishes observed assessment changes from one clearing sequence whose saved-state proof remains unknown. Enabling a policy that already passes can calculate compliance without storing it, so the diagram contains no guaranteed transition from an absent assessment to a saved passing label. The compliance-transition finding records the missing assertions for that boundary and for clearing a previously compliant assessment.
States
ungoverned
No enabled type policy applies, and recalculation leaves compliance fields absent. Entry requires this condition: No enabled type policy applies when recalculation runs. Available behavior is Read the absence of assessment; configure policy and request a later evaluation with the applicable grants.. Status and violations are absent rather than a reassuring compliant label.
in compliance
Every configured bound is met by distinct eligible role holders on effective affiliations. Entry requires this condition: All applicable role-count bounds pass at evaluation. Available behavior is Read the assessment; edit underlying ties; request reprocessing.. Staff see an assessment with no failed bounds.
not in compliance
One or more counts fail their bounds; violations retain the configured rule order. Entry requires this condition: At least one applicable bound fails when evaluated. Available behavior is Read ordered violations; correct underlying coverage; request reprocessing.. The profile explains the missing or excess holder count; notice delivery remains separate.
Transitions Explained
ungoverned → not in compliance
The compliance evaluator starts this change when the following occurs: Create under policy or recalculate after policy becomes applicable. The transition checks this boundary: Enabled type policy has at least one failed rule. The accompanying work is write status and violations in the owning transaction; publish enabled attention; suppress notices on creation; allow notices on subsequent eligible transitions. A changed evaluator result can advance the organization version and capture a revision. The implementation compares violations when deciding to persist; a status-only difference with the same violations does not establish a stored transition. Notice request pointers commit with that assessment; unchanged evaluation produces no new assessment revision.
Passing calculation without a stored transition
A newly applicable policy can pass because the organization already has the required role holders. That computed result and a stored transition are different outcomes. During enabled-policy evaluation, the implementation compares the previous violations with the new ones before reporting a change to persistence. With no previous violations and none now, the calculated compliant status alone does not cause an organization write.
For example, Harbor West Chapter has effective officers before an administrator enables a policy that those officers already satisfy. Reprocessing can calculate a passing result without recording that label or a new organization version. The absence of a guaranteed saved transition follows from this guard; a calculated passing label does not establish stored compliance. Direct before-and-after saved-state and version assertions for this starting condition are missing. The compliance-transition finding records that test gap. The formal inventory excludes the unconditional persistence claim because the implementation contradicts it.
The recalculation result also carries the calculated status when it reports that nothing was written. A caller inspecting only that returned status can therefore mistake the calculation for the stored assessment. In this example, the meaningful verification is a subsequent organization read and comparison with its earlier version, alongside the recalculation outcome. The open finding requires those separate assertions; a returned passing label alone cannot settle the transition.
in compliance → not in compliance
The system under the triggering change context starts this change when the following occurs: Recalculate after relationship work, a date boundary or a reprocess. The transition checks this boundary: Violations differ and at least one rule fails. The accompanying work is persist status and violations; advance owner version; capture revision; submit deduplicated recipient batches when allowed; publish enabled attention. A changed evaluator result can advance the organization version and capture a revision. The implementation compares violations when deciding to persist; a status-only difference with the same violations does not establish a stored transition. Notice request pointers commit with that assessment; unchanged evaluation produces no new assessment revision.
not in compliance → in compliance
The compliance evaluator starts this change when the following occurs: Recalculate and find no remaining violation. The transition checks this boundary: The newly empty violation list differs from stored violations. The accompanying work is set compliant status and clear violations; resolve enabled attention; submit no notice. A changed evaluator result can advance the organization version and capture a revision. The implementation compares violations when deciding to persist; a status-only difference with the same violations does not establish a stored transition. Notice request pointers commit with that assessment; unchanged evaluation produces no new assessment revision.
not in compliance → not in compliance
The compliance evaluator starts this change when the following occurs: Recalculate an already noncompliant organization with changed violations. The transition checks this boundary: The computed violations differ from storage. The accompanying work is replace violations; advance version; omit another transition notice. A changed evaluator result can advance the organization version and capture a revision. The implementation compares violations when deciding to persist; a status-only difference with the same violations does not establish a stored transition. Notice request pointers commit with that assessment; unchanged evaluation produces no new assessment revision.
in compliance → ungoverned
After the policy is removed or disabled, the next recalculation takes the evaluator's separate clearing branch. An existing status or violations makes that branch report a change, allowing persistence to clear the assessment and advance the organization version. The enabled-policy comparison that can suppress a new passing label does not suppress clearing an existing compliant label.
This distinction matters when an administrator retires Harbor West Chapter's role policy. A policy edit alone does not immediately refresh all organizations, but a later valid evaluation can remove the saved assessment. It is not established by direct saved-state and version assertions that this previously compliant starting state completes the clearing sequence. The formal transition is therefore labeled unknown and cites the compliance-transition finding. The evaluator and persistence code support the described mechanism, but the no-policy creation test does not demonstrate this existing-record sequence.
A separate change-event test seeds an organization with a compliant label and no governing policy. It checks that a contact change selects that organization for recalculation. This is useful evidence that the reaction reaches the clearing path, but its assertion stops at selection: it does not read the resulting stored status, violations or version. That narrower test does not close the persistence gap.
not in compliance → ungoverned
When a previously noncompliant organization loses its policy, recalculation clears the existing status and violations through the same clearing branch. Enabled attention is resolved with the assessment write. No transition into noncompliance occurs, so removing the policy does not itself require another violation notice.
The integration suite includes an existing organization whose type is changed to one without rules, followed by a contact reaction; it checks absent status and violations afterwards. That case supports clearing a prior failing assessment. It does not settle the separately missing passing-policy case or prove every starting state's version effects. The formal trigger names the prior failing assessment, and its source is the existing-record clearing case. The missing version assertion remains a coverage limitation rather than a claim that clearing failed.
What Cannot Happen
Ordinary organization writes cannot assign the computed assessment. Echoed read-only compliance values are ignored; they do not change the evaluator’s result.
Changing a type or policy is not an immediate evaluation of every existing organization. Existing saved status can remain until another valid trigger or reprocess reaches it.
Permissions by State
The state rows reference grants from the CRM authorization model. Read access is distinct from mutation, and history requires the corresponding history and read checks. Administrator and Power User hold administrative record actions; ordinary Standard User grants include applicable read and update operations, while Read Only grants do not authorize edits.
Assessment itself is evaluator-owned. Organization update allows requesting reevaluation, while contact authority controls the underlying responsibility corrections; it does not make the computed status writable.
Concurrency and Timing
The evaluator serializes on a transaction advisory lock and the organization row. It counts distinct effective people from committed relationship data. Under an enabled policy, a changed violation result allows an assessment write; without an applicable policy, clearing existing assessment fields also reports a change. Later contact commits provide later reactions; this is not a single snapshot of all policy and people changes across the workspace.
A transition notice can have multiple recipient batches, each with a deduplication key based on organization, resulting version and batch position. Accepted submission is not guaranteed delivery. Initial creation suppresses its notice, and continuing noncompliance does not by itself imply another transition notice.
Invariants
Our reading is that separating ungoverned from compliant prevents staff from interpreting absence of a policy as a completed policy check. Violations reflect the most recent evaluation of eligible role holders and periods; a later date boundary or policy edit can require another evaluation. Notice submission follows a relevant changed assessment and keeps its own retry identity. Neither a compliant label nor the end of a reprocess scan demonstrates that a communication reached its recipients.