RegiaBI apps

Profile a dataset locally (no data leaves the machine): per-column types, cardinality, ranges, measure/dimension roles, temporal/ordinal detection, and cross-column signals (nesting, shared values, association). This is the same measurement engine the BIC Power BI visual uses before generating a chart.

How to build an app with these charts, from the guide this package ships. Local and free: no network, no credentials. topic 'fabric-app' (the default) is what a Microsoft Fabric App on the Rayfin data app template needs: what to pull, generating, wiring in React, the Fabric App section and the time-savers. 'all' is the whole guide, including Blazor. 'chart-shapes' lists every chart type with the columns, limits and renderers it needs. 'settings' lists the choices a person can make about a chart, with their options and defaults.

The AUTHORITATIVE list of chart types (maps, tables a reader works with and app widgets included) that can render this dataset — the server's own eligibility engine, NOT a local guess. Profiles the data locally, then sends that profile to the backend. NO LLM in the loop, but this is a NETWORK call and it is METERED — see the licensing note below. By default the tool DETECTS the project's language (JS/TS vs Python from the working dir) and returns the charts for THAT language, SCOPED and ordered by how well each type fits this data (best first; `order: 'variety'` favors newer and less-common types instead), each tagged with its source language and renderer. Pass `language` ('javascript'|'python') to force it, or `renderer` ('D3'/'PLOTLY'/…) to rank one specific renderer, or renderer '' for the full renderer-agnostic eligibility across ALL renderers (also ranked, by chart type alone, with no renderer/language tag). If the language can't be auto-detected and none is given, the tool asks you to specify one. Needs an account: eligibility IS the engine, so programmatic access to it is licensed. With nothing configured, the first call opens a browser sign-in, waits for it and then answers (a license key in the environment is the alternative for a machine with no browser). Free within a generous hourly allowance; beyond it each call draws usage credits. The reply carries a text block and a structured table: one row per chart type with its rank, name, preview flag, fit verdict, description, language and renderer. Rows flagged alsoWorthALook are a few picks from below the top fits, drawn so an offer can include something different; the fit order itself never changes. A type that fits only once the rows are totalled (raw rows where the chart wants one per category) is listed under its own heading, once per grain: each row carries the sentence that says how the rows are totalled first and that grain's projection key.

Generate ready-to-render chart code for a dataset via the BIC backend: the data shape is profiled locally, the backend picks a suitable chart type (or honors chart_type), and returns code that has passed the backend's eligibility gates and quality checks. Needs a trial or paid account: with nothing configured, the first call opens a browser sign-in, waits for it and then finishes the chart (a license key in the environment or ~/.bic/credentials.json is the alternative for a machine with no browser). The returned D3 code is a portable render(container, data, options) function meant to be MERGED into your own app; an integration contract describes exactly how to call it. A standalone HTML preview and file output are optional. The arguments chart_style, level_of_detail and culture are the person's choices, and the guide's 'settings' topic lists every choice a person can make with its options.

Shows exactly what a chart generation would send to the BIC backend for these arguments - the measured shape of your data (column names, types, counts, ranges), the settings, and whether any sample rows travel - with the credentials removed. SENDS NOTHING and needs no license: it is local and free. Takes the same arguments as a generation. It answers 'what data leaves my machine?'; the eligibility list sends a subset of the same shape.

Checks a chart request against this data before anything is generated. Takes the same arguments as a generation - the chart type and every setting (date grain, limit, overlay, required columns, rows policy, data labels and the rest) - and answers, in the server's own words, each ask this data can't honor and why: a channel the data doesn't have, too little of one for the ask, or a name the catalog doesn't know. When the chart type itself is denied, it also lists up to five chart types that fit this data, best fit first. An OK names the asks it checked. Profiles the data locally and sends that profile, as a generation would; no sample rows travel. NO LLM in the loop and no generation credits are spent, but this is a NETWORK call and it is METERED like the eligibility list: free within a generous hourly allowance, then usage credits per call. Needs an account: with nothing configured, the first call opens a browser sign-in (a license key in the environment is the alternative). The reply carries a text block and a structured result: the verdict (OK or DENY), the asks checked, each finding with its kind and reason, and the alternatives.

Verify a generated chart locally before deploying: draws the chart.js that generate_chart wrote, headless, against its data - the rows query_semantic_model saved, a CSV, or the rows it was generated for - through @bicharts/chart-host, and reports in plain words: the marks drawn by kind, anything thrown (with the line), whether it came out blank, anything drawn outside its frame, and whether a click on a mark reaches onSelect with source rows. Takes seconds; local and free (no network, no credentials, nothing sent). Run it after each generate_chart instead of deploying to see whether a chart works, and check at the size the panel will give it: by default it reads minChartWidth and minChartHeight off the app's BicChartPanel around the chart (else the size it was generated for); pass width and height only for another size. A WARNING line is a label cut off at that size even at a narrow font's width; the reply says whether more room fixes it. The app's own legend and frame fit is NOT run in the check, so a label it flags may already be handled in the app. Never edit the generated chart code by hand to clear a finding: regenerate it (generate_chart, with a prompt describing the fix) or report it. It does not judge colors or real font widths.

Check how the app uses the chart library, before every deploy and after check_chart: reads the app's own source (never the files generate_chart and setup_fabric_app wrote) and reports, each with file, line and the library call to use instead: hand-written selection glue (a toggle, a second-click guard, a remount to clear) where useBicFilter + selects does it; each chart's filter wiring - the page filter its clicks set and the filters its query or component follows (filtered query, highlight only or none) - with a chart filtered by the filter it sets, a treatAs column the model's relationships can't carry to the panel, or to one of its measures (read from the tables each measure's expression reads) (read from the project's schema cache, .schema/models/*/model.sqlite), a total that isn't the sum of the parts the page shows (a rounding measure at the total), a click filter keyed coarser than the marks that set it, a chart carrying write markers whose query drops rows the write form can target, several charts sharing one click filter, a chart no page filter reaches, and a panel whose filtered query it isn't given; a "vs" measure in the app's .dax queries that is never blank (BLANK() - 1 is -1), a card that names a window ("2019 to 2025") over a query with no bound on it, and a query a line over time reads that can drop a quiet period (SUMMARIZECOLUMNS with no COALESCE or ADDMISSINGITEMS), a query whose range is a date written in (DATE ( y, m, d )) where it should come from the data or the person's words; a write that stores a placeholder name ("unknown") when no one is signed in or a time from the browser's clock, a Rayfin entity that takes any name on create or lets any row be updated again (rayfin/data), a name shown (createdBy) its policy doesn't check against the caller's token, a function that reads the caller's email from preferred_username or upn (Rayfin reads only the email claim), a write that resolves before its reload lands (so its button comes back on over t

Run once in a Microsoft Fabric App scaffolded from Rayfin's data app template, before the first chart: installs @bicharts/chart-host (at this server's version) and d3, adds src/lib/bic-chart-options.ts (the app's Fabric theme as chart options) and src/components/bic-chart-panel.tsx (a chart box that measures itself and shows the query's loading, error and empty states) and .agents/skills/regiabi-charts/SKILL.md (also written to .claude/skills/, where Claude Code reads it), ignores .bic/, and puts every @microsoft/rayfin-* package on npm's latest, the release `rayfin init` installs (run it before rayfin init; every package.json range it changes is listed, and the reply names the Rayfin version installed). Never overwrites a file; the one template file it edits - a vi.mock that fixes the template's own validate-visual test under ESM - is named in the reply, as is the one line of src/main.tsx it points at src/lib/bic-css-theme.ts (the theme without bundling Vega). With features: ["notes"] and/or ["scenarios"] (once Rayfin's data service is on), it also adds finished notes-on-marks and saved-scenario files - the Rayfin entities, registered in rayfin/data/schema.ts, a hook each, a notes dialog and a scenarios panel - built on chart-host's useBicFilter / useBicControls; write none of that by hand. Replies with a worked example that renders a generated chart from a live query.

In a Microsoft Fabric App built on Rayfin's data app template: runs one chart's DAX query through the project's own tooling - its semantic model's Rayfin connector (rayfin/rayfin.yml), or on the template's older layout its `fabric-app-data` CLI - renames the `Table[Column]` and `[Measure]` headers to plain names (the names the chart.component.tsx that generate_chart writes will match on live rows), saves EVERY row as CSV, reads each column's role, format and description from the model, and profiles the result. Replaces the query, rename, save and profile steps with one call, and returns the arguments to pass to list_eligible_charts and generate_chart. Write the query at the chart's grain (one row per country for a country map). Local: the data goes only where the project's own tooling already sends it, and nothing reaches the chart server.

Which charts suit this data? Answers 'what are good chart types for this dataset / model', 'what can I chart here', 'recommend some charts' for a semantic model in a Microsoft Fabric App built on Rayfin's data app template, in ONE call, from the model's real rows: reads its tables, columns, measures and relationships through the project's own tooling (its Rayfin connector, or the older layout's `fabric-app-data` CLI), finds its natural views (measures by place, flows between places, measures over time, measures by category), queries each at its grain, keeps the measures that vary there, and asks the server's eligibility engine what fits each view. Replies view by view with the real counts (rows, places, periods, categories) and the chart types that fit, and saves each view's rows and DAX under .bic/data so generate_chart can build any of them next. Pass `views` to ask about your own groupings. Answer the person from this reply rather than from general knowledge. One eligibility call per view: metered like list_eligible_charts (free within an hourly allowance, usage credits beyond it) and needs the same licence. For one table you already hold, use list_eligible_charts.