# v0.1.0-alpha.1

## Overview

`v0.1.0-alpha.1` is the first alpha-positioned release draft for `.aieng` as an auditable CAD/CAE context package.

This release is about package semantics, evidence discipline, provenance, freshness tracking, review readiness, and stable-ish pure helpers for AI-assisted review workflows.

It is not a CAD automation release, not a solver release, and not an engineering decision engine.

## What `.aieng` is

`.aieng` is:

- an auditable CAD/CAE context package,
- an engineering evidence/provenance layer for AI-assisted review,
- a review-oriented interoperability layer.

`.aieng` is not primarily CAD-to-JSON. Converters and adapters are ingestion paths into the package, but the higher-value layer is:

- provenance,
- evidence references,
- freshness/revalidation state,
- missingness and unsupported-state recording,
- diagnostics and review readiness,
- explicit separation between evidence, proposals, and acceptance.

## Included capabilities

The alpha-scoped core semantics include:

- CAE result summary generation
- field summary artifacts
- artifact manifest generation
- evidence resolver semantics
- package consistency diagnostics
- revalidation status and geometry revision freshness tracking
- audit event semantics
- claim proposal semantics
- support packet semantics
- review readiness semantics

The reference runtime/workbench lives in `aieng-ui` and delegates package semantics back to `aieng` core. Its backend tests exercise real and simulated CAE workflow paths, but the semantic source of truth remains in this repository.

## Explicit non-goals

This release does **not** provide:

- engineering certification,
- automatic engineering validation,
- solver authority,
- autonomous engineering decisions,
- automatic claim advancement,
- claim acceptance/rejection workflows,
- claim maps as part of the intended alpha contract,
- a CAD kernel,
- a solver replacement,
- a guarantee that STEP conversion captures design intent.

## Safety and review semantics

The intended safety posture is conservative:

- `claim_advancement: "none"` is the default invariant.
- Evidence is not claim.
- Proposal is not acceptance.
- Freshness is not validation.
- Diagnostics are not certification.
- Tool execution must not silently advance engineering claims.

Where the package records solver outputs, topology, or imported artifacts, those records are there to support review, not to assert engineering correctness by themselves.

## Known limitations

Current limitations include:

- no production multi-CAD adapter guarantee,
- no certification or validation claims,
- no automatic design verification,
- no guarantee that STEP-derived structure captures design intent,
- opt-in or gated real-binary workflows outside the narrow pure-core semantics path,
- remaining legacy claim-map surfaces in the broader repo that need cleanup before a fully clean alpha tag.

Current known test results from this release-preparation pass:

- focused core release checks: `54 passed`
- full `pytest -q` run in this repo: `1916 passed, 15 skipped, 10 warnings`
- `aieng-ui/backend` reference runtime checks (latest reported state): `352 passed, 3 skipped`

## Future roadmap

Near-term roadmap items should stay release-hardening oriented:

- remove or quarantine legacy claim-map/update-claim surfaces from alpha-facing docs and APIs,
- narrow the public API contract around pure semantics modules,
- harden packaging so installed wheels include required schemas/resources,
- keep runtime orchestration and package semantics clearly separated,
- continue strengthening deterministic contract tests and golden examples.
