Executive Summary: Raw status and normalized status answer different questions in a Puerto Rico verification workflow. Raw status preserves what a selected registry response said. A normalized status gives a system a consistent representation for a defined operational use. Neither one decides whether a lender should fund a file. Cobalt's coverage guidance says field depth varies by jurisdiction and documented availability is not a guarantee of population for every record.[1] The safe design retains the source wording, the transformation that produced the standardized value, and the lender policy action as three different facts. The Puerto Rico matrix documents raw status and normalized-status context where returned.[2] “Where returned” matters here as much as it does for any other field. It means the integration should capture an explicit Unknown when the source does not establish status, rather than invent a normalized value. It also means that a field matrix is not a statement that every record maps the same way or supports the same policy outcome.
What is raw status?
Raw status is the source label or value returned for a selected Puerto Rico record. Preserve it exactly enough for later review, together with the selected entity, source context, query, response time, and retrieval event. Do not rewrite it to make it fit a display convention. If the source does not return a status, store that as `not-returned` or an equivalent explicit evidence state. An empty value is not a negative status and is not proof that an entity does not exist.
Puerto Rico's public corporation search uses name and registration-number routes.[3] That makes selection evidence part of the status record. Before anyone interprets a status value, the workflow must show why the returned entity is the application entity. A status from an unselected candidate is not a status conclusion about the applicant.
What is normalized status?
Normalized status is a standardized label created for a defined system use. It can make a workflow easier to route or report on, but it is still a transformation. Store the normalized value with a mapping version, mapping rule identifier, transformation time, and source raw status. This allows a reviewer to see what changed if the mapping is later revised. It also prevents the system from presenting a standardized label as though it were the exact public registry wording.
The benefit of normalization is consistency, not certainty. A lending team may need a consistent operational category to send cases to a queue, compare fields, or apply a policy. But a normalized category cannot supply missing legal context, resolve an uncertain entity match, or decide the materiality of a returned record. Those questions remain outside the transformation.
Why retain both values?
Retaining only raw status creates reporting friction because similar evidence may appear in different labels or formats. Retaining only normalized status creates an audit problem because the source wording and mapping rationale can disappear. Retaining both lets the team work with a consistent label while keeping the evidence needed to test, revise, or challenge that label. It is a small data requirement with a large review benefit.
The record should answer four questions: What did the source return? Which record was selected? Which mapping version produced the normalized value? What did lender policy require next? If those questions are represented by a single field, a later reviewer cannot distinguish a public source fact from an internal transformation or a final business action.
Select the record before mapping a status
Record selection precedes status mapping. Preserve the application legal name, Puerto Rico scope, submitted identifier where available, selected legal title, and selection rationale. The Department of State administers the public Registry of Corporations and Entities.[4] That gives the status field source context but does not guarantee that a search result belongs to the borrower. If the entity cannot be selected safely, open an identity review. Do not map a candidate's status and attach it to the file.
This order prevents a common automation error. A system finds a plausible name, normalizes its returned status, and routes the applicant based on a record it never established. The normalized value may look precise because it is standardized, but the selection boundary is still unresolved. A disciplined workflow treats that state as an identity question, not a status answer.
Make mapping rules inspectable
A mapping rule needs a stable identifier, an effective date, a source-field scope, a result label, and a stated limit. It should also record how the system handles blank, unfamiliar, or conflicting values. A rule may say that a known raw label maps to a workflow category for a particular use. It should not say that the category automatically means compliant, fraudulent, fundable, or unfundable. Those are lender policy decisions requiring separately defined inputs and authority.
State corporate records and requirements are state specific.[5] For that reason, do not publish or encode a universal Puerto Rico mapping based on a generic assumption about status labels. Test permitted records, preserve the observed raw evidence, and version the actual mapping the lender approves. If a value is not covered by the mapping, preserve it and route it as `mapping-not-established` instead of forcing it into a familiar category.
Separate mapping from policy action
The transformation layer says how a raw value was represented. The policy layer says whether that representation matters for a particular lending use. Keep the layers separate in storage and in the review screen. A policy event should include policy version, condition evaluated, action, owner, next evidence if any, and disposition. It should point to the source and transformation records rather than replace them.
For example, an internal policy may require a review when a status category is not established for a specific product. The source record says whether a raw value was returned. The transformation record says whether it mapped. The policy record says what the lender did. This sequence lets an auditor see that the source did not decline the file and that Cobalt did not make the lending decision.
Handle Unknown, changed, and conflicting states
Use explicit states for `raw-not-returned`, `entity-not-selected`, `mapping-not-established`, `mapping-version-changed`, and `policy-review-required`. Each state names a real boundary in the workflow. It prevents a blank, a new source label, or a later policy change from becoming a synthetic inactive status. A lender can choose to collect more evidence, hold the file, or accept an Unknown for a defined use, but that choice belongs to the policy layer.
If a mapping changes, do not silently rewrite historical normalized values. Store the new version and apply it prospectively or through a documented re-evaluation process. The original file must continue to show what source value was observed and what mapping rule operated at that time. This is the only way to tell later whether a changed outcome followed new evidence or a new internal rule.
Give reviewers a side-by-side screen
Show the application claim, selected entity, raw source status, retrieval time, mapping rule and version, normalized result, evidence state, policy trigger, owner, and final disposition. Place source and normalized labels side by side, not one above the other as if the second replaced the first. If no raw status was returned, say so. If the entity was not selected, say so before showing a status workflow. Clear labels make the exception queue easier to review and harder to misuse.
The reviewer should not be asked to diagnose why a public source used a particular word unless a source supports that explanation. Their job is to verify selection, understand the transformation, apply the correct policy, and record any additional evidence. This is more reliable than asking them to interpret a normalized label as a complete legal or business description.
Test a mapping before automation
Use permitted representative records to test the query, selection, raw-value capture, transformation, Unknown state, exception route, and replay. Include a selected record with a mapped raw status, a selected record with no returned status, an unselected result, a raw label not covered by the mapping, and a policy that treats the same normalized category differently by use case. Record the results as coverage observations, not as a universal field promise.
Then test the audit replay. NIST guidance supports retaining context that makes review and reconstruction possible.[6] A reviewer should be able to identify source, selection, mapping, policy, and outcome in order. If any layer cannot be reconstructed, change the data model or the operational procedure before expanding automation.
Measure the control rather than interpreting a status trend
Measure selection success, returned-status rates in permitted tests, mapping-not-established frequency, mapping-version changes, policy exceptions, queue aging, and closure reasons. Segment the results by workflow use case and policy version. These measures help a team improve mapping coverage and operations. They do not establish that a given status predicts a business's credit quality, legal compliance, or lending outcome.
If the same raw value repeatedly falls outside a mapping, inspect the source evidence and revise the rule deliberately. If selection failures rise, improve input or matching review. If exception aging grows, clarify ownership. The measurements are signals about the verification process. They must not convert into claims about the businesses behind the records.
Use public references as context, not a shortcut
Puerto Rico's corporation services and public forms can help a team locate official process information.[7] [8] They do not provide a universal mapping policy or turn a returned status into a lender conclusion. General legal context is likewise separate from a record-specific response and a lender's internal rule.[9]
Keeping those boundaries clear lets a team use trustworthy sources without overclaiming their role. The registry provides a source observation. The normalization provides a controlled representation. The lender policy provides the decision route. Each layer can be examined, revised, and governed without pretending it is another layer.
Where Cobalt fits
Cobalt provides documented Puerto Rico raw and normalized status context where returned. It does not promise a particular value for every record, decide how a lender maps an unfamiliar value, or determine the consequence of any status in a funding process. The lender owns mapping governance, exception policy, additional evidence, and final disposition.
That separation makes normalization safer. A team can gain operational consistency while retaining the source wording that gives the value meaning. It can change a mapping or policy without rewriting history, and it can show a reviewer exactly where evidence ended and lender judgment began.
What should a risk leader do next?
Define raw status, selected-record evidence, mapping version, normalized output, explicit Unknown states, policy trigger, exception owner, and closure record before a normalized field enters an automated rule. Test each state with permitted Puerto Rico results. Keep both source and transformation history in the case file.
This gives underwriting, operations, and engineering a common language for status evidence. It prevents a clean-looking normalized label from hiding a missing source value, a questionable selection, a changed mapping, or a lender-owned decision.
Build a status record that survives a policy change
The source record should contain the raw status as observed, the source retrieval time, the entity selection reference, and any returned source trail. The transformation record should contain the mapping rule identifier, mapping version, transformation time, input status, normalized output, and a reason when the value was not mapped. The policy record should contain the use case, policy version, condition evaluated, owner, next action, and closure. Linking these three records gives a later reviewer a complete chain without requiring any field to stand in for another.
This structure is particularly valuable when a lender revises a policy. The organization can apply a new policy to future files without retroactively claiming that an older raw status had a different meaning. It can also run a documented re-evaluation if policy requires one. In either case, the review shows what was observed first, what was transformed second, and what the lender decided third.
Use reason codes that describe the status-control state
Reason codes should say what the process needs next. Useful examples include `selected-raw-status-returned`, `raw-status-not-returned`, `normalization-complete`, `normalization-not-established`, `entity-selection-review`, `policy-review-required`, and `alternate-evidence-open`. These labels allow operations to measure why cases left the normal route. They do not imply that a company is active, inactive, lawful, fraudulent, eligible, or ineligible.
A code such as `normalization-not-established` is especially important. It means the source returned a value that the current transformation rules do not cover. The correct next step is a defined review of source context and mapping governance, not an automatic default to a familiar status. This protects against a new or unusual label being silently collapsed into a misleading category simply because the automation needs an answer.
Establish ownership for each layer
Engineering can own the faithful capture of raw values and execution of a versioned mapping. Risk or operations can own approval of mapping changes and policy rules. An underwriter or exception team can own individual-case review. This division prevents an integration change from altering a lending policy without the policy owner's knowledge. It also prevents a manual reviewer from silently changing a source record to make the screen easier to use.
The handoff between owners should be explicit. A mapping-review queue needs the raw value, selected record, mapping version, policy use case, and evidence limit. A case-review queue needs the policy condition, requested next evidence, and deadline. A source-data issue needs the retrieval event and the observed field state. Clear ownership creates a route for correction without confusing a technical defect with a business decision.
Test changes through controlled cases
When a mapping changes, test it against permitted representative records before it reaches a production decision path. Confirm that raw source values remain unchanged, the new version is stored, formerly unmapped values receive the expected state, and the policy layer does not trigger a decision outside its defined scope. Then test a historical replay using both versions. The reviewer should be able to explain why the same raw label could be displayed differently after a legitimate, recorded mapping change.
Puerto Rico's public assistance information can direct users to official service paths, but it does not resolve mapping governance or replace observed record evidence.[10] The lender must decide how mapping changes are proposed, approved, tested, released, and audited.
Review exception quality, not only exception volume
Count how many cases entered a queue, but also inspect whether the reason code matched the real evidence state, whether the selected entity was supported, whether a mapping version was recorded, whether the policy action was within scope, and whether closure retained the evidence that justified it. An exception queue can appear efficient while hiding many cases that were routed for the wrong reason. Sampling case quality exposes that problem.
Use the findings to improve training and controls. If reviewers confuse a normalized value with the raw source label, make the screen clearer. If many items have no mapping version, repair the transformation contract. If policy owners cannot explain why a category matters, narrow the rule. Each correction keeps the workflow grounded in observed evidence rather than allowing status labels to accumulate unsupported meanings.
Set the minimum safe rule for status automation
Do not normalize a record before entity selection is supported. Do not discard the raw source value. Do not map a missing value to a negative status. Do not allow a mapping to stand in for policy. Preserve transformation version and time. Route unfamiliar values and missing fields through named evidence states. Retain policy owner and closure evidence separately. This minimum rule gives a team enough structure to automate a consistent workflow while keeping the source and decision boundaries visible.
Make status reporting traceable to its source layer
Dashboards should report raw-status coverage, normalization coverage, and policy outcomes as different measures. A chart of normalized categories can be useful for operations, but it must show the mapping version and excluded or Unknown population. A chart of raw source values can reveal new labels or coverage gaps, but it should not be read as a lending-decision report. A policy dashboard can show queue volume and closure patterns, but it should not claim that the source itself made the disposition.
This separation lets leaders ask better questions. Did the source return a value? Did the transformation cover it? Did policy need an exception? Was the case resolved with additional evidence? Each question has an owner and a different corrective action. Combining them into one status metric can hide a coverage problem inside a policy number or make a policy rule look like a registry fact.
Report the retrieval date with each source-coverage measure. That preserves the difference between a current observation and a historical result and gives the mapping owner a concrete point for retesting when coverage or policy changes. It also keeps dashboard users from mistaking stale transformation output for a newly retrieved registry fact now.
.jpg){kind=small}
.png)