> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: RMD filing flagged deficient, overdue, or unexpectedly withdrawn > Work the FCC Robocall Mitigation Database (RMD) lifecycle failures end to end: a deficient flag, a certification clock that expired without warning, a withdrawn filing still being re-filed, a draft that will not submit, and the 409 codes each path returns — with the fix run for each. # Troubleshooting: RMD filing lifecycle failures The [RMD filing lifecycle](/compliance/rmd-registration) page teaches the happy path — draft, submit, certify, keep current, withdraw. This page picks up where a filing stopped being happy: the FCC or a terminating carrier flagged it deficient, the recertification clock ran out with no one watching, a filing was withdrawn (sometimes accidentally) and now needs to come back, or a re-file attempt returns a `409` you did not expect. Each failure below has a diagnostic that names the exact response fields to read and a fix run that returns the filing to `active`. Orbit records and tracks your RMD filing state. **Nothing here is legal advice**, and nothing files with the FCC for you — the filed data, and every lifecycle decision along the way, stays with you. ## How the lifecycle moves (and where it jams) ``` draft ──▶ submitted ──▶ active ──▶ remediation_required ──▶ active │ │ │ │ ▼ ▼ ▼ ▼ withdrawn ◀── any non-terminal state ──▶ withdrawn ──▶ draft (re-open) ``` A filing jams at five points, covered in order below: 1. **`active` flagged deficient** — a carrier or the FCC reports a problem; the filing sits in `remediation_required` until you resolve it. 2. **`active` past the review date** — the recertification verdict flips to `overdue` and, under `enforce`, origination blocks with a `403 RMD_RECERT_OVERDUE` at call time. 3. **Withdrawn by mistake** — `withdrawn` is reversible; re-`POST /compliance/rmd` re-opens the same registration to `draft`. 4. **Draft will not submit** — mandatory fields (usually the mitigation plan) are missing; the response's `details` array names every blocker. 5. **409 on re-file** — `RMD_LOCKED`, `RMD_INCOMPLETE`, and `RMD_INVALID_TRANSITION` each mean a different wrong move. ## Symptom → cause → fix ### Symptom 1: filing flagged deficient (the "filed but flagged" state) The registration shows `status: "remediation_required"` on **Settings → Compliance → RMD**, or your origination guard (in `warn` or `enforce` mode) flags calls because `RMD_REMEDIATION_REQUIRED` fires. **Diagnostic.** Read the current state: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/rmd" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` `registration.status` is `remediation_required`, and `registration.remediation_reason` carries whatever was recorded as the cause. The flag is class-level data — anyone with member read access can pull it; you do not need to be the owner to diagnose. **Fix run.** 1. **Treat the cause** — re-file with the FCC RMD portal once the filing content is corrected (a bounced contact email, a stale mitigation plan, an incomplete address). 2. **Resolve the flag:** ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/rmd/resolve" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{"notes": "Contact email corrected and re-filed with the FCC."}' ``` Resolving returns the filing to `active` and **restarts the recertification clock from the resolve date** — a resolved deficiency resets the review deadline, it does not inherit the old one. 3. If your enforcement mode is `enforce`, origination unblocks the moment the resolve lands; in `warn`, the flag clears on the next call. Expected lead time: the remediation itself is minutes of API calls — the long pole is whatever the FCC or carrier requires of the re-file. Do not sit in `remediation_required` waiting for a reviewer; the state only flags that *you* still owe the correction. ### Symptom 2: certified-but-expired (silent recertification lapse) The filing shows `recertification.status: "overdue"` — or worse, origination `403`s with `RMD_RECERT_OVERDUE` under `enforce`. The counter-intuitive part is that **the countdown lives in the read response, not in a webhook**: `GET /compliance/rmd` recomputes the full verdict on every call, so nothing pings you when `days_remaining` crosses zero. **Diagnostic.** Read the registration and look at `recertification`: ```json theme={null} { "data": { "registration": { "status": "active", "certified_at": "2025-08-31T14:00:00.000Z", "recert_interval_days": 365, "recertification": { "due_at": "2026-08-31T14:00:00.000Z", "status": "due_soon", "days_remaining": 12, "overdue": false, "reason": "The RMD certification review date is approaching; recertify to keep the filing current." } } } } ``` The "next cert by" date is exactly `certified_at + recert_interval_days` (default 365; settable up to 3650), returned ready-computed as `recertification.due_at`. When `days_remaining` drops to 30 or below the verdict is `due_soon`; past the date it is `overdue` with `overdue: true`. **Fix run.** 1. Re-attest with the FCC (periodic review / re-certification of a current filing). 2. Restart the clock by re-certifying. Two routes reach `active` and set a fresh `certified_at`: * if you walked the filing through a deficiency, `POST /compliance/rmd/resolve`; * if the filing is still plain `active`, withdraw it and re-file it as below (Symptom 3) — the re-file path mints a new `certified_at` when you re-certify. 3. Watch `recert_interval_days` when you next edit a **draft**: set the review cadence your counsel requires instead of the 365-day default. The field applies at draft time and survives for the life of the registration. To never be caught by symptom 2 again: poll `GET /compliance/rmd` on a job and alert when `recertification.status` reaches `due_soon`. The field exists on every read, so an external reminder is a three-line script. ### Symptom 3: withdrawn filing still being originated (guard defaults) Two situations hide behind one word. A withdrawn filing shows up as a `403 RMD_NOT_ACTIVE` origination block (under `enforce`), or a `warn`-mode flag — and the operator who withdrew it accidentally cannot re-file until the re-open completes. **Diagnostic.** Read the registration and the enforcement mode in one call (the dashboard's **Settings → Compliance → RMD** page shows both): ```json theme={null} { "data": { "registration": { "status": "withdrawn", "withdrawn_at": "2026-08-28T09:41:00.000Z" }, "enforcement": { "mode": "off", "updated_at": null } } } ``` `enforcement.mode` of `off` (the default) means the opt-in call-time guard under 47 CFR § 64.6305 isn't blocking anything — origination proceeds regardless of the withdrawn state. In `warn` or `enforce`, the same withdrawn filing flags or blocks with `RMD_NOT_ACTIVE`. **Fix run.** 1. **Re-open the withdrawn filing to `draft`:** ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/rmd" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "company_name": "Acme Communications LLC", "business_address": "100 Market Street, San Francisco, CA 94105", "stir_shaken_status": "partial", "mitigation_plan": "…", "contact_name": "Jordan Lee", "contact_email": "compliance@acme.example" }' ``` `POST /compliance/rmd` on a `withdrawn` filing re-opens it to `draft` and **keeps the original id and created\_at** — the re-file is a continuation, not a fresh record. 2. Correct the mandatory fields (see Symptom 4 if you get a `409 RMD_INCOMPLETE`). 3. `POST /compliance/rmd/submit` (records the FCC filing reference), then `POST /compliance/rmd/certify` when publication is confirmed. The recertification clock restarts from that new `certified_at`. 4. Review the enforcement mode **before** you turn the filing back on: if the withdrawal was a deliberate pause of origination, putting the guard straight back to `enforce` re-blocks calls the minute certify lands. Set it with `PUT /compliance/rmd/enforcement` (see [RMD registration](/compliance/rmd-registration#call-time-origination-enforcement)) — and remember `off` is the tenant-owned default; nothing platform-level forces you into a gate. ### Symptom 4: draft won't submit — incomplete mandatory fields `POST /compliance/rmd/submit` returns `409 RMD_INCOMPLETE` even though the draft looked fine when you saved it. The blocker list lives in the response's `details` array: ```json theme={null} { "error": { "code": "RMD_INCOMPLETE", "message": "The RMD registration cannot be submitted yet.", "status": 409, "details": [ "a robocall-mitigation plan is required unless STIR/SHAKEN is fully implemented (stir_shaken_status = 'complete')" ] } } ``` The check runs at submit time, not at draft-save time — so a draft that was housed in state can hold a missing piece for months without anyone noticing. **Diagnostic.** Get the exact blockers from `details` — each string names the missing field. The usual offender is the mitigation plan, which is mandatory whenever `stir_shaken_status` is `partial` or `none`. The other four are the identity fields: `company_name`, `business_address`, `contact_name`, `contact_email`. **Fix run.** 1. `POST /compliance/rmd` with the missing field filled in (only allowed while the filing is still `draft` or `withdrawn` — a filed registration is mutated through the lifecycle endpoints). 2. Re-`POST /compliance/rmd/submit`. The same four calls always succeed once every blocker resolves. 3. If the filing is already past `draft` (submitted or active), stop editing it in place — `409 RMD_LOCKED` is the surface telling you to go through `submit` / `certify` / `remediation` / `resolve` / `withdraw` instead. ### Symptom 5: 409 conflict on re-submit or re-file A re-file attempt hands back a `409` you can't place. The [error-code catalog](/reference/error-codes) has three RMD conflict codes and each one means something different: | Code | Definition | Where it surfaces | Fix run | | ------------------------------ | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | `RMD_INVALID_TRANSITION` (409) | A lifecycle call hit a state it can't reach (e.g. certifying from `draft`, or re-submitting an `active` filing) | Any lifecycle endpoint | Pull `GET /compliance/rmd` and re-apply the correct transition — the response names the status you're coming from | | `RMD_INCOMPLETE` (409) | The draft is missing a submission blocker (most often the mitigation plan) | `POST /compliance/rmd/submit` | Read the `details` array, fill what it names, re-submit (Symptom 4) | | `RMD_LOCKED` (409) | You tried to in-place-edit a filed (`submitted` / `active` / `remediation_required`) registration | `POST /compliance/rmd` | Move the filing through the lifecycle endpoints instead of editing it | | `RMD_NOT_FOUND` (404) | No registration has ever been created for the org | Any lifecycle endpoint, or the enforcement PUT, or the certified read | Create the draft with `POST /compliance/rmd` first | | `VALIDATION_ERROR` (422) | A field failed schema validation (e.g. `contact_phone` isn't E.164, `recert_interval_days` exceeds 3650) | Any endpoint | Read `formatZodErrors` in the `details` array | The re-file-idempotent path: `POST /compliance/rmd` on a `withdrawn` filing is the correct re-file (keeps id), `POST` on a filed registration is the wrong re-file (`RMD_LOCKED`), and a first-time `POST` mints a fresh registration. That is the end of the 409 map — none of the codes is a transient collision or a retry target. ## Error-code quick reference (RMD endpoints) | HTTP | Code | Where it fires | | ---- | ------------------------ | ------------------------------------------ | | 404 | `RMD_NOT_FOUND` | lifecycle calls before any draft exists | | 409 | `RMD_INVALID_TRANSITION` | a lifecycle jump the state table forbids | | 409 | `RMD_INCOMPLETE` | `/rmd/submit` with open blockers | | 409 | `RMD_LOCKED` | `/rmd` POST against a filed registration | | 422 | `VALIDATION_ERROR` | bad payload shape (e.g. non-E.164 phone) | | 403 | `RMD_NOT_CURRENT` | origination guard (detail names the cause) | `RMD_NOT_CURRENT` at call time carries one of four details: `RMD_NOT_REGISTERED`, `RMD_NOT_ACTIVE`, `RMD_REMEDIATION_REQUIRED`, or `RMD_RECERT_OVERDUE` — match it against the [RMD registration](/compliance/rmd-registration#call-time-origination-enforcement) page's guard table. ## What not to do * **Do not re-activate the withdrawn filing without reviewing the guard.** If `enforcement.mode` is `enforce` or `warn`, bringing the filing back to `active` flips the origination verdict instantly. A deliberate pause becomes an accidental block, a warn becomes a quiet resume. Review the mode with the same care you review the filing. * **Do not PUT `"certified"` manually.** The only route to `active` is `POST /compliance/rmd/certify` (or `POST /compliance/rmd/resolve`) after a real `submitted` state — a hand-edited record would carry a `certified_at` that no filing ever supported, and every downstream check trusts that timestamp. * **Do not try to edit a filed registration.** `409 RMD_LOCKED` is the surface refusing in-place mutation; it is intentional. Walk the lifecycle endpoints instead. * **Do not treat a poll-loop on `GET /compliance/rmd` as a substitute for counsel.** The filed data stays with you; the platform records it. This page is operational guidance, not legal advice. ## See also * [RMD filing lifecycle](/compliance/rmd-registration) — the full happy path, the recertification verdicts, and the endpoint reference. * [Send gates](/compliance/send-gates) — the outbound gate stack the origination guard reads alongside. * [STIR/SHAKEN attestation](/channels/voice/stir-shaken) — the level you assert on the filing and what callers see. * [ITG traceback](/compliance/itg-traceback) — the companion obligation once your traffic is attributable. * [Troubleshooting](/reference/troubleshooting) — the rest of the fault-finder pages if this symptom list didn't cover yours.