...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<ErrorMessage text>[: <attributeName>[=<attributeValue>]][: expected <attributeName>=<expectedValue>] |
This section is about OSF input validation, unrelated to the OFF's protocol (TDA/PDX vs REST) — it does not change when an OFF migrates.
Common message templates
| Situation | DASErrorMessages | Resulting message (example) |
|---|---|---|
| Priority date doesn't match the registered one | MISMATCHED_PRIORITY_FILING_DATE | "Mismatched priority filing date: documentDate: expected documentDate=2022-10-01" |
| Access code doesn't match | MISMATCHED_ACCESS_CODE | "Mismatched access code: dasAccessCode: expected dasAccessCode=AB46" |
| Both date and access code wrong | MISMATCHED_ACCESS_CODE_AND_PRIORITY_FILING_DATE | "Mismatched access code and priority filing date: dasAccessCode, documentDate: expected dasAccessCode=AB46, documentDate=2022-10-01" |
| documentKindCategory wrong (alone or combined) | MISMATCHED_DOCUMENT_KIND_CATEGORY (+ combos) | "Mismatched document kind category: documentKindCategory=design: expected documentKindCategory=patent" |
| Priority date missing | MISSING_PRIORITY_FILING_DATE | "Missing priority filing date: documentDate" |
| Access code missing | MISSING_ACCESS_CODE | "Missing access code: dasAccessCode" |
| Access code fails format/checksum check | INVALID_ACCESS_CODE | "Invalid access code: dasAccessCode: expected dasAccessCode=AB46" |
| documentDate not a valid date | INVALID_PRIORITY_FILING_DATE | "Invalid priority filing date: documentDate: expected documentDate=2022-10-01" |
| Document not registered | DOCUMENT_NOT_FOUND | "The requested document is not registered in the system: documentNumber=US64/282,001, documentKindCategory=patent" |
| Other field mismatch (generic) | MISMATCHED_INPUT_VALUE | "Mismatched input value: documentKindCategory: expected documentKindCategory=patent" |
| Invalid file format on upload | INVALID_DOCUMENT_FILE_FORMAT | "Invalid document file format: fileFormatCategory=jpg: expected fileFormatCategory=pdf,zip" |
| Required field missing on upload | MISSING_REQUIRED_FIELD | "Missing required field: fileChecksum" |
...
requestStatusCategory (SERVICE_STATUS) | requestStatusMessage (UI_MESSAGE, when set) |
|---|---|
document registered | document registered successfully |
document not registered | document not registered |
registration - recorded | registration - recorded |
successful | successful |
success | success |
pending | — |
registration - withdrawn | registration - withdrawn |
Where the message text comes from
...
today, for a hosted OFF on TDA/PDX
If the failure originated from a hosted OFF answering over TDA/PDX → requestStatusMessage is overwritten with the EDI-translated text documented on 5.1.2 (e.g. "ACCESS NOT AUTHORIZED" for TDA code 5), because OSF_LAST_MESSAGE is set to that EDI string regardless of which channel (push or pull) ends up reading it.
If the failure was raised by DAS's own validator instead (e.g. an OSF polls a retrieval it submitted with a mismatched access code, unrelated to any OFF) → you'll see the literal strings in the tables above directly (e.g. unmatched access code).
So the same underlying TDA failure can appear as "ACCESS NOT AUTHORIZED" to a polling OSF, and as errorCode: -6, statusMessage: "ACCESS NOT AUTHORIZED" to a webhook-registered OSF — same text, but only the webhook gets the numeric code.
🆕 What changes once this OFF migrates from TDA/PDX to REST
Just like on the notification channel (5.1.2), OSF_LAST_MESSAGE (which becomes requestStatusMessage here) is only EDI-translated when event.respondingProtocol == 'tda'. Once the OFF answers over the draft REST interface instead (5.1.1), the raw statusMessage the OFF sent is stored and returned as-is — no EDI translation step runs at all.
| Today (OFF on TDA/PDX) | After migration (OFF on REST, per the draft) | |
|---|---|---|
requestStatusMessage source | EDI-translated text from the fixed lookup table on 5.1.2 (ALL-CAPS legacy phrases) | Whatever free text the OFF's REST endpoint sent — expected to already match the literal das-status.ts strings in the tables above |
| Practical effect | requestStatusMessage looks different from the strings DAS uses for its own native validation failures (e.g. "ACCESS NOT AUTHORIZED" vs. "unmatched access code") | requestStatusMessage should look the same style as DAS's own native strings once the OFF reuses the same vocabulary — e.g. "document awaiting security clearance" instead of "ACCESS NOT AUTHORIZED" for the TDA-5 equivalent case |
| Consistency guarantee | Strong — fixed EDI lookup table | ⚠️ Weak — nothing validates what the OFF actually sends; see 5.1.1 for the gaps in the draft's vocabulary (e.g. TDA 2 and TDA 5 both map to the same REST phrase) |
Worked example — same underlying failure (TDA code 5 equivalent), polled via GET: - Today: {"requestStatusCategory": "error", "requestStatusMessage": "ACCESS NOT AUTHORIZED"} - After migration: {"requestStatusCategory": "error", "requestStatusMessage": "document awaiting security clearance"} (assuming the OFF implements the draft vocabulary as documented on 5.1.1)
Quick reference: which page documents which field
| Field you see | Where it's documented |
|---|---|
code, details[].code, details[].message (HTTP 4xx on submission) | This page, section A |
requestStatusCategory, requestStatusMessage (HTTP 200 on poll) | This page, section B |
errorCode, statusMessage (push notification body) | 5.1.2.- Responses from DAS to OSF via notification endpoint |
| Raw Legacy TDA/PDX numeric code, and its REST migration mapping (OFF→DAS only, never seen by the OSF directly) | 5.1.1.- Responses from OFF to DAS (TDA/PDX codes) |