Disclosure: I maintain the open-source repository described below. This article was prepared with AI assistance and reviewed before publication.
Automation failures in finite-element projects are often blamed on the solver, but many failures begin earlier. A script renames a region while a later load still points to the old name. An output request no longer covers the quantity needed by a review. A report calls a result "approved" even though the solver and physical-review gates are incomplete.
These are contract problems. They are useful to detect before launching a licensed application or handling a large model. In this tutorial I will use a small, dependency-free Python demo to show the pattern.
git clone https://github.com/1348109517/abaqus-agent-skills.git
cd abaqus-agent-skills
git checkout v0.3.0
python scripts/run_demo.py --scenario complete
The complete synthetic contract produces:
PASS: 8
WARNING: 0
REVIEW_REQUIRED: 0
The command writes report.json
and report.md
. Both reports are derived from the same ordered finding objects. They contain an input SHA-256 digest but no runtime timestamp by default, so rerunning an unchanged contract yields deterministic review artifacts.
Now run the committed failure case:
python scripts/run_demo.py --scenario naming-drift
Its summary is:
PASS: 7
WARNING: 0
REVIEW_REQUIRED: 1
The C-REF-001
finding points to loads.Gravity.region
. The load refers to ExcavationFaceRenamed
, while that region is not declared by the contract. The command still exits successfully because the auditor completed its job; the finding is a structured request for human review, not a Python crash.
This separation matters in CI. An invalid JSON shape or an I/O failure should fail the tool. A valid contract containing an engineering-review finding should produce a stable artifact that a person or later workflow can inspect.
python scripts/run_demo.py --scenario evidence-overreach
This scenario also returns seven passes and one REVIEW_REQUIRED
finding. C-EVIDENCE-001
records that an engineering claim was marked approved before the declared solver and physical-review gates were complete.
The key rule is intentionally conservative:
static contract review != solver evidence
solver completion != physical correctness
physical review != automatic claim approval
A deterministic preflight can verify names and declared dependencies. It cannot choose a constitutive model, judge mesh adequacy for a specific claim, interpret an ODB, or certify an engineering conclusion.
The public example uses synthetic data only. For another workflow, start with a small schema that names producers and consumers explicitly: parts, instances, regions, materials, steps, loads, output requests, and evidence gates. Keep machine-checkable references separate from decisions that require domain judgment. Prefer a status such as REVIEW_REQUIRED
when automation has reached its evidence boundary.
Repository:
https://github.com/1348109517/abaqus-agent-skills
Verified v0.3.0 release:
https://github.com/1348109517/abaqus-agent-skills/releases/tag/v0.3.0
The project is early-stage, Apache-2.0 licensed, and independently maintained. It is not affiliated with or endorsed by Dassault Systemes or SIMULIA. It does not include Abaqus, official documentation, solver binaries, or private model data.
If the project is useful in your workflow, star the repository to follow its development. I would also appreciate a reproducible issue report or a proposal for another synthetic contract failure; those concrete cases are more useful at this stage than broad adoption claims.