DRDataRaft/ docs
GitHub ↗

Follow a real reporting problem

Explore a synthetic insurer portfolio from six related source tables to a checked lapse-rate report.

Positron

Command or action
Select R Session → Refresh Metadata → Inspect Product → Trial Product

The native workspace overview lists the six-table portfolio, its model, a channel lapse-rate product and a deliberately invalid cash feed.
The native workspace overview lists the six-table portfolio, its model, a channel lapse-rate product and a deliberately invalid cash feed. Open full-resolution screenshot ↗
The portfolio.relational_model definition identifies the six-table model; the R tests verify its primary and foreign keys.
The portfolio.relational_model definition identifies the six-table model; the R tests verify its primary and foreign keys. Open full-resolution screenshot ↗
The lapse-rate dashboard shows its column contract and named owner policy.
The lapse-rate dashboard shows its column contract and named owner policy. Open full-resolution screenshot ↗
A dry run of the channel lapse-rate product completes without publishing a release.
A dry run of the channel lapse-rate product completes without publishing a release. Open full-resolution screenshot ↗
The invalid cash delivery records one failed nonnegative_cash check among 108 payment records.
The invalid cash delivery records one failed nonnegative_cash check among 108 payment records. Open full-resolution screenshot ↗
Directed product lineage connects the monthly exposure, policy and broker definitions to the lapse-rate product.
Directed product lineage connects the monthly exposure, policy and broker definitions to the lapse-rate product. Open full-resolution screenshot ↗

The problem

A portfolio analyst needs a monthly cancellation rate by distribution channel. Customer, broker, policy, status, payment and claim data arrive in different tables. An invalid negative receipt must not slip into reporting. Months later, the analyst needs to explain the input and rules behind a rate.

The synthetic case

The versioned R example defines 18 customers, six brokers, 36 policies, 108 monthly status rows, 108 payment records and eight claims. Every table has a contract, including keys. A six-table dm model checks the relationships. Separate products add a blocked payment scenario, a channel lapse-rate calculation, a named owner policy and an output with an 08:00 UTC deadline. In March, four newly lapsed policies are measured against 33 policies exposed at the start of the month, giving 4/33 across all channels. The counts are deterministic regression expectations, not production data.

Try the native workflow

  1. Load the example into an R session and select that session in Positron.
  2. Refresh metadata and find the portfolio products in the overview.
  3. Inspect the relational model and the lapse-rate product's contract, policy, port and SLA.
  4. Trial the lapse-rate product. Inspect the completed result without publishing.
  5. Trial portfolio.invalid_cash_receipts, then select the failed nonnegative_cash check.
  6. Follow the directed lineage from the inputs to portfolio.lapse_rate_by_channel.

What the screenshots prove

The test drives the actual Positron workbench and production extension in one Ark R session. It asserts the successful and blocked result statuses, then checks that exactly one of 108 cash rows failed. The same installed example is exercised by the R package test suite for contracts, model relationships, bad deliveries and 4/33 arithmetic. The screenshots show metadata and UI state; they do not prove that an output was published or that a consumer received it.

Original capture from the native Positron extension host, using synthetic data. Extension implementation: a33652d. Screenshot automation: a33652d. Successful native capture run ↗

Search documentation

Search functions, packages and guides.