Report storage and indexing
Reports are written as JSON plus HTML, organized into a date-based folder tree. An append-only index.ndjson file at the root lets the interface load large histories instantly without scanning sub-folders.
{reports_path}/
index.ndjson
2026/
04/
W14/
AMP-100-SN001-PASS-20260405-180358-abc12345.json
AMP-100-SN001-PASS-20260405-180358-abc12345.html
archive/
2025/
...
Report file naming
Every report filename encodes the most important fields at a glance:
{part_number}-{serial}-{RESULT}-{YYYYMMDD}-{HHMMSS}-{uuid8}.json
Example: AMP-100-SN00412-FAIL-20260405-180358-3fdc76ec.json
| Segment | Source | Notes |
|---|---|---|
part_number | Routing entry | NA if no routing |
serial | Trigger payload | NA for manual triggers |
RESULT | Final run result | PASS, FAIL, ERROR, ABORTED |
| Date/time | UTC start time | |
uuid8 | Random | Collision avoidance |
The report_id field inside the JSON body matches the filename stem and is the stable identifier used across the index and the viewer.
Result Viewer
The Result Viewer is at the Results tab of the main navigation.
List panel. Outcome badge, serial, part number, sequence name, date, and duration. Paginated at 50 per page.
Search. Instant client-side filtering by serial number, part number, sequence name, or report ID.
Result filter. Click PASS, FAIL, ERROR, or ABORTED chips to narrow the list. ALL resets.
Detail view. Station info, trigger type, run summary tiles, per-step expandable cards with raw data, validation detail, and array charts.
If the index file is lost or corrupted, use Rebuild index in the Config panel to regenerate it by scanning the report folders.
Storage configuration
Report storage is configured in config/system_config.json:
{
"reports": {
"path": "data/reports",
"archive_after_days": 90,
"max_hot_reports": 10000
}
}
| Field | Default | Description |
|---|---|---|
path | "data/reports" | Where reports are written. Relative paths resolve against the application working directory. |
archive_after_days | 90 | Reports older than this are moved to archive/. Set to 0 to disable. |
max_hot_reports | 10000 | If the active folder exceeds this count, oldest entries are archived regardless of age. |
To change the path: Config → Report Storage → Browse or type a path → Save. Takes effect on the next engine start. Existing reports are not moved — run Rebuild index after copying files.
GRR study modes
GRR is a first-class operating mode in Corvus. It runs a structured measurement study to quantify how much observed variation comes from the gauge itself versus the parts being measured.
| Mode | Use when | What it measures |
|---|---|---|
single_op | One operator | Equipment variation (EV) and part variation (PV) |
full | Multiple operators need comparison | Repeatability, reproducibility, operator variation, and interaction |
| Hardware qualification | Qualifying the gauge with no part movement | Primarily equipment variation — no operator handling |
The hardware qualification profile is activated with:
{
"mode": "single_op",
"part_handling": "static",
"auto_advance": true,
"skip_prompts": true
}
Part handling modes
| Value | Operator prompted | When to use |
|---|---|---|
per_run | Before every measurement | Parts are re-fixtured for each trial |
per_part | Once per unique part, then when part changes | Parts stay in fixture for all their trials |
static | Never | Part never moves; hardware qualification only |
%GRR status thresholds (AIAG MSA 4th Ed.)
| %GRR | Status |
|---|---|
| < 10% | Acceptable |
| 10–30% | Marginal |
| > 30% | Unacceptable |
Study lifecycle
- Create — configure the study in the GRR screen (parts, trials, operators, sequence, capture steps, tolerance spec).
- Plan generated — Corvus writes a randomized execution matrix (Fisher-Yates shuffle with consecutive-part avoidance).
- Start — the study runner fires measurement triggers in plan order, prompting the operator to load or change parts as needed.
- Data collected — each completed run is appended to
results.jsonlimmediately. A crash mid-study can be resumed without data loss. - Analysis — when all runs are complete, Corvus runs the ANOVA computation and writes
report.json. - Result panel — the study result shows %GRR, NDC, P/T ratio, and capability indices side-by-side.
Study files live at data/grr_studies/{study_id}/:
| File | Contents |
|---|---|
config.json | Study parameters — immutable after creation |
plan.json | Randomized execution matrix |
results.jsonl | Append-only measurement log |
report.json | ANOVA results — written after analysis completes |
Study configuration reference
| Field | Required | Description |
|---|---|---|
mode | Yes | "single_op" or "full" |
part_count | Yes | Distinct parts (minimum 2 for non-static modes) |
trial_count | Yes | Measurements per part/operator cell (minimum 2) |
operator | Yes | Sole operator ID for single_op mode |
operators | Full mode | Operator IDs for full mode (minimum 2) |
capture_step_ids | Yes | Step IDs whose numeric outputs are the measurements |
tolerance_spec | No | { "lsl": 3.13, "usl": 3.47 } — enables P/T ratio and capability indices |
part_handling | Yes | "per_run", "per_part", or "static" |
auto_advance | Yes | Skip GUI confirmation between measurements |
skip_prompts | No | Auto-respond Pass to all user_prompt steps — enables unattended runs |
job_slots | No | Zero-indexed slot indices the runner may use. Empty = all slots. |
Capability and measurement concepts
- %GRR — gauge variation as a percentage of total variation.
- NDC — Number of Distinct Categories. ≥ 5 is generally required for a capable measurement system.
- P/T ratio — GRR span relative to the tolerance window. Target < 10%.
- Cpk — short-term process capability using part variation with measurement error excluded.
- Ppk — long-term capability using total variation, including both process and gauge effects.
Capability status thresholds
| Index value | Status |
|---|---|
| ≥ 1.67 | Excellent |
| ≥ 1.33 | Capable |
| ≥ 1.00 | Marginal |
| < 1.00 | Incapable |
Interpreting Cpk vs Ppk
| Relationship | Interpretation |
|---|---|
| Cpk ≈ Ppk | Measurement system has little impact on observed variation |
| Cpk >> Ppk | Measurement system inflates observed variation — gauge improvement recommended |
| Cpk < 1.33 | Process centering or spread issue, independent of gauge quality |
One-sided tolerance specs are allowed. When only one limit is provided, Cp and Pp (which require both limits) are omitted from the report. P/T ratio is computed using the process-centred equivalent width.