---
id: t7-compliance-workflow
title: Compliance Workflow
module: GROW-S6
module_slug: grow-s6-govtech-compliance
cluster: Trust
type: spec
version: v0.1.0
status: Gate-reviewed
tier: membership
contract_role: Produces C9 → Provenance
canonical_url: "https://grow.goodcombinator.ai/library/registry/t7-compliance-workflow"
download_url: "https://grow.goodcombinator.ai/library/registry/t7-compliance-workflow.md"
license: CC-BY-4.0 (proposed — owner confirmation required)
source: GROW by Good Combinator
retrieved_at: 2026-05-29
---

# Compliance Workflow Spec (C9 Producer)

This spec translates jurisdiction rules cataloged in `t7-jurisdiction-rule-map` into a deterministic process model: the ordered steps, required documents, review and approval gates, and exception paths that a compliance agent must execute for a given permit or regulatory determination. It is built on the process-modeling patterns of `e4-workflow-artifacts` and serves as the C9 producer: for every compliance determination the agent makes, it emits a structured provenance record to `s3-provenance-metadata-schema`. When a determination crosses the `expert-review boundary`, the workflow blocks applicant-final output and raises a mandatory S1 HITL event — this is how the "not legal advice" boundary is enforced by mechanism, not by prose disclaimer alone.

## 1. Workflow Architecture

The compliance workflow has five ordered phases. Every phase produces one or more step-level outputs; phases 3 and 4 contain the HITL gates that enforce the `expert-review boundary`.

```
Phase 1: Intake & Completeness Check
Phase 2: Rule Identification
Phase 3: Per-Rule Determination  ← C9 emission point; HITL gate if expert_review_required
Phase 4: Aggregated Disposition  ← HITL gate if any determination is needs-review
Phase 5: Record & Notify         ← Applicant-facing output released here ONLY after phase 4 clears
```

### Phase 1 — Intake & Completeness Check

**Inputs:** Application payload (form, attachments, parcel data) from the district portal or intake system.

**Steps:**
1. Validate that all mandatory fields are present per the applicable intake form schema. Any missing field triggers a `return-to-applicant` sub-workflow with a checklist of deficiencies. Missing-field notices are not compliance determinations; they do not emit C9 records.
2. Confirm that the parcel GIS layer resolves the submitted parcel ID to a valid polygon within the agent's operating jurisdiction.
3. Log the accepted application with an intake timestamp. This event is logged to `s2-audit-trail-schema` but does not yet emit a C9 provenance record; no determination has been made.

**Exception:** If the parcel ID does not resolve, classify the application as `incomplete` and halt. Emit a C9 record with `determination: not-applicable` and `evidence_pointer` referencing the GIS lookup failure log.

### Phase 2 — Rule Identification

**Inputs:** Validated application payload + `t7-jurisdiction-rule-map` (current version).

**Steps:**
1. For each row in `t7-jurisdiction-rule-map` with `scope: universal`, evaluate the `agent_trigger` condition against the application fields.
2. For local-scope rows matching the application's `jurisdiction_id`, evaluate triggers.
3. Produce an activated-rules list: an ordered set of `rule_id` values, each with the triggering field and value. This list drives Phase 3.
4. If no rules are activated (e.g., activity is genuinely below all thresholds), emit a single C9 record with `determination: not-applicable` and close. `[ATTORNEY REVIEW]` — confirm no silent exemption is being claimed.

**Rule for ambiguous triggers.** When a trigger condition is ambiguous — the measured value is near a threshold and the uncertainty band spans the threshold — classify the rule as activated and mark the resulting determination `needs-review`. Do not resolve ambiguity autonomously.

### Phase 3 — Per-Rule Determination

This phase is the C9 emission point. One C9 record is emitted per activated rule per application. The determination logic for each rule must be strictly rule-based; the agent must not introduce judgment beyond what is encoded in the rule row.

**Determination enum (C9 `determination` field):**

| Value | Meaning |
|---|---|
| `compliant` | Application meets the rule's requirements on its face |
| `non-compliant` | Application fails one or more explicit requirements of the rule |
| `needs-review` | Rule threshold is ambiguous, rule text is disputed, or the determination requires expert judgment |
| `not-applicable` | The rule's trigger conditions are not met by this application |

**Expert-review boundary rule.** A determination MUST be set to `needs-review` and `expert_review_required: true` whenever any of the following hold:

- The rule requires interpretation of a statute or regulation beyond plain-text reading. `[ATTORNEY REVIEW]`
- The rule involves a threshold that requires an engineering calculation the agent cannot verify from the submitted data alone.
- The `verify_flag` on the rule row is `true` and `last_confirmed` is older than 12 months.
- The rule row carries `attorney_review: true`.
- The application involves a first-of-type fact pattern not covered by prior determinations in the evidence store.

When `expert_review_required: true` is set, the workflow MUST raise an S1 HITL event before proceeding to Phase 4. The HITL event uses the C2 six-field shape (`event_id`, `timestamp`, `agent_id`, `decision_origin: escalation`, `evidence_pointer`, `rationale`). Phase 4 does not execute — and applicant-facing output is blocked — until the HITL event is resolved by a qualified reviewer.

**Decision origin mapping:**

| Determination path | `decision_origin` value |
|---|---|
| Autonomous rules-based evaluation, no expert flag | `compliance-determination` |
| Routed to expert reviewer via HITL gate | `escalation` |
| Reviewer overrides agent determination | `human-override` |

### Phase 4 — Aggregated Disposition

**Inputs:** All per-rule C9 records from Phase 3.

**Aggregation logic:**

```
IF any rule determination == non-compliant → overall disposition = non-compliant
ELSE IF any rule determination == needs-review → overall disposition = needs-review (BLOCKED until expert review clears)
ELSE IF all rule determinations == compliant → overall disposition = compliant
ELSE IF all rule determinations == not-applicable → overall disposition = not-applicable
```

An aggregated `needs-review` disposition blocks Phase 5. The blocking condition lifts only after every `needs-review` record has been resolved by a qualified reviewer and the record's `determination` updated to `compliant`, `non-compliant`, or `not-applicable`.

### Phase 5 — Record & Notify

**Condition to enter Phase 5:** No unresolved `needs-review` records exist for this application. HITL gate signed off.

**Steps:**
1. Produce the applicant-facing determination summary. This document is a draft produced by the agent and reviewed by a clerk before transmission. It must carry the standard disclaimer: **"This summary is prepared by an automated compliance screening tool. It is not legal advice and does not constitute a final agency determination. Please consult with a licensed attorney for legal guidance."** `[ATTORNEY REVIEW]`
2. Log the finalized determination to `s3-provenance-metadata-schema` with `retention_class: civic-7yr` per `s3-governance-retention-policy`.
3. Emit the applicant notification draft to the clerk queue per the `irreversible_impact_boundary` rule from `s1-hitl-review-policy` — the agent does NOT send directly to the applicant.
4. Archive the application, all per-rule records, HITL event records, and evidence pointers in the provenance store.

## 2. Provenance Emission (C9)

This section is the contract C9 implementation. It is normative — a compliance determination that does not emit per this spec fails the integration check.

**Trigger:** One C9 record per activated rule per application, emitted at the close of Phase 3 step for that rule.

**C9 payload schema:**

```json
{
  "rule_id": "string — resolves to t7-jurisdiction-rule-map row",
  "jurisdiction_id": "string — kebab-case, e.g. fl-walton-county",
  "determination": "compliant | non-compliant | needs-review | not-applicable",
  "evidence_pointer": "URI or storage key — points to the rule text cited and the application fields evaluated",
  "decision_origin": "compliance-determination | escalation",
  "expert_review_required": "boolean"
}
```

**Emission rules:**
- Every C9 record is appended to `s3-provenance-metadata-schema` immediately on determination. Records are never held or batched.
- `expert_review_required: true` also raises a C2 S1 HITL event with `decision_origin: escalation`. The two records share a `correlation_id` field (consistent with C5 pattern).
- Heavy evidence payloads (rule text excerpts, application field copies) use hash-and-ref (`{ref, hash, field}`) rather than inline content, consistent with the C3 split-storage model.
- `determination: needs-review` with `expert_review_required: true` MUST NOT be advanced to Phase 5 output. The block is enforced by the workflow engine, not by a prose policy.

**Example C9 record (illustrative):**

```json
{
  "rule_id": "fdep-stormwater-general",
  "jurisdiction_id": "fl-state",
  "determination": "needs-review",
  "evidence_pointer": "s3://prov/swcmcd/app-2026-0412/rules/fdep-erp-threshold-eval.json",
  "decision_origin": "escalation",
  "expert_review_required": true
}
```

The companion S1 HITL event:

```json
{
  "event_id": "019123ab-...",
  "timestamp": "2026-05-29T10:14:02.440Z",
  "agent_id": "stormwater-permit-triage",
  "decision_origin": "escalation",
  "evidence_pointer": "s3://prov/swcmcd/app-2026-0412/rules/fdep-erp-threshold-eval.json",
  "rationale": "ERP threshold determination for 0.4-acre impervious increase requires licensed engineer review; rule fdep-stormwater-general verify_flag=true and last_confirmed > 12 months. Blocking applicant output."
}
```

## 3. Exception Handling

| Exception | Agent behavior | HITL required |
|---|---|---|
| Rule row not found in jurisdiction map | Halt determination for that rule; emit `needs-review` C9 record with `evidence_pointer` referencing the lookup failure; raise HITL | Yes |
| Evidence pointer fails to resolve | Halt; do not emit a `compliant` determination without evidence; emit `needs-review` | Yes |
| Conflicting rule determinations (two rules produce contradictory requirements) | Classify entire application as `needs-review`; surface conflict description in rationale | Yes |
| Application scope crosses multiple jurisdictions | Activate rules from each jurisdiction independently; aggregate per Phase 4 logic | Only if any single rule triggers `expert_review_required` |
| Stale rule (last_confirmed > 12 months) | Set `expert_review_required: true` for affected rule regardless of other conditions | Yes |

## 4. Worked Example — 30A Lot Clearing Application

**Application:** Parcel 09-3S-19-23000-000-0230 (illustrative parcel), 1.2 acres, Walton County. Activity: vegetation removal and 0.4-acre impervious surface addition. Submitted to SWCMCD portal.

**Phase 1 result.** Application complete; parcel resolves. Intake logged.

**Phase 2 activated rules:** `walton-co-ldco`, `fdep-stormwater-general`, `swcmcd-permit-intake`, `fl-pub-records-access`.

**Phase 3 determinations:**

| rule_id | determination | decision_origin | expert_review_required | rationale |
|---|---|---|---|---|
| `fl-pub-records-access` | `compliant` | `compliance-determination` | false | Application submitted to district portal; public-record handling is the district's standard operating procedure |
| `swcmcd-permit-intake` | `compliant` | `compliance-determination` | false | All intake fields present; application complete per portal schema |
| `walton-co-ldco` | `needs-review` | `escalation` | **true** | Impervious increase of 0.4 acres crosses County LDC Ch. 5 review threshold; engineering review required `[VERIFY]` |
| `fdep-stormwater-general` | `needs-review` | `escalation` | **true** | ERP applicability requires FDEP-threshold calculation; `verify_flag: true` and `last_confirmed: unknown`; `[ATTORNEY REVIEW]` |

**Phase 3 HITL events raised:** 2 (one per `expert_review_required: true` rule). Workflow blocked at Phase 4 aggregation.

**Phase 4 disposition:** `needs-review` (blocked). Applicant output not produced. Clerk queue notified with the two open HITL tasks assigned to District Engineer (stormwater) and outside environmental counsel.

**Phase 5 (after expert resolution):** Engineer confirms LDC review required; counsel confirms ERP pre-application meeting required. Both records updated; disposition advances to `non-compliant` (application is not yet complete for regulatory purposes). Determination summary drafted for clerk review. Applicant notified by clerk: application requires LDC permit and ERP pre-application meeting before processing can continue.

## 5. Integration with e4-workflow-artifacts

This compliance workflow follows the `e4-workflow-artifacts` process-map pattern. Each phase maps to a `workflow step` (glossary term). The per-phase step IDs (`intake-check`, `rule-identification`, `per-rule-determination`, `aggregated-disposition`, `record-notify`) are the `step_id` values used when this workflow emits C5 records via any parent workflow orchestrator that wraps it. The compliance workflow itself is the C9 producer; the parent orchestrator, if any, is the C5 producer.