Example · Example catalog

Choose the right example

This is a documentation-only navigation exercise. It shows how to use the Example catalog without confusing a good teaching match with a scientifically justified analysis choice.

The selection rule is:

Choose by the thing you need to learn next, then read the example contract before copying anything.

Scenario 1 — “I just installed GazeAudit”

The immediate question is software availability, not measurement or robustness.

Use the catalog with:

• Data context: Software-only
• Focus: Environment

That leads to Install, verify, first import.

Why this is the right learning route:

• it verifies package identity, imports, optional capabilities, and console commands;
• it does not require a scientific dataset;
• its boundary explicitly says that successful installation is not scientific validation.

Do not begin with a robustness example merely because it contains more analysis code.

Scenario 2 — “I have my own gaze CSV”

The need is to connect a real source table to the package safely.

Use:

• Data context: Demo or user data
• Focus: Data & QC

Open First real audit.

The reusable element is the project template: source mapping → structural QC → governed downstream analysis → saved evidence.

The demonstration settings are not a ready-made study protocol. Before transferring the workflow, use Adapt a synthetic example to your study.

Scenario 3 — “I need to understand a specification-space audit”

Here the goal is learning the scientific workflow mechanics before applying them.

Use:

• Data context: Synthetic
• Focus: Robustness & sensitivity

Open End-to-end robustness audit.

The contract tells you what transfers: the complete audit workflow. The evidence boundary tells you what does not: the synthetic specification levels and endpoint choices.

After learning the mechanics, move to the Specification-space guide for the real task.

Scenario 4 — “The code ran; what can I report?”

This is no longer mainly an execution question.

Use:

• Data context: Synthetic
• Focus: Interpretation & reporting

Open Result-pattern reporting or Decision-to-report.

These examples teach how to separate:

• complete vs incomplete execution;
• direction stability;
• magnitude sensitivity;
• bounded manuscript wording.

Their synthetic result patterns are teaching cases, not empirical priors for your dataset.

Scenario 5 — “A reviewer requested another analysis”

Filter to:

• Data context: Synthetic
• Focus: Peer review & publication

Several examples can legitimately match because the next action depends on the reviewer request:

The catalog is allowed to return several matches. That is preferable to pretending one workflow is universally correct.

Scenario 6 — “I know the function name, not the workflow”

Use:

• Data context: Documentation-only
• Focus: Documentation & API

Then choose between:

• Generated API call contracts for parameter/return structure;
• Source-level API inspection for signatures and source;
• Function → evidence for the governed research context.

Once the question changes from “what does this symbol do?” to “what should my study choose?”, leave the documentation-only route and use the corresponding guide.

A compact selection checklist

Before opening an example, answer:

1. What do I need to learn next?
2. Do I need synthetic, software-only, documentation-only, or user-data material?
3. What output do I expect from the exercise?
4. Which part of the example is explicitly reusable?
5. What does its evidence boundary prohibit me from transferring?

If question 5 is still unclear, read the example contract before copying code.

Return to the Example catalog to try the filters.