# Support, licence and contributing

## Licence

heliaAOT is released under the Ambiq Apollo SDK License, which the repository
holds in `LICENSE.md`. Three points matter before you ship:

- **Field of use.** The licence grants the right to use, copy, modify and
  distribute the software solely for incorporation into, and execution on,
  computing platforms that include an Ambiq-manufactured CPU. Execution on a
  non-Ambiq CPU is expressly forbidden, including as part of a multi-CPU
  system.
- **Attribution.** Redistribution in source or binary form has to carry the
  copyright notice, the conditions and the disclaimer.
- **No warranty.** The software is provided as is, with all warranties
  disclaimed.

The repository licence and the generated module licence are separate texts.
The documentation handler renders `helia_aot/aot/templates/docs/license.md.j2`
into the module’s `LICENSE`; it is not a copy of the repository `LICENSE.md`.
Read both applicable texts and your model/dependency terms. Third-party
components heliaAOT depends on are listed in `THIRD_PARTY_NOTICES.md`.

`LICENSE.md` in the repository is the authoritative text. The summary above is
a reading aid, not a substitute for it, and it is not legal advice.

## Reporting a problem

If you have access to the private repository, report problems in the
[heliaAOT issue tracker](https://github.com/AmbiqAI/helia-aot/issues).
Otherwise, share the details below with your Ambiq contact.

Include the following so the team can reproduce or narrow down the failure:

- **The version.** `helia-aot version` prints it.
- **The target.** The platform name you passed to `--platform.name`, as
  [list-targets](https://ambiqai.github.io/helia-aot/reference/cli/) spells it.
- **The command.** The whole `helia-aot convert` line, or the YAML file if you
  configured it that way.
- **The console output at `--verbose 2`.** Level 2 is the one
  [Troubleshooting](https://ambiqai.github.io/helia-aot/guide/troubleshooting/#when-there-is-no-error-at-all)
  asks for: it includes resolved operator attributes and planner diagnostics.
  Use `--verbose 3` when expanded AIR tensor and option details are needed.
- **The model**, or a description of the failing node if you cannot share it.
  A `TemplateRenderError` in particular is a heliaAOT defect and is worth
  reporting with whichever of the two you can give.

For anything you would rather not put in a public issue, write to
`support.aitg@ambiq.com`.

## Models

The Getting started pages convert models from
[AmbiqAI/helia-model-zoo](https://github.com/AmbiqAI/helia-model-zoo), which
holds the LiteRT files the examples download. heliaAOT takes supported LiteRT models;
the zoo is a convenience, not a requirement.

The example fixtures currently have no stated model licence in the recorded
provenance. Their availability for download does not establish permission to
redistribute or ship the weights. Check the model card and obtain the applicable
terms before using a fixture in a product; see the
[example provenance notes](https://github.com/AmbiqAI/helia-aot/tree/main/examples#model-provenance).
The compiler's licence does not grant rights to third-party model weights.

## Supported Python and operating systems

`pyproject.toml` declares `requires-python = ">=3.11"`, and the classifiers name
3.11, 3.12, 3.13 and 3.14. The
[Versions and compatibility](https://ambiqai.github.io/helia-aot/reference/versions/) page reads the
same file, so it is the row to trust if the two ever differ.

The package declares `Operating System :: OS Independent`. That is what the
repository claims, and it is not the same as a tested claim: every CI job runs
on an Ubuntu runner, so Linux is the only operating system with evidence behind
it. The conversion itself is pure Python; the toolchain you build the emitted
module with is a separate question, covered in
[Toolchains and build environments](https://ambiqai.github.io/helia-aot/guide/toolchains/).

## Contributing

The repository has no `CONTRIBUTING.md`. `AGENTS.md` at the root is the single
source of truth for contributors and for coding agents alike, and `CLAUDE.md`
only points at it. Read it before opening a pull request. The parts that catch
people out:

- **Conventional commits.** `feat:`, `fix:`, `docs:`, `refactor:`, `test:` and
  `chore:`, with an imperative summary. Pull requests are squash-merged, so the
  squash title becomes the commit message that release-please reads to decide
  the next version. Use a conventional title so release-please can classify the change.
- **Behavior changes need tests.** A bug fix needs a regression test, and a
  new public API or extension point needs unit coverage.
- **Generated artifacts are regenerated, never hand-edited.** `README.pypi.md`,
  codegen snapshots and reference exports have owning tools and freshness
  checks. Regenerate reference JSON with `uv run python -m repo_tools.docs_export`
  and validate the site with the commands below. Release-please owns
  `CHANGELOG.md`; do not manually regenerate it as a documentation export.
- **The docs build is part of the change.** From `docs/`, `npm run check`,
  `npm run build` and `npm run check:reference` are what hold this site to the
  source it documents.

Branch protection requires an approving review and green CI before a merge.