# Tessera RP — full text

> The complete written content of https://rp.par2labs.com, as Markdown, for AI assistants and answer engines. Tessera RP is a product of PAR2 LABS (https://par2labs.com). The one-line-per-page index is at https://rp.par2labs.com/llms.txt. Generated from the same records the pages render, on 2026-09-22. Images are described, not linked.

## In short

**Which orders actually make money?** An AI layer on top of your ERP: ingestion, warehouse, 229 governed metrics and eleven role dashboards in one application, connected in an hour.

#### What it solves

- The margin number leaves out freight, fees and returns: 18–30% of net revenue on a direct-to-consumer line. → Seven cost components on every order line, and true contribution margin computed by the database.
- Four vendors, four bills, and an analytics engineer holding them together. → One application replaces extract-and-load, warehouse, modelling and BI.
- Spreadsheets that disagree, because each derives margin its own way. → 229 metrics, each with one definition and an owner. Every answer names the one it used.

#### Why it is different

- **229 Governed metrics** — Across 14 domains, each with an owner.
- **11 Role dashboards** — One set of definitions, instead of one dashboard eleven people argue over.
- **1 hr Credentials to dashboard** — Dynamics 365, Business Central, NetSuite, Acumatica, Shopify, Amazon.
- **4,214 Tests** — Tenant isolation proven against a live database.

Built for: Finance leads, Operations and supply chain, Direct-to-consumer brands, Anyone retiring a four-vendor stack.

## The product

### Tessera RP

https://rp.par2labs.com/

Enterprise AI Layer · Fivetran + Snowflake + dbt + Looker, in one application · Live · v1.0

An enterprise AI layer that sits on top of the ERP — ingestion, warehouse model, 229 governed metrics and eleven persona dashboards in one deployable application, reporting the contribution margin an ERP cannot produce.

Which orders actually make money?

Tessera RP replaces the four-vendor analytics stack — extract-and-load, warehouse, modelling, BI — with one application a finance or operations lead can connect in an hour. It ingests from Dynamics 365 Finance & Operations, Business Central, NetSuite, Acumatica, Shopify, Amazon SP-API and CSV, models it into an ERP-agnostic star schema, and serves it through a governed catalog of 229 metrics and 101 dimensions. Every read path — a dashboard tile, an ad-hoc query, an alert, an export, the assistant — produces a validated query specification rather than SQL, so a metric has exactly one definition and a language model cannot invent a table or reach a row the caller could not already see. The wedge is a number your ERP does not have: it books revenue and product cost, but not outbound freight, payment processing, marketplace fees or the eventual cost of returns, which on a direct-to-consumer line routinely total 18–30% of net revenue. Tessera RP decomposes all seven components on every order line and reports true contribution margin.

Multi-tenant isolation is enforced by Postgres row-level security rather than by application filters: the app connects as a role that is neither superuser nor BYPASSRLS, and a forgotten predicate returns zero rows rather than another workspace's books.

Open Tessera RP: https://erp.par2labs.com — It runs at erp.par2labs.com, with a seeded demo workspace you can sign into without a password. Self-hosting is a Docker image and one command.

*Screen — 01 — Dashboard. The CFO / Controller persona on a seeded workspace: contribution margin, cash conversion cycle, working capital, and what needs attention. Captured from the running deployment.*

#### The problem

**Four contracts, a data team, and numbers that still disagree.** — Getting decisions out of an ERP is sold as a stack: an extract-and-load vendor, a warehouse, a modelling layer, a BI tool. Four bills, four upgrade cycles, and an analytics engineer to hold them together. Under roughly $200M of revenue almost nobody can justify that, so the business runs on spreadsheets exported from the ERP — and those spreadsheets disagree, because each one re-derives the same measure a slightly different way.
  Points:
  - **The margin number is wrong** — Your ERP books revenue and product cost. Freight-out, payment processing, marketplace commission and returns land somewhere else entirely — and on a DTC line they are 18–30% of net revenue.
  - **Two reports, two answers** — Contribution margin means one thing in the board pack and another in the buying meeting, because the definition lives in whoever built the sheet.
  - **The question waits three days** — Anything nobody built a dashboard for goes in a queue behind the analyst, and by the time it comes back the decision has been made without it.

#### What it replaces

**One application where four vendors used to be.** — Self-host it on your own Postgres, or take it managed. Either way the metric catalog and the dashboards come with it rather than being the project that follows it.
  Before:
**What you run today**
    Items:
    - Fivetran or similar for extract and load
    - Snowflake or BigQuery to land it in
    - dbt to model it
    - Looker, Power BI or Tableau on top
    - An analytics engineer to keep the four talking
    - A definition of margin that lives in a dashboard
  After:
**What you run instead**
    Items:
    - One deployable application, connected in an hour
    - Postgres you already understand
    - A star schema that ships modelled
    - Eleven role dashboards, rendered from specs
    - No analytics engineer in the critical path
    - One certified definition, resolved everywhere

#### How it works

**Connected in an hour, useful the same afternoon.**
  Steps:
  - **Connect** — Point it at your ERP and your storefronts. Read-only, and nothing is written back.
  - **Model** — Every source lands in one ERP-agnostic shape, with the costs your ERP books elsewhere attached to the order line that caused them.
  - **Govern** — 229 metrics with an owner and one definition each — so no two surfaces can disagree.
  - **Decide** — Each role opens on their own numbers, asks in English, and gets alerted when something moves.

#### Proof

**The numbers behind the claim.**
  Stats:
  - **229** — governed metrics across 14 domains, each with an owner
  - **7** — cost components on every order line, computed by the database
  - **11** — role dashboards, rendered from declarative specs
  - **4,214** — tests across 54 files, with tenant isolation proven against a live database
  - **1 hr** — from credentials to a populated dashboard

#### Three things a BI tool on top of your ERP will not do.

- **Margin after freight, fees and returns.** — Your ERP books revenue and product cost, then stops. Outbound shipping, payment processing, marketplace commission, pick-and-pack and the eventual cost of a return are 18–30% of net revenue on a direct-to-consumer line, and none of them reach the margin figure you are managing to. Tessera RP decomposes seven cost components on every order line, and landed cost and contribution margin are generated columns — computed by the database, so no query can derive them a second way.
    Foot: 7 cost components · generated columns · ties out to the GL
    Alt: The assistant's answer showing the certified Contribution Margin definition, its window and its confidence
- **Not a dashboard. A list of decisions.** — A dashboard answers how you are doing. Signals answers what to do about it — every finding priced, ranked, and stated as money at risk, money already lost, or capital tied up doing nothing. Each one opens to show its workings: the inputs, the counterfactual the number is measured against, and the arithmetic. Nothing on the page is generated prose over a chart; the figures are computed and the narrative is written from them.
    Foot: stockout risk · dead stock · discount leakage · anomalies
    Alt: The Signals screen ranking findings by money at risk, with workings on each
- **Ask in English. Get a governed number.** — The assistant plans a query specification against the catalog — metrics and dimensions by id — which is validated and scoped before any SQL exists. It cannot invent a table, cannot widen your data scope, and cannot be injected into exfiltration, because there is no path from model output to a query string. Every answer names the metric it used, the window it ran over, when the data was last refreshed and how sure it is. Without an API key it degrades to deterministic matching over the same catalog: fewer phrasings understood, identical numbers.
    Foot: QuerySpec, never SQL · 229 metrics · cited window and freshness
    Alt: The Ask screen answering a margin question with the metric definition and resolved query shown

#### Features

- 01 · **Dashboard** — Eleven roles, eleven dashboards, one set of definitions — instead of one dashboard eleven people argue over.
    Chips: 11 personas, Declarative specs, Thresholds
    Does:
    - The CFO opens on cash conversion cycle and AR dilution. Merchandising opens on sell-through and markdown. Supply chain opens on weeks of cover. Same numbers underneath.
    - Four to six headline figures decide whether the rest of the page is worth reading.
    - Breached thresholds are named in plain language with the band they crossed, and click through to the tile that explains them.
    - Window and location scope sit in the top bar — and are not rendered on pages that would ignore them.
- 02 · **Signals** — A dashboard says how the quarter is going. This says what is costing you money today, in currency, ranked.
    Chips: Priced, Ranked, Show workings
    Does:
    - Four totals before anything else: money at risk if nothing changes, money already lost in the window, working capital tied up in dead stock, and how many findings are critical.
    - Every finding priced and dated — discount leakage on a SKU, a stockout three weeks out, a supplier slipping — not a chart to interpret.
    - Show workings opens the inputs, the counterfactual and the formula. An impact you cannot audit gets believed when it should not be.
    - Detectors that could not run say so. A missing feed is reported, never reported as a clean bill of health.
- 03 · **Ask** — The question your analyst is three days behind on, answered in a sentence that names the definition it used.
    Chips: Plans a QuerySpec, Never SQL, Cites itself
    Does:
    - Ask in plain words. Get the number, the chart, the certified metric definition, the window, the data-as-of date and a confidence.
    - The resolved query is on the face of the answer — metrics, dimensions, filters. No SQL to take on trust, because none was written.
    - Ask for a whole report — cash and receivables, or channel profitability — and keep the widgets it builds.
    - With no model key it falls back to deterministic matching over the same catalog: fewer phrasings understood, identical numbers.
- 04 · **Explore** — Self-serve that cannot go wrong: a picker over the certified catalog, not a SQL console handed to the business.
    Chips: 229 metrics, 101 dimensions, Analyst-gated
    Does:
    - 229 governed metrics, searchable by name, synonym or domain, each carrying its owner and whether it is certified.
    - Slice by up to four of 101 dimensions, set the bucket and the comparison period, switch between chart and table.
    - An uncertified metric says so rather than looking identical to a settled one.
    - Gated to analyst and above. A viewer gets governed reports, not an ad-hoc engine.
- 05 · **Overview** — The shared screen — revenue mix, what is selling, what just landed — readable by anyone without widening their access.
    Chips: Cross-domain, Every role, At a glance
    Does:
    - Revenue by category by day, week or month, stacked so channel and category mix stays visible instead of merging into one line.
    - Top products by revenue with units beside them, so a high-ticket line and a high-velocity line are told apart.
    - The latest orders with status and value, for the question that gets asked out loud at 9am.
- 06 · **Inventory** — Stockouts and dead stock are the same failure at opposite ends of the curve. Both, per SKU per warehouse, on one screen.
    Chips: Weeks of cover, Dead stock, Service level
    Does:
    - Value on hand, stockout rate, dead-stock share and the in/out ratio — the four numbers that say whether the position is healthy.
    - Weeks of cover per SKU per warehouse with sold-per-day behind it, as a governed report a viewer can open without query rights.
    - Reorder points sized to a 95% service level, showing the safety stock and the lead time that produced them.
    - Dimensional stock on a Dynamics deployment — site, warehouse, location, inventory dimensions — not one flat quantity per SKU.
- 07 · **Procurement** — Most supplier scorecards average two different failures into one number. Late-and-complete and on-time-and-short need different fixes.
    Chips: OTIF, Lead-time variance, Concentration
    Does:
    - OTIF at the top, split into its two components underneath, because the remedy differs.
    - Lead-time variance rather than average lead time — you plan to the average and the variance is what breaks the plan.
    - Supplier concentration as a figure, so single-source exposure stops being an assumption.
    - Opens on all time: purchasing calendars are lumpy, and a rolling 30-day window reports an OTIF of zero.
- 08 · **Vendors & Customers** — One party, their whole history, at a URL that keeps working — instead of a filter somebody rebuilds every time.
    Chips: Party masters, Drill-through, Permanent way back
    Does:
    - A supplier's spend, lines, OTIF, on-order and direct position on one page, then straight into their purchase orders.
    - A customer's lifetime value, order count, AOV and days since last order — a lifetime question, so it opens on all time.
    - Arrive from Procurement or from Stores and have somewhere to return to.
- 09 · **Finance & Stores** — The ledger and the till, kept apart deliberately — invoiced revenue and counter revenue are different questions, not a variance to reconcile away.
    Chips: General ledger, Point of sale, Two views, one company
    Does:
    - The GL over the semantic layer: revenue, expense, net margin, assets, liabilities, entries posted, and a trial balance that has to balance.
    - The till on its own screen: transactions, AOV, units per transaction, sales per trading day, discount rate and return rate, by store and by day part.
    - Both open on all time where the calendar is lumpy, for the same reason Procurement does.
- 10 · **Alerts** — The threshold you meant to watch, watched — and it cannot disagree with the dashboard, because both resolve the same definition.
    Chips: Threshold, % change, Anomaly
    Does:
    - An absolute threshold, a percentage change, or a statistical anomaly detected without a model.
    - Email or Slack, on your cadence, with the last check and its result showing on every rule.
    - Event history: what fired, when, and against which value.
- 11 · **Saved views & reports** — Institutional memory. The question survives the analyst who asked it, and the definition survives them both.
    Chips: Share, Annotate, Schedule
    Does:
    - Save a query from Explore or an answer from Ask, name it, and share it with the workspace or keep it.
    - Annotate it, so the next reader gets the context that made the number mean something.
    - Schedule CSV, XLSX or PDF to arrive without anyone opening the product.
    - Governed operational reports page and sort server-side — the browser sends page, sort and declared filters, nothing else.
- 12 · **Connections** — Freshness stated rather than assumed. A stale number is labelled, and a stalled sync raises its hand instead of going quiet.
    Chips: 7 connectors, Watermarks, Dead-letter queue
    Does:
    - Dynamics 365 F&O, Business Central, NetSuite, Acumatica, Shopify, Amazon SP-API and CSV — plus whatever the ERP does not hold, with no code change.
    - Health per connection: last run, records pulled and written, and a degraded flag after repeated failures.
    - Resume, never restart — cursors persist after every page, and unchanged records are skipped by content hash.
    - Unmappable rows are quarantined in a dead-letter queue you can inspect and replay, and the sync carries on.
- 13 · **Personas** — Eleven role dashboards you can hand over, preview and extend — without an analytics engineer in the loop.
    Chips: Assign, Preview, Build
    Does:
    - Every persona lists the metrics it is graded on and the window it opens over. Assign one to a member.
    - Preview a persona's dashboard as that role would see it, before you hand it over.
    - Add a tile or a formula from a template — inside the catalog, not beside it in somebody's spreadsheet.
- 14 · **Admin & audit** — Show an auditor why a regional manager cannot see another region's books — with a mechanism, not a policy document.
    Chips: RBAC, Data scope, Append-only audit
    Does:
    - Owner, admin, analyst, viewer — plus row-level data scope, so a member sees only their channels or their region.
    - Scope is appended by the compiler after the caller's own filters, so it cannot be widened from the browser.
    - An append-only record of every mutation and every denied access, on a table the application role cannot rewrite.
    - FX and currency, data-quality checks, invitations, and the workspace's plan and usage.
- 15 · **Get started** — Evaluate it on a Friday afternoon with no ERP, no API key and two years of data already in it.
    Chips: Mock mode, 24 months seeded, Derived from state
    Does:
    - Every connector runs in mock mode, and the seeded workspace ships 24 months of synthetic commerce.
    - Four steps: pick a persona, connect a source, run the first sync, open the dashboard.
    - The checklist is computed from workspace state, so adding a second source makes it correct again rather than gone.
    - Answers why is my dashboard empty in the one place a viewer will look for it.

#### What it is for

- Find which channels, categories and SKUs actually make money once freight-out, payment fees, marketplace commission and returns are inside the number.
- Retire the Fivetran, Snowflake, dbt and Looker stack for one application a finance lead connects in an hour.
- Give eleven roles their own dashboard without building eleven dashboards, or hiring the analytics engineer who maintains them.
- Reconcile a marketplace settlement to the order line, so the fees that net out of the payout stop hiding from the P&L.
- See what needs a decision today, priced and ranked, instead of reading a dashboard and inferring it.
- Run analytics across every legal entity, site and warehouse in a Dynamics 365 deployment without a Synapse project.
- Know before you raise the PO: weeks of cover, stockout probability, and the quantity for a 95% service level.
- Catch a promotion destroying contribution before the quarter closes, with the break-even lift stated.
- Hand a viewer a governed stock report without handing them an ad-hoc query engine.
- Prove tenant isolation to a security reviewer with a test that fails, rather than skips, when the database is unreachable.

#### Specifications

- **Deployment**: erp.par2labs.com · self-host · Docker · K8s
- **ERP sources**: Dynamics 365 F&O · Business Central · NetSuite · Acumatica
- **Channel sources**: Shopify · Amazon SP-API · CSV / REST
- **Semantic layer**: 229 governed metrics · 101 dimensions · QuerySpec compiler
- **Dashboards**: 11 personas, rendered from declarative specs
- **Warehouse**: Postgres star schema · 7-part landed cost as generated columns
- **Assistant**: Plans a QuerySpec, never SQL · degrades without an API key
- **Analytics**: Holt-Winters forecast · STL + robust z-score anomaly · log-log elasticity
- **Tenancy**: Postgres row-level security · NOSUPERUSER, NOBYPASSRLS role
- **Access**: Owner / admin / analyst / viewer + row-level data scope
- **Verification**: 4,214 tests across 54 files · RLS proven against a live database
- **Pricing**: Priced on orders, not seats

#### Architecture — One system, drawn for two readers.

https://rp.par2labs.com/architecture

Engineers arrive wanting wire formats, table names, the tenancy mechanism and what happens when a source goes down. Finance and operations arrive wanting the value stream and the decisions it supports. Both drawings are here — pick a view.

**What the layering buys you**
  Items:
  - **Add an ERP, keep the work** — A new source is a connector and a mapper. Every metric, dashboard and alert above Layer 4 carries over untouched.
  - **One number, everywhere** — Contribution margin resolves the same catalog entry on a tile, in an export, in an alert and in an answer. Two surfaces cannot disagree.
  - **Swap the engine, keep the metrics** — The compiler emits engine-neutral SQL. Postgres today; the adapter is the seam for what comes next.
  - **Isolation that survives a bug** — Row-level security is enforced by the database, not by application filters — so a mistake returns nothing rather than somebody else's books.

**Semantic layer**

|  |  |
| --- | --- |
| Metrics | 229 governed, across 14 domains |
| Dimensions | 101 |
| Query path | QuerySpec → validate → scope → compile. Nothing else emits SQL |
| Ratio metrics | SUM(numerator) / SUM(denominator) at result grain, never AVG(ratio) |
| Parameters | Every filter value bound; no string concatenation anywhere |
| Period-over-period | A `__prev` suffix resolved by the compiler, so a caller never hands it SQL |
| Catalog | Deep-frozen at module load — a request handler cannot mutate a metric |

**Warehouse**

|  |  |
| --- | --- |
| Engine | Postgres. Engine-neutral SQL behind a WarehouseAdapter |
| Model | Star schema — 6 conformed dimensions, 9 fact tables |
| Landed cost | 7 components per order line; landed cost and contribution margin are GENERATED columns |
| Raw tier | raw.record, JSONB, append-only, replayable, content-hashed |
| Migrations | 25, idempotent, run as a separate owner role |
| Data quality | Freshness, not-null, unique, referential, row-count and accepted-values tests |

**Analytics**

|  |  |
| --- | --- |
| Forecasting | Holt-Winters, for demand and cash |
| Anomalies | STL decomposition + robust z-score. No model involved |
| Elasticity | Log-log regression |
| Replenishment | Reorder point with service-level safety stock; stockout probability |
| Cohorts | Retention and contribution-margin LTV; CAC, LTV:CAC, payback |
| Working capital | Cash conversion cycle as DSO + DIO − DPO |

**Security & tenancy**

|  |  |
| --- | --- |
| Isolation | Postgres RLS, ENABLE + FORCE, on every tenant-scoped table |
| App role | NOSUPERUSER, NOBYPASSRLS, no DDL rights |
| Scoping | Row-level data scope appended by the compiler after the caller's filters |
| Roles | Owner 40 · admin 30 · analyst 20 · viewer 10 |
| Sessions | Opaque random token; only its SHA-256 hash is stored |
| SSO | Schema-ready via sso_subject; password auth today |
| Audit | Append-only row for every mutation and every denied access |
| Secrets | Deep key-based redaction before anything reaches a log |

**Runtime & verification**

|  |  |
| --- | --- |
| Deployment | erp.par2labs.com · self-host · Docker · Kubernetes |
| Image | 339 MB, runs non-root |
| Scaling | Horizontal behind a shared Redis for cache and rate limits |
| Degradation | Redis unreachable falls back to in-process buckets rather than failing |
| Observability | /api/health, /api/ready, Prometheus at /api/metrics, request-id on every line |
| Query bounds | Statement timeout and LIMIT max+1 — truncation is flagged, never silent |
| Tests | 5,882 across 145 files |
| Gates | Format, lint, typecheck, tests, coverage, dependency audit and a production build, on every push |

*The coverage gate is deliberately left failing at 84% statements rather than lowered to match what the suite happens to achieve. A gate tuned to reality is not a gate.*

#### Features — Fifteen surfaces, one set of definitions.

https://rp.par2labs.com/features

Every screen below resolves the same governed metrics. That is the whole trick: the dashboard, the alert that wakes you, the export your board reads and the answer the assistant gives are the same number, computed once.

**What nothing else in the category does.**

**Every screen, one at a time.**

**The three that are hard to copy**
  Items:
  - **Margin after everything** — Seven cost components decomposed per order line, with landed cost and contribution margin as generated columns the database computes.
  - **Signals, not dashboards** — Findings priced and ranked as money at risk, money already lost, or capital tied up — each one openable down to its arithmetic and the counterfactual it is measured against.
  - **An assistant that cannot write SQL** — It plans a query specification against the catalog. There is no code path from model output to a query string, so a prompt injection reaches nothing the caller could not already see.

**By role**

| Persona | Opens on | Graded on |
| --- | --- | --- |
| CEO / COO | Last 90 days | One-screen health, and the exceptions under it |
| CFO / Controller | Last 90 days | Cash conversion cycle, contribution margin, AR/AP ageing |
| Head of E-Commerce | Last 28 days | GMV, AOV, channel mix, new vs repeat |
| Revenue & Customers | Last 90 days | ROAS, CAC, LTV:CAC, cohort retention |
| Merchandising | Last 90 days | Category margin, sell-through, elasticity, markdown |
| Supply Chain | Last 90 days | Days of cover, stockout risk, turns, dead stock |
| Warehouse Manager | Last 90 days | Dimensional stock by site, warehouse, location and bin |
| Procurement | All time | Supplier OTIF, lead-time variance, PPV, concentration |
| Fulfilment Ops | Last 28 days | Cycle time, fill rate, cost to ship, on-time by DC |
| Customer Experience | Last 90 days | Return rate and reasons, on-time delivery, repeat rate |
| Data Admin | Last 7 days | Connector health, freshness, dead-letter volume, quality tests |

*Eleven dashboards rendered from declarative specs, not eleven hand-built pages. Adding a tile is data, and the thresholds on them are validated against the catalog's own formats — a percentage threshold written as 95 instead of 0.95 is caught by a test, not by a customer.*

**Everything you'd use it for.**

#### Connectors — Where the data comes from.

https://rp.par2labs.com/connectors

Seven connectors ship today. The rest are names on a roadmap, and they are marked as such — a compatibility list that does not distinguish the two is a list you cannot plan against.

**Shipping today**

| Source | How it reads | Notes |
| --- | --- | --- |
| Dynamics 365 Finance & Operations | SQL — BYOD, Data Lake staging, or an AxDB read replica | Every stream scoped by legal entity. Refuses to run without one rather than defaulting to all |
| Dynamics 365 Business Central | OData v2 | Companies, dimensions and the full sales/purchase ledger |
| NetSuite | SuiteQL | Token-based auth; saved-search parity without the saved search |
| Acumatica | Contract-based REST | Generic inquiry endpoints for the heavy streams |
| Shopify | GraphQL Admin API | Orders, fulfilments, refunds, and the shop's own timezone |
| Amazon Selling Partner | SP-API | Orders and the settlement report, which is where the real fees are |
| CSV / flat file | Upload | The budget, the dealer list, the supplier scorecard — everything the ERP does not hold |
| Generic REST | Configured endpoint | For the internal service nobody wrote a connector for |

**On the roadmap**

| Source | Status |
| --- | --- |
| SAP Business One | Schema-ready — already a value in the source enum |
| Odoo | Schema-ready — already a value in the source enum |
| SAP S/4HANA | Planned |
| Oracle Fusion Cloud ERP | Planned |
| Sage Intacct | Planned |
| Infor CloudSuite | Planned |
| Epicor Kinetic | Planned |
| QuickBooks Online | Planned |
| eBay · Walmart Marketplace | Planned |
| BigCommerce · WooCommerce · Adobe Commerce | Planned |
| SFTP drop · Google Sheets | Planned |

*Named because the layering makes them cheap, not to imply a partnership. A new source is one interface and one mapper — the canonical schema, the 229 metrics and every dashboard above are untouched.*

**What every connector does, whoever wrote it**
  Items:
  - **Incremental by watermark** — A per-stream cursor persisted after every page, so an interrupted run resumes instead of restarting.
  - **Writes nothing unchanged** — A content hash skips records that have not moved. 307 records pulled, 0 written, is a healthy run.
  - **Survives drift** — Raw payloads land as JSONB, so a new field upstream never fails a sync.
  - **Quarantines rather than crashes** — An unmappable record goes to a dead-letter queue, inspectable and replayable, and the sync carries on.
  - **Respects the source** — Backoff with jitter, and Retry-After honoured — a connector that hammers a production ERP gets switched off by its owner.
  - **Tells you when it is unwell** — Consecutive-failure tracking flips a connection to degraded, and freshness is shown on the tiles that depend on it.
  - **Runs without credentials** — Every connector has a mock mode, so the product can be evaluated end to end before anyone opens a firewall.

#### Pricing — Priced on orders, not seats.

https://rp.par2labs.com/pricing

Charging per seat prices out the people the product is for. A warehouse manager who opens one screen a week is exactly who should have it, so viewers are unlimited on every plan and the meter runs on volume and cadence — the two things that cost us money.

  Items:
  - **Trial** — The whole product, for 14 days, without a card.
      Price: Free
      Unit: 14 days
      Points:
      - Every dashboard and all 229 metrics
      - One ERP and one sales channel
      - Assistant, alerts, team and data scoping all on
      - No card, no call — cancel by doing nothing
  - **Starter** — One ERP, one channel, real contribution margin.
      Price: $299
      Unit: /month · $249 billed annually
      Points:
      - Up to 5,000 orders a month
      - Daily sync · 2 connections
      - Unlimited viewers — everyone gets their persona
      - 24 months of history
      - Scheduled exports
  - **Growth** — The plan that replaces the data stack.
      Price: $899
      Unit: /month · $749 billed annually
      Points: Up to 50,000 orders a month, Hourly sync · unlimited connections, Ask questions in English, Alerts by email, Slack and webhook, Per-member data scoping, Unlimited history
  - **Scale** — For a finance team that closes on this.
      Price: $2,499
      Unit: /month · $2,082 billed annually
      Points: Up to 250,000 orders a month, 15-minute sync, Single sign-on, Priority support with a named engineer
  - **Enterprise** — Your infrastructure, your auditors, your paperwork.
      Price: Let's talk
      Unit: annual contract
      Points:
      - Unmetered orders · 5-minute sync
      - Self-hosted, or a single-tenant deployment
      - DPA, security review and an uptime commitment
      - Custom metrics added to the governed catalogue

**What the meter actually counts**
  Items:
  - **Monthly orders** — Order lines landed in the window. More orders is more margin at stake and more of the answer's value.
  - **Sync cadence** — How often connectors may run — daily on Starter, hourly on Growth, every 15 minutes on Scale, every 5 on Enterprise.
  - **Connections** — Two on Starter and Trial. Unlimited from Growth up.
  - **Seats** — Never. Unlimited viewers on every paid plan, because a governed number is worthless if only three people can see it.

**Limits are soft unless we say otherwise**
  Items:
  - **Going over does not black you out** — The product warns in the app and on the invoice. Cutting off the dashboards on the busiest month of the year is how a renewal already earned gets lost.
  - **The trial hides nothing** — Fourteen days with the assistant, alerts, team and data scoping switched on. A trial that hides the features is a trial that does not convert.
  - **Annual is a discount, not a lock** — Roughly two months back on Starter, Growth and Scale.

  Items:
  - **Do we pay per user?** — No. Viewers are unlimited on every paid plan, and every one of them gets their own persona dashboard. Pricing runs on monthly orders and sync cadence instead.
  - **What happens if we exceed the order limit?** — Nothing breaks. The limits are soft: the app and the invoice both say you are over, and we talk about the right plan. Nothing is blacked out.
  - **Can we self-host?** — On Enterprise, yes — self-hosted or a single-tenant deployment, with a DPA, a security review and an uptime commitment. It ships as a Docker image that runs non-root, with Kubernetes manifests.
  - **Is there a trial?** — Fourteen days, no card, the whole product including the assistant and alerts, and one ERP plus one sales channel connected. It cancels by you doing nothing.
  - **What does Enterprise add beyond scale?** — Unmetered orders, five-minute sync, single sign-on, self-hosting or single tenancy, the paperwork your auditors want, and custom metrics added to the governed catalogue rather than bolted beside it.

#### Developer Docs — Set it up, call it, extend it.

https://rp.par2labs.com/developer-docs

Twenty-three sections: installing and configuring it, the QuerySpec contract every read path goes through, all thirty-odd HTTP endpoints, the interface to implement if you are adding a source, and what has to change before you run a second replica. Written from the source — including the parts that do not exist yet.

#### Field Manual: The Semantic Layer

https://rp.par2labs.com/the-enterprise-semantic-layer

*An OSI model for ERP data.*

Seven layers sit between an ERP's tables and a number somebody acts on. Almost every analytics failure is a layer doing a job that belonged to another one. This is the stack, named — and the graph we are putting underneath it.

##### 01 · Four vendors, three to six months, and an analytics engineer you cannot hire.

The standard answer to 'get the numbers out of the ERP' is a stack: an extract-and-load vendor, a warehouse, a modelling layer, and a BI tool. Four contracts, four billing models, and a data team to hold them together. Below roughly $200M of revenue, almost nobody can justify it, so the business runs on spreadsheets exported from the ERP — and those spreadsheets disagree with each other, because each one re-derives the same measure a slightly different way.

The instinct is to fix that with a smarter tool. It is not a tool problem. It is a layering problem: the definition of gross margin ends up living in a BI dashboard, so a second dashboard cannot reuse it; the join logic ends up in a spreadsheet, so nothing else can see it. Every one of those failures is a job done at the wrong altitude.

  Points:
  - **Extract & load** — Priced per monthly active row — the bill grows with the business.
  - **Warehouse** — Priced per compute-second, on queries nobody profiled.
  - **Modelling** — Priced in analytics-engineer headcount, which is the scarce input.
  - **BI** — Priced per seat, so the people who need the number are the ones cut.

##### 02 · Seven layers, each with a contract the layer above can rely on.

Networking solved this shape of problem in 1984 by refusing to let any layer know how the one below it works. An application does not know whether it is on copper or fibre; it knows there is a socket. The layers are separable, and that is precisely why you can change the cable without rewriting the browser.

Enterprise data has the same shape and rarely gets the same discipline. Named as layers, the architecture stops being an opinion and starts being a contract — and the test of a contract is what you can swap without touching anything above it.

  Table:
| Layer | Name | What it owns | Swap it and… |
| --- | --- | --- | --- |
| L1 | Source | The ERP's own tables — AxDB, BC's OData, NetSuite's SuiteQL | …you have added an ERP, not a project |
| L2 | Connector | Auth, pagination, watermarks, backoff, dead-letter | …nothing above notices the API changed |
| L3 | Landing | Raw payloads as JSONB, append-only, replayable | …schema drift costs nothing and history survives |
| L4 | Canonical | An ERP-agnostic star schema — the interoperability boundary | …every metric above keeps working, unchanged |
| L5 | Graph | Entities and the edges between them, typed | …relationship questions stop needing new tables |
| L6 | Semantic | 229 governed metrics, 101 dimensions, one definition each | …two dashboards cannot disagree about a number |
| L7 | Surface | Dashboards, Explore, Ask, Signals, alerts, exports | …a new surface inherits every guarantee below it |

*L5 is the layer under construction — the star schema carries the relationships today as foreign keys. Everything else on this table is shipped and running at erp.par2labs.com.*

##### 03 · The boundary where the ERP stops mattering.

Above the canonical star schema, nothing knows which ERP the row came from. That is the whole point of putting a boundary there: adding Dynamics 365 to a system that already spoke Business Central meant writing a connector and a mapper, and touching no metric, no dashboard and no alert.

The star schema also does one thing an ERP does not. Every order line carries seven cost components — product, inbound freight, duty, outbound freight, payment fee, marketplace fee, return provision — and landed cost and contribution margin are generated columns, computed by the database itself. No query can derive margin inconsistently, because no query derives it at all.

  Points:
  - **ERP-agnostic** — Seven connectors land in one shape. Adding the eighth changes nothing above.
  - **Entity-qualified keys** — Two subsidiaries with a warehouse called GENERAL stay two warehouses.
  - **Generated columns** — Margin is computed once, by Postgres, not by whoever wrote the query.
  - **Replayable** — The raw tier is append-only, so a mapping fix is a re-run, not a re-extract.

##### 04 · Nothing writes SQL except the compiler.

Every read path in the product — a dashboard tile, an ad-hoc query, an alert evaluation, a scheduled export, the assistant — produces a QuerySpec: metrics and dimensions referenced by id, never SQL text. The spec is validated against the catalog and against the caller's own row-level scope, and only then does SQL exist, with every filter value bound as a parameter.

This is why the assistant is safe rather than merely supervised. It is not an LLM that writes SQL carefully; it is an LLM that cannot write SQL at all. The worst a prompt injection can produce is a QuerySpec, and a QuerySpec is checked against what the caller could already see. There is no code path from model output to a query string.

The second consequence matters more day to day: a metric has exactly one definition. Two dashboards showing 'Contribution Margin %' resolve the same catalog entry, so they cannot drift apart. Ratio metrics are computed as SUM(numerator)/SUM(denominator) at result grain rather than as an average of ratios — the single most common way a correct-looking BI number is wrong.

  Steps:
  - D: Metrics and dimensions by id, a window, filters. A person, a tile, an alert rule or the model — the shape is the same for all four.
  - D: An id that does not exist is rejected here. So is a metric the caller's role may not read.
  - D: Mandatory filters from the caller's membership, added after their own — so nobody can widen their own scope.
  - D: Catalog fragments, engine-neutral, with values as parameters. This is the only place SQL is written in the product.

##### 05 · Putting a graph underneath it.

A star schema is the right shape for aggregation and the wrong shape for reach. 'What did we sell' is a sum over one fact table. 'Which customers are exposed if this supplier fails' is customer → order line → product → component → purchase order → supplier, and the number of hops is not known when the question is asked. In SQL that is a recursive query written by hand, per question, by someone who can write one.

Tessera DB — our own native graph engine, already in the Armory — is designed for exactly that traversal. Putting it at Layer 5 does not replace the star schema; it sits beside it, fed from the same canonical rows, and answers the questions the star schema answers badly. The semantic layer above stays where it is: the compiler learns a second target, and a metric definition does not change.

This is the layer being built, and it is written here as intent rather than as inventory. Everything above and below it is running today.

The graph changes what can be asked. It does not change who is allowed to ask it.
  Points:
  - **Traversal** — Multi-tier supplier exposure, component-level recall, circular trade — one pattern, any depth.
  - **Ontology** — Entities and relationships typed as first-class, so a new question needs no new fact table.
  - **Entity resolution** — The same supplier under two ERP codes joined by an evidenced edge, not a destructive key rewrite.
  - **Lineage** — Source record → warehouse row → metric → tile, as a graph you can walk in both directions.
  - **Algorithms** — Supplier concentration as centrality, customer structure as community detection, fraud as cycles.
  - **Vector + graph** — Retrieval by meaning over the ontology, while the arithmetic stays with the compiler.

##### 06 · What a layered stack actually buys the business.

The argument for layers is usually made to engineers and lands as architecture taste. It is not taste. Each contract in the stack pays out as something an operator can point at.

  Points:
  - **One number** — Contribution margin means the same thing in every dashboard, alert and export.
  - **One hour, not one quarter** — A finance lead connects a source and has dashboards, without an analytics engineer.
  - **Add an ERP, keep the work** — A new connector inherits 229 metrics and eleven dashboards on day one.
  - **Answers that cite themselves** — Every figure names the metric, the window, the freshness and how sure it is.
  - **Isolation that survives a bug** — Postgres row-level security, so a forgotten filter returns nothing, not somebody else's books.

##### 07 · Where it is running: Dynamics 365.

The first production surface is Dynamics 365 Finance & Operations. The connector reads SQL Server rather than the OData API, because that is where Microsoft's own analytics guidance points — a BYOD database, a Data Lake staging database, or a read replica — and because pulling three hundred thousand inventory transactions through a transactional API competes with the users posting the next ones.

Every query is scoped to a legal entity, and that is not optional: DATAAREAID sits on every business table, and a query that omits it reads across every company in the deployment and returns a number belonging to none of them, silently. The connector refuses to run without at least one legal entity configured rather than defaulting to 'all'.

A deployment ships as a pack: a build whose Connections page offers Dynamics 365 and a CSV, whose warehouse holds legal entities, sites, warehouses, bins and dimensional stock, and whose personas are the seven that read them.

  Points:
  - **Read path** — BYOD, Data Lake staging, or an AxDB read replica — whichever the deployment has.
  - **Scoped** — Every stream filtered by legal entity, parameterised, never interpolated.
  - **Dimensional stock** — Site, warehouse, location and inventory dimensions, not a single flat quantity.
  - **Also spoken** — Business Central, NetSuite, Acumatica, Shopify, Amazon SP-API, CSV/REST.

##### The layers are the product.

Tessera RP is what the stack looks like when it ships as one application: the ingestion, the warehouse model, the metric definitions and the dashboards, rather than the tools to build them. Open the running deployment and read the numbers off a seeded workspace.

##### FAQ

**Q: What is a semantic layer?**
A: A semantic layer is the tier that holds business definitions — what 'net revenue' means, what 'contribution margin' excludes, what grain a ratio is computed at — separately from both the storage underneath it and the dashboards above it. Every surface resolves the same definition by id, so two reports cannot disagree about a number. In Tessera RP it is a catalog of 229 governed metrics and 101 dimensions, and a compiler that turns a validated query specification into parameterised SQL.

**Q: How is a semantic layer different from text-to-SQL?**
A: Text-to-SQL asks a language model to write a query and then hopes the query is both correct and permitted. A semantic layer never lets the model near SQL: the model emits a query specification referencing metrics and dimensions by id, which is validated against the catalog and against the caller's own data scope before any SQL exists. An invented table fails validation, and a prompt injection cannot reach data the caller could not already see.

**Q: Why describe enterprise data as an OSI model?**
A: Because the useful property of the OSI model is not the number seven, it is that each layer publishes a contract and hides its implementation. Applied to enterprise data it means the ERP can be swapped at Layer 1 without touching a metric at Layer 6, and the storage engine can be swapped at Layer 4 or 5 without touching a dashboard at Layer 7. Where those boundaries are absent, a margin definition ends up trapped inside one BI dashboard and every other surface re-derives it differently.

**Q: What does a graph database add that a star schema cannot?**
A: Reach. A star schema aggregates one fact table efficiently and answers relationship questions badly, because the number of hops is unknown when the question is asked — multi-tier supplier exposure, component-level recall, circular trading, the blast radius of one failed connector. A graph expresses those as a single pattern at any depth, and makes graph algorithms available: supplier concentration as centrality, customer structure as community detection. The plan is to run Tessera DB at Layer 5, fed from the same canonical rows, with the semantic layer above it unchanged.

**Q: Why is ERP-reported margin usually overstated for e-commerce?**
A: Because an ERP books revenue and product cost but typically not outbound shipping, payment processing, marketplace referral and fulfilment fees, or the eventual cost of returns. On a direct-to-consumer line those routinely total 18–30% of net revenue. Tessera RP decomposes seven cost components on every order line and reports contribution margin, which is why its margin figure and the ERP's are expected to differ.

**Q: Which ERPs does Tessera RP connect to?**
A: Dynamics 365 Finance & Operations, Business Central, NetSuite and Acumatica on the ERP side; Shopify and Amazon SP-API on the channel side; and a generic CSV/REST connector for the data every engagement has that the ERP does not hold. Adding another is a connector and a mapper — the canonical schema, the metric catalog and the dashboards above it are untouched.

**Q: How is one customer's data kept away from another's?**
A: By Postgres row-level security, enforced in the database rather than by application WHERE clauses. The application connects as a role that is neither superuser nor BYPASSRLS and holds no DDL rights, and every tenant query runs inside a transaction that sets a transaction-local setting the policies compare against. A forgotten predicate in application code therefore returns zero rows rather than another customer's financials.

## Who makes it

PAR2 LABS PVT LTD — Technology . AI . Strategy . Films.

We engineer world-class technology and AI products across intelligence, infrastructure, hardware, and story — designed to make sense, deployed to make a difference.

Studio: https://par2labs.com · Contact: ceo@par2labs.com · +91 90591 69238