# AI-Assisted Engineering Process

BowEcho's documentation includes AI-assisted engineering records on purpose.
These files are not one-shot prompts and they are not raw private chat logs.
They are curated design and verification artifacts that show how features were
specified, challenged, implemented, and tested.

The useful public record is the process: iterative requirement refinement,
domain-literature checks, adversarial review, implementation handoffs,
acceptance criteria, regression-test targets, and explicit design tradeoffs.
That trail is especially important for a scientific and operational tool,
where a feature is only as trustworthy as the assumptions, citations, and
failure modes that shaped it.

The public docs intentionally omit local machine details. Paths under personal
home directories, assistant tool-output folders, temporary extraction caches,
local executable locations, unpublished private data, credentials, API tokens,
personal config dumps, and private polling or position-feed URLs do not belong
in the repository. When a local artifact mattered only as verification
scaffolding, the docs now describe it generically and retain the public paper,
DOI, package, source-file name, or official URL instead.

Prompt excerpts can be valuable when they explain why a design exists, but they
should be curated. Public docs should read like engineering records: requested
capability, design intent, evidence, decision, implementation plan, and tests.
Casual transcript residue is edited into that form without erasing the fact
that the work was AI-assisted.

The lesson BowEcho tries to preserve is simple: high-quality AI-assisted
scientific software comes from structured prompts, domain constraints,
verification, review, and tests. It does not come from a single vague
instruction.