State configuration navigator

Outcome

You have a single landing page that answers "what's configured for state XX?" and links out to every editor that owns the underlying data.

Prerequisites

• config.read to view.

What it is — and isn't

/admin/states is a read-only directory. It owns no schema. Every "view all" link drops the operator into the editor that owns that data:

Section	Source	Editor link
Payers + LOBs	rcm_master.payer.state	Payer + program config
Trading partners + companion guides	edi-app	EDI category
Submission routing rules	rcm_master.submission_routing_rule	Submission routing rules
Rule sets	config.rule_set_version	Publish rule changes
Modifier injection rules	rcm_reference.modifier_injection_rule	Modifier rules
Trading partner credential vault	edi-app	Credential vault

What the navigator does NOT do:

• No mutations. No "rename state", no "deactivate state", no "delete all OH config" button.
• No state-rate-codes. Master-data rate codes live in State rate code reference.
• No fee-schedule listing. Fee schedules are payer-scoped, not state-scoped — use /admin/fee-schedules?state=XX directly.

Recommended onboarding flow for a new state

When you receive a new state engagement (call it XX):

1. Open /admin/states. Confirm XX is not in the directory yet. If it is, something else has been configured — investigate before proceeding.

2. Tier 1 — Payers + LOBs (/admin/payers). Register the state's Medicaid agency / commercial payers. Each LOB carries the state column that surfaces on the navigator.

3. Tier 2 — Trading partners + companion guides (edi-app). Register the clearinghouse / direct partner serving the state's payers; attach the matching companion guide.

4. Tier 3 — Submission routing rules (edi-app). Map state=XX × payer × tx_type → trading_partner + guide. This is the table that ties partners + guides to the state.

5. Tier 4 — Rule sets (/admin/rules). Author or clone the state's pre-submit YAML, with config_scope.state=XX.

6. Tier 5 — Modifier injection rules (/admin/modifiers/injection). Add state-scoped rules where the state has unique modifier requirements (e.g. ABA HO/HN by credential).

7. Verify on the navigator. Reload /admin/states/XX — the counts should reflect what you just wrote, and each section's "view all" link should round-trip back to the editor.

8. Test scrub end-to-end. Build a test claim against the new state's facility/payer and run the scrubber (POST /scrub or via the worklist) — confirm the global stage runs, then the state stage picks up the new rule set, then routing resolves to the new trading partner.

Operational guarantees

• The directory shows only states that already have at least one configured resource. A state with no rules + no routing + no modifier rule + no payer LOB will be absent from /admin/states until something is added.
• The detail endpoint does not 404 for a clean state code — visiting /admin/states/CA for a state that has nothing returns zero counts and empty recent-item lists. Intentional, so operators can navigate to a state mid-setup.

Validation

Check	Expected
/admin/states lists every state with config	Yes
Empty state visit	Returns zero counts (no 404)
"View all" links	Round-trip to the data owner

Cross-references

• Batch eligibility sweeps — sweeps run on members regardless of state; this navigator doesn't filter or schedule them.
• Modifier rules — honours ?state=XX URL filtering natively.

Next

4.9 — Payer contract registry