# AXIOM Analysis

## Software Analysis Guide

Version 1.0 | April 12, 2026

---

## Purpose

Use the Software domain when you want AXIOM to review technical material for likely defects, regressions, architecture stress points, rollout risk, and validation gaps.

This workflow is strongest when the input contains real technical evidence:

- code or diffs
- architecture notes
- logs or traces
- expected behavior
- the reason the review matters now

---

## Best Starting Settings

### Code / change review

- Domain: `Software`
- Modules: `review`
- Report depth: `Standard`
- Engine: `AXIOM Gateway` or `Auto`
- Live sources: `off`

### Architecture review

- Domain: `Software`
- Modules: `architecture`
- Report depth: `Standard`
- Engine: `AXIOM Gateway` or `Auto`
- Live sources: `off`

### Broad technical review

- Domain: `Software`
- Modules: `review`, `architecture`
- Report depth: `Standard`
- Engine: `AXIOM Gateway` or `Auto`
- Live sources: `off`

---

## What To Prepare

Before you run the analysis, collect:

- the scope being reviewed
- what changed
- the expected behavior
- the current observed behavior
- the main risk areas
- code or config evidence
- logs, tests, and open questions

If you only provide a vague summary, the review will stay vague.

---

## Best Input Pattern

The cleanest current pattern is:

1. fill out the intake template
2. upload the intake plus the technical material
3. use the short prompt file in the portal

This works better than turning the request box into a long, improvised technical memo.

---

## Common Mistakes

- asking for a serious review without uploading the real code or logs
- not naming the files or modules in scope
- not saying what behavior is expected
- mixing architecture concerns and bug symptoms without labeling them
- using `fast` when the task is actually a deep review

---

## Recommended Run Order

1. Start with `review` or `architecture` and `Standard`
2. Improve the evidence pack if the output feels generic
3. Use `review + architecture` when both code and structure matter
4. Only then try `Deep`

---

## What A Strong Result Should Include

A strong software report should clearly show:

- the highest-risk issues
- the evidence behind them
- likely consequences
- architecture stress points
- missing tests or validation
- the most important information gaps

---

## Related Files

- `SOFTWARE_ANALYSIS_INTAKE_TEMPLATE_2026-04-12.md`
- `SOFTWARE_ANALYSIS_PROMPT_2026-04-12.txt`
- `SOFTWARE_ANALYSIS_EXAMPLE_REVIEW_2026-04-12.txt`

---

End of Software Analysis Guide v1.0