Skip to main content
are configuration parameters that control how your AI capability behaves. By defining flags, you can run that systematically compare different models, prompts, retrieval strategies, or architectural approaches - all without changing your code. This is one of Axiom’s key differentiators: type-safe, version-controlled configuration that integrates seamlessly with your evaluation workflow.

Why flags matter

AI capabilities have many tunable parameters: which model to use, which tools to enable, which prompting strategy, how to structure retrieval, and more. Without flags, you’d need to:
  • Hard-code values and manually change them between tests
  • Maintain multiple versions of the same code
  • Lose track of which configuration produced which results
  • Struggle to reproduce experiments
Flags solve this by:
  • Parameterizing behavior: Define what can vary in your capability
  • Enabling experimentation: Test multiple configurations systematically
  • Tracking results: Axiom records which flag values produced which scores
  • Automating optimization: Run experiments in CI/CD to find the best configuration

Setting up flags

Flags are defined using Zod schemas in an “app scope” file. This provides type safety and ensures flag values are validated at runtime.

Create the app scope

Create a file to define your flags (typically src/lib/app-scope.ts):
src/lib/app-scope.ts

Use flags in your capability

Reference flags in your capability code using the flag() function:
src/lib/capabilities/classify-ticket/prompts.ts

Declare flags in evaluations

Tell your evaluation which flags it depends on using pickFlags(). This provides two key benefits:
  • Documentation: Makes flag dependencies explicit and visible
  • Validation: Warns about undeclared flag usage, catching configuration drift early
src/lib/capabilities/classify-ticket/evaluations/spam-classification.eval.ts

Running experiments

With flags defined, you can run experiments by overriding flag values at runtime.

CLI flag overrides

Override individual flags directly in the command:

JSON configuration files

For complex experiments, define flag overrides in JSON files:
experiments/gpt4-detailed.json
experiments/gpt4-mini-concise.json
Run evaluations with these configurations:
Store experiment configurations in version control. This makes it easy to reproduce results and track which experiments you’ve tried.

Comparing experiments

Run the same evaluation with different flag values to compare approaches:
Axiom tracks all these runs in the Console, making it easy to compare scores and identify the best configuration.

Best practices

Organize flags by capability

Group related flags together to make them easier to manage:

Set sensible defaults

Choose defaults that work well for most cases. Experiments then test variations:
For evaluations that test your application code, it’s best to use the same defaults as your production configuration.

Use enums for discrete choices

When flags have a fixed set of valid values, use enums for type safety:

Advanced patterns

Model comparison matrix

Test your capability across multiple models systematically:

Prompt strategy testing

Compare different prompting approaches:

Cost vs quality optimization

Find the sweet spot between performance and cost:
experiments/cost-quality-matrix.json
Run experiments and compare cost (from telemetry) against accuracy scores to find the optimal configuration.

CI/CD integration

Run experiments automatically in your CI pipeline:
.github/workflows/eval.yml
This automatically tests your capability with different configurations on every pull request.

What’s next?

  • To learn all CLI commands for running evaluations, see Run evaluations.
  • To view results in the Console and compare experiments, see Analyze results.