Quartyl Glossary: Product Terms and Where They Live

The product pages use a vocabulary that is half transfer-pricing (covered by the knowledge glossary) and half Quartyl-specific. This page defines the product side — what each term means in the workspace and where you will meet it — so the manual’s pages can assume you know the words.

The study object

Term	Definition	Where it lives
Study	The unit of work: one tested party, one transaction, one benchmarking run, its review and its deliverables. A study is a state machine, not a file.	The study list; every other surface is study-scoped
Study state	The study’s position in the lifecycle: Draft, Study Initialized, Processing, In Review, Report Generated, Document Generated, Signed Off, Archived — plus Rejected and Failed as working states.	The state stepper on the study
Tested party profile	What the entity being benchmarked is: its jurisdiction, whether it supplies goods or services, its function types, its nature-of-business description and the scope fields (channel, business models, geographies, IP ownership, related-party profile, materiality, exclusions). The reference every downstream screen weighs; the functional analysis itself is derived from it later, not typed in.	The wizard’s Study Context step; the screening stages
Parameters	The study’s benchmarking configuration: the PLI, the averaging basis (single latest year, or multi-year aggregation of raw financials), the percentile band for the range, the tested party’s own margin, and the data filters — revenue range with currency and reporting unit, maximum related-party share, minimum employee-cost ratio. Recorded on the study as part of the record.	The wizard’s Parameters & Run step
Dump data	The raw data as read after the quantitative stage, before qualitative work — the inspection point for what the screens actually received. The normalized dump is cached as Parquet for the life of the study’s deliverables and then purged: seven days by default, one to thirty where the firm’s plan allows the window to be configured.	The study’s data views
Processing step	The substate within a run: Queued → Preparing Data → Quantitative Analysis → Qualitative Screening → AI Screening → (Web Research) → (Advanced AI Screening) → Final Analysis.	The run’s progress stepper

The review layer

Term	Definition	Where it lives
Comparables grid	The screened comparable population sorted into the four buckets the screens produce — accepted, almost accepted, flagged, rejected — with the recorded reason for each. The work surface of a study in review.	The study’s review view
Disposition	Where a company sits: the screen’s bucket (accepted, almost accepted, flagged, rejected) and, once a reviewer acts, the effective status of accept or reject that the statistics run on. Every one of them carries a rationale.	The grid
Override	A reviewer’s decision that replaces a screen’s bucket with a straight accept or reject, with a recorded rationale. Only Manager, Firm Admin and Superadmin may override, and only while the study is In Review. Overrides are ledgered, not silent.	The grid; the override micro-ledger in the audit trails
Override rationale	The recorded reason for an override — the text a transfer pricing officer reads when the grid is examined.	The grid entry; the audit ledger
Qualitative data	The per-comparable facts the qualitative screen wrote during the run — similarity and composite scores, the risk level, the recommendation, its rationale and the company’s description fields. Read-only in the review and evidence views.	The comparable’s detail view

Results and reports

Term	Definition	Where it lives
Arm’s length range (ALR)	The pool-derived band for the chosen PLI: the percentile band set in the study parameters (25th–75th by default), except in the six jurisdictions that prescribe their own band, where theirs applies. Below three accepted comparables no band is published and the arithmetic mean is reported as a point estimate. The tested party’s margin is placed against it.	The results view
Risk score / reliability score	The study-level and pool-level signals the final analysis computes: how risky the position is, and how reliable the pool behind it is. Weighted rules over the computed statistics — sample size, dispersion, range tightness, loss incidence — not a trained model.	The results view; the risk engine (where held)
Excel workbook	The primary deliverable, built when the study is approved: six sheets — Strategy, Search Result, Accept Reject Matrix, Financial Results, Margin Analysis and Web Analysis — with every value computed in Python rather than left as live formulas.	The study’s report downloads
Word master report	The seven-chapter master report (plus cover, confidentiality page, contents and abbreviations) with twelve lettered annexures, A–L, generated on demand from the study’s recorded analysis with the engagement details. The annexures carry the schedules themselves, not pointers. The contents field refreshes when Word updates it.	Reports → final document
PDF report	The branded client-facing PDF produced from the same content stream as the Word report — the same seven chapters and the same Annexures A–L, with its own typography: a typeset contents page with real page numbers, footnotes in the page gutter and natively drawn charts. Built best-effort: if the PDF leg fails, the Word report is still stored and simply no PDF is offered.	Reports → final document
Final document	The on-demand request that produces both report files: the engagement details (prepared by, report date, the database line, search regions, the corporate-background schedules and any narrative overrides) are captured at request, the deliverables are built from the persisted analysis, and the files are stored on the study. Each study has five generations, counted from the job ledger and printed on the action.	The partner-level report action
White-label branding	The firm’s brand name and accent applied across the workspace shell — sidebar, sign-in and claim page — where the firm’s plan holds the feature. The generated reports carry the platform’s own identity.	Firm settings

Evidence and audit

Term	Definition	Where it lives
Evidence ledger	The append-only, event-ordered record for each comparable and each decision — the capture, the AI recommendation, and the verification events a reviewer records over it.	The evidence repository (where held)
Digital war room	The per-company drill-down in the evidence repository: the snippets, captures and entity data behind that comparable’s ledger entries.	The evidence repository
Ground-truth registry	The cross-study list of the standardised screening and AI reasons, each with its reason identifier and recency/hit statistics, and the link an override has to the reason it corrects. It records which canonical rationale was applied — it is not a store of independently verified facts.	The audit trails
Audit packet	The exportable bundle for a study: the ledger, the overrides, the chronology — the package a firm hands over (or keeps) for an examination. Each export is itself recorded.	The evidence repository’s packet actions
Audit trail	The study’s complete chronology: every state change, every action, every override, with the actor and the timestamp.	The audit trails view

Risk

Term	Definition	Where it lives
Audit probability / litigation risk	The study-level risk signals the risk engine scores: the likelihood dimensions of an examination challenge, computed as weighted rules over the recorded study data.	The Predictive Risk Engine (where held)
Defensibility grade	The study-level assessment of how well the record supports the position — the score that turns “defensible” into a comparable number.	The risk engine
Portfolio risk	The aggregation of study-level risk across the firm’s studies — where the practice’s exposure concentrates.	The risk engine’s portfolio view

The engine is heuristic by design: fixed weights over the numbers on the record, with no trained model in the loop, and a neutral score for any jurisdiction the rule set does not rate rather than a flattering low one.

Administration

Term	Definition	Where it lives
Plan feature	A capability gate held (or not) by the firm’s plan: the gated screening steps (the deep FAR pass, and with it the optional web research step), dump retention, the risk engine, the evidence repository, the developer console, user management, firm settings, white-label, priority support and others. Assigned to the firm by the platform; absent features do not render, and the server enforces the same gate on every request.	The platform’s plans and firms consoles
Firm settings	The tenant configuration panel: the security tab (session timeout, MFA mandates, IP allowlist, audit retention), a Single Sign-On tab where the firm is entitled to manage it, and a Branding tab that exists only when the plan holds white-label.	Administration
TP defaults	A stored set of house benchmarking defaults on the tenant record — default jurisdiction, arm’s-length percentiles, permitted methods, default PLI, base currency — returned by the settings API. There is no editor for it in the panel, and a new study does not inherit it: the parameters you run with are the ones you set in the wizard.	The tenant record

The transfer-pricing terms these product terms lean on — tested party, PLI, IQR, Accept-Reject, working capital adjustment, safe harbour — are defined in the knowledge glossary alongside their method and documentation context.

FAQ

“Disposition” vs “override” — what is the difference? A disposition is the screen’s per-company placement — accepted, almost accepted, flagged or rejected — made and reasoned at screening time. An override is a later, reviewer-made change to that row, and it can only be an accept or a reject, with a reason. It is additionally ledgered, because it is the exception to a recorded process.

Is the dump data the same as the uploaded file? No. The dump is the data as the pipeline read it, after the quantitative stage — the inspection point for what the screens actually received. The uploaded file is the input; the dump is the evidence of what that input became, kept in the run’s cached form for the retention window and then purged.

Where does the ground-truth registry come from? Every reason the screens and the AI give is standardized into a canonical list, and each company’s rationale points at an entry in it. The registry is that list across studies, with the recency and hit statistics, and the link from an override back to the canonical reason it corrects. It answers “which recorded rationale did this decision rest on?” — it is not a claim that anyone independently verified the underlying facts.