Executive Summary: Before a Puerto Rico registry field controls an automated workflow, test what the route actually returns and how the lender's policy responds when it does not return the expected evidence. A field matrix is useful for planning, but it is not a record-level promise. Cobalt's coverage guidance says field depth and availability vary by jurisdiction and do not guarantee every field is populated for every response.[1] The test must therefore include returned, missing, unselected, and policy exception states, not only a successful response. The current Puerto Rico matrix documents relevant registry context where fields are returned.[2] That lets a lender define what it wants to observe, but it does not let the lender assume a field, alternative match, source URL, screenshot, or other value will appear in every production case. A useful test turns documented availability into dated, limited evidence that the lender can inspect before placing a field inside an automated rule.
Start with the policy question, not the API field
Write the specific lender question first. For example, the workflow may need to know whether an entity can be selected, whether a status comparison can be made, whether an address needs review, or whether a missing field should open an alternate-evidence route. Then identify which returned field may support the question and what the policy should do if the field is not established. This prevents engineering from automating a field merely because it appears on a matrix.
The policy statement should include the product or use case, required evidence, acceptable Unknown state, owner, alternate route, and closure rule. It should also say what the field does not decide. A registry status is not a credit decision. A returned officer is not necessarily ownership proof. A missing field is not automatically negative. These limits make the test honest and keep the future rule within the authority of the lender rather than the source.
Define a representative test set
Choose permitted test cases that exercise the workflow's meaningful states. Include a case where an entity can be selected and the target field is returned; a selected entity where the field is not returned; a search with no safe selection; a comparison that can be made; a comparison that cannot be made; and a case where policy requires another approved evidence route. The purpose is not to prove every Puerto Rico entity behaves the same way. It is to observe how this integration and this lender policy behave in the states they must handle.
Puerto Rico's public search supports name and registration-number routes.[3] Retain which input route was tested, the input values allowed by the test, selection rationale, retrieval time, and selected legal title. A result is not useful as coverage evidence if a later reviewer cannot tell what was searched or whether the returned record was selected appropriately.
Keep a test-observation record
Each test observation should record test ID, purpose, environment, date, jurisdiction, input type, selected-entity state, target field, returned raw value or explicit `not-returned`, source context, transformation version, policy result, exception state, owner, and evidence-limit note. Store a source URL or screenshot only if actually returned and permitted by the lender's retention policy. Do not manufacture test evidence to make a checklist look complete.
This record separates observation from inference. “The selected test record returned a value at this time” is an observation. “The field will always be available” is an unsupported inference. “Our underwriting policy can use this field under these conditions” is a lender decision. All three may appear in a test report, but they must be labeled differently so the report does not create a false production promise.
Validate entity selection before field logic
Do not call a field test successful when the entity selection is uncertain. The Puerto Rico Department of State administers the public Registry of Corporations and Entities.[4] That is the source authority, but an individual response still needs a case-specific selection rationale. Capture the search input, returned title, registration identifier where available, and reason the test treated that record as the intended entity.
Create an explicit `entity-not-selected` test as well. Confirm that the workflow routes it to identity review and never extracts a target field from a plausible but unconfirmed result. This is a key automation boundary. A clean field value from the wrong entity is not good test evidence. The rule must handle selection failure before it tries to interpret status, filing, agent, address, or other registry context.
Test returned and missing fields equally
A successful returned value is only one test state. Test the field when it is not returned, unavailable, empty, or not established for a selected record. The expected system behavior should preserve an explicit Unknown state and apply the lender policy that corresponds to that state. It must not substitute a negative default, create an invented mismatch, or silently skip evidence that the policy requires.
Write expected results before running the test. For a returned field, the system may preserve raw source context and a versioned transformation. For a missing field, it may record `field-not-returned`, request more evidence, or close as not required by current policy. The right result depends on the lender's rule. The test proves whether the system followed that rule, not whether an absence says something negative about the business.
Test transformations without losing raw evidence
If the workflow normalizes status, dates, names, or other values, test the transformation separately. Retain raw value, selected record, mapping or transformation version, normalized output, and transformation time. Include a raw value that maps as expected, a value that is Unknown, and a value not covered by the current mapping. Confirm that an unmapped value opens the defined review route rather than being forced into a familiar category.
State registration records and requirements are state specific.[5] That is why a generic mapping assumption is not enough. A lender should test the exact transformation it intends to use, preserve the observed source context, and version its mapping. The future reviewer must be able to tell whether an outcome changed because the source changed or because the mapping changed.
Test policy behavior separately from source behavior
Run the same source state through each relevant policy condition. One product may accept an Unknown for a limited workflow. Another may require a named alternate-evidence route. A third may require a manual owner review. The API response did not make these distinctions. The lender did. Test that the policy layer receives the source state accurately and applies only the action it is authorized to take.
This is where many automations become unsafe. A source field is present, and a team assumes the rule is correct without testing what happens when policy does not need it, when the value is unfamiliar, or when the entity was not selected. Testing policy cases exposes those branches before a production file reaches them. It also keeps Cobalt's role clear: returned registry context, not a lending decision engine.
Test the exception route and owner handoff
For every expected exception state, test that a complete ticket opens with case reference, evidence state, selected-entity state, source context, policy version, assigned owner, next evidence request, and closure criteria. Confirm that routing a case to operations, underwriting, risk, or engineering does not remove the raw source record or replace it with a generic failure label. The queue should make work visible, not obscure why the work began.
Puerto Rico's public forms and assistance information can help an operator find official processes.[6] [7] They do not define the lender's exception policy, evidence standard, or service target. Those must be written and tested as lender controls.
Test audit replay before enabling the rule
Give a completed test case to a reviewer who did not build it. The reviewer should be able to reconstruct the input, scope, selection, returned field, Unknown state if any, transformation, policy action, exception owner, alternate evidence, and final disposition. They should also be able to identify what the source did not establish. If the reviewer cannot answer those questions from the record, the test is incomplete even if the rule returned the expected screen value.
NIST guidance supports retaining context that permits later review and reconstruction.[8] The replay test does not certify every future production response. It certifies that the workflow preserved enough evidence to explain a tested response and its policy route. That is the correct standard for moving from a field matrix to a controlled automation decision.
Define acceptance criteria that include failure states
Acceptance criteria should require more than an HTTP response or a populated field. They should require supported entity selection, correct raw-value capture, explicit Unknown handling, correct transformation version, policy behavior within scope, named exception routing, audit replay, and no invented negative status. Add a test freshness window and an owner who must re-run tests when source coverage, mapping, or policy changes.
An acceptance result can be `pass for tested scenario`, `pass with documented limit`, or `blocked`. Do not use a generic `production-ready` label without the scope of the test. A passing test means the observed scenario met the written criteria on the stated date. It does not mean all records will return the same fields or that every future policy decision will be correct.
Measure test coverage and refresh it
Track which fields, source states, selection states, mapping states, policy branches, exception routes, and replay cases have been tested. Record the date, environment, test owner, result, evidence limit, and next refresh trigger. Use this register to identify gaps, such as a field tested only when returned or a policy tested without an Unknown state. Do not present test counts as a claim about all Puerto Rico records.
Refresh a test when coverage changes, a source response changes, a mapping is revised, a policy rule changes, or a queue pattern reveals an unhandled state. Keep prior results intact. They show what the team knew at the time and avoid rewriting history to make an old test look like a current coverage guarantee.
Where Cobalt fits
Cobalt provides documented Puerto Rico registry context where fields are returned. It can support a lender's representative tests, but it does not promise the same fields for every record, approve a test plan, set acceptance criteria, determine policy behavior, or make a funding decision. The lender owns each of those actions.
That division makes the test more useful. It forces the team to inspect the actual evidence and failure states before automation can hide them. The result is a rule that knows when to act, when to preserve Unknown, and when to hand the case to the person or policy that owns the next decision.
What should a risk or engineering leader do next?
Create a field-test register for the first Puerto Rico rule. Define the policy question, selected test cases, evidence states, expected system behavior, transformation version, exception route, replay checks, acceptance criteria, and refresh trigger. Run the tests with permitted evidence and store both the passing results and documented limits.
This process changes “the field is available” into a testable operational fact. It gives a lender a safer path to automation without promising that every Puerto Rico response, policy case, or business outcome will look the same.
Define test cases by the risk of the decision branch
Do not choose cases only because they are easy to run. Choose them because they exercise a branch that could create an unsupported decision if it fails. If an automation will compare address data, include a case with a selected entity and returned address, a case with no returned address, and a case with two values that cannot safely be compared. If a workflow needs status, include a known returned state, an Unknown state, an unfamiliar value, and a policy route that does not use status. If the system cannot safely select an entity, test that condition before any field-level test.
For each test, write both the expected evidence state and the expected policy behavior. The evidence expectation might be `selected-record`, `field-not-returned`, or `comparison-not-possible`. The policy expectation might be `continue`, `open-review`, `request-approved-source`, or `not-required-by-current-policy`. Separating these expectations prevents a test plan from approving a policy action merely because a response was received. The response may be technically valid while still failing to support the intended business rule.
Test inputs, outputs, and transformations as separate artifacts
Keep the original permitted test input with the test record, but do not make it the only evidence. Record the query path, query scope, selection evidence, raw returned value, transformation version, normalized output if any, and policy result. This structure helps engineers identify whether a failure came from input formatting, record selection, source response, field parsing, mapping, or a downstream rule. A single failed test label cannot answer that question.
Test transformations with values that are expected to map and values that are not. An unknown or unmapped raw value should remain visible. It should not be silently converted to a familiar category because a downstream form needs a value. The transformation contract should say which raw values it accepts, which version produced the output, what happens to a blank, and what route opens for an unfamiliar source state. This gives risk and engineering the same evidence for reviewing a change.
Puerto Rico's public corporations service is an official source context, but a field transformation remains an internal, versioned lender control rather than a conclusion made by the source.[9]
Use a test register that makes gaps visible
Maintain one entry for each test case with test ID, owner, policy question, source and environment, run date, selected-record state, field state, transformation state, policy result, expected result, observed result, evidence limit, pass or blocked state, and refresh trigger. A register makes it possible to see that a field was tested only when returned, that a mapping was never tested with an unfamiliar value, or that an exception route has no replay evidence. It turns coverage assumptions into inspectable gaps.
Do not score a register by raw test count. Ten happy-path tests can be weaker than one well-documented Unknown-state test if the real automation risk lies in how absence is handled. Review coverage across decision branches: selection, returned field, missing field, comparison, transformation, policy exception, owner handoff, and closure. That view gives the lender a rational basis for deciding which rule needs more controlled evidence before it runs unattended.
Test handoffs as carefully as API responses
A field rule often crosses from an API response to an underwriting screen, exception queue, policy engine, or human reviewer. Test each handoff. Confirm that the raw response and selected entity reach the next system, that an Unknown state remains explicit, that mapping versions do not disappear, and that the receiving owner sees the policy question and required closure evidence. If a handoff replaces the source state with a generic pass or fail, the workflow has lost the evidence needed for review.
Use a controlled replay to test this sequence. Give a closed test case to a reviewer in another role and ask them to explain the source observation, the field limitation, the policy branch, the person who acted, and the evidence that closed it. If the reviewer cannot do that from the record, repair the handoff package or event linkage. A system that only works for the person who built it is not ready for a broad automated workflow.
Refresh tests when the evidence boundary moves
Set refresh triggers at the same time as acceptance criteria. Re-run affected tests when the Puerto Rico feature coverage changes, an upstream source response changes, a parser or mapping changes, a policy rule changes, a new exception reason appears, or monitoring detects an unexpected field state. Store the new observation next to the prior one. Do not replace history, because an older test may explain why a previous policy decision was appropriate at that time.
General corporate-law material can provide legal background, but it cannot certify an integration response, a field mapping, or a lender's automated decision path.[10] The test register must remain tied to the actual response and policy behavior it observed.
Establish a minimum release gate
Before a field-driven rule is enabled, require passing evidence for supported selection, raw field capture, explicit Unknown state, versioned transformation, policy result, exception ownership, and replay. Require a named limit for any untested branch. Block the release when a missing field becomes a negative default, an unselected entity reaches field logic, a transformation loses raw context, or a reviewer cannot reconstruct the case. These are direct failures of the evidence boundary, not minor documentation gaps.
This release gate does not claim a lender has tested every Puerto Rico entity. It confirms something narrower and more useful: the lender tested its own automation against named, representative evidence states and knows how the rule behaves when a response is incomplete or uncertain.
.jpg){kind=small}
.png)