Operate

Import center

Upload a workbook shaped like the ASSAM canonical model. Sheets are detected, headers mapped, values validated and a genuine dry run is produced. Nothing is analysed until you commit the parsed rows to the tenant-scoped pilot data store, where they persist across reloads.

Synthetic demo

Workflow

Stage 1 of 5

1. Select files2. Detect & map3. Validate4. Dry run5. Load workspace

Rows parsed

No file selected yet

Rows mapped

0 skipped

Warnings

Import proceeds

Errors

Those rows are skipped

Run a dry run first.

Security classification — SANITIZED PILOT DATA ONLY

What is actually enforced today, and what still blocks confidential client data

Use sanitized or synthetic data only. This preview is a controlled pilot environment, not a certified store for confidential client data.

Enforced now

Authenticated sessions (email + password) required to commit, read or delete a dataset
Server-side auth verification on every estate function (bearer token validated per request)
Row-level security: every row is scoped to auth.uid() and additionally filtered by tenant_id
Atomic imports: dataset, records and issues are written in one database transaction — a failed write rolls everything back, and the database refuses a second dataset for the same user + tenant
Append-only pilot activity trail: every commit and delete/reset is recorded by a database trigger in the same transaction; users can read only their own events and cannot edit or remove them
Tenant-scoped cascade delete — one tenant's reset cannot touch another's data
Encryption in transit (TLS) and at rest at the managed-Postgres level

Outstanding blockers

No organisation / role model or sharing controls — a dataset belongs to one signing-in user only
Activity trail covers commit and delete/reset only — not reads, exports or sign-in events
No customer-managed encryption keys and no contractual data-residency guarantee
No independent security review or penetration test of this preview
Managed preview hosting is a temporary path, not the planned production data architecture

Pilot activity

Append-only trail of commits and deletes for tenant northwind, written by the database in the same transaction as the change

Client import template

Nine canonical streams. Column headers below are generated from the parser itself, so a completed template always maps.

Sheet name	Canonical entity	Required columns	Columns
Applications	Applications	Application Id, Application Name	17
Hardware Assets	Hardware assets	Asset Id	24
Deployments	Deployments / discovery	Deployment Id	16
Entitlements	Entitlements / purchases	Entitlement Id	31
Commercial Transactions	Commercial transactions	Transaction Id, Transaction Type	25
Contracts	Contracts / agreements	Contract Id	20
SaaS Cloud	SaaS / cloud	Subscription Id	18
AI Assets	AI assets	Ai Asset Id	20
Evidence	Source / evidence	Evidence Id	12

Accepted formats: .xlsx, .xls and .csv (one stream per CSV file, named after the sheet). Extra columns are reported as unmapped and ignored; missing required identifiers reject that row only. Allowed transaction types: new purchase, additional purchase, maintenance renewal, subscription purchase, subscription renewal, true-up, upgrade, reinstatement, credit, termination, refund, other.

Engine self-tests

Executable proofs run against an internal fixture shaped exactly like the canonical model

Proves: maintenance renewal never creates entitlement quantity, purchases do, subscription and maintenance renewal dates stay distinct, deficit/surplus math, no savings without cost evidence, and source lineage preserved end to end.