AEISPrepare the foundation inputs
Start from the approved IFC foundation source. Confirm revision identity, foundation scope, levels, units, and the exclusions that keep non-foundation content out of the build.
Where the engineering case requires it, prepare the lateral soil-spring workbook and any build options the engineer intends to apply. Inputs that are not named before build become untraceable assumptions after the run.
- Select the issued IFC foundation revision and record its approval status.
- Confirm soil-spring or support idealisation inputs when the stage requires them.
- Name build options, design settings, and known exclusions before generation.
Confirm soil springs and support assumptions
Soil idealisation is engineering judgment, not a free default. Review spring values, support conditions, and any workbook mappings against the geotechnical basis of design before they enter the SAFE input path.
If soil data is incomplete, stop and resolve it. Carrying placeholder springs into analysis creates a clean-looking run with an untrusted foundation response.
- Trace spring or support values to the geotechnical source used on the project.
- Record units, coordinate alignment, and any zone-based variation.
- Flag temporary or construction-stage support conditions separately from permanent design.
Build the analysis input
Generate the SAFE input set from the approved IFC and configured options. The build stage should produce inspectable geometry, assignments, assumptions, and build logs—not a black-box file drop.
Review generated content before authorizing the external-tool run. Resolve source or build warnings rather than carrying them silently into analysis.
- Inspect generated geometry, element assignments, and load or support mapping.
- Read build logs for missing properties, unit issues, and scope gaps.
- Freeze the build package identity that will be sent to the SAFE stage.
Review before the SAFE run
Hold an explicit review gate between build and SAFE execution. Confirm that the input package matches the approved source revision, that assumptions are still valid, and that the acceptance target for the run is still the right one.
This gate is where qualified engineers prevent expensive rework. A successful SAFE run on the wrong input is still a failed engineering delivery.
- Reconfirm source revision, soil assumptions, and build options.
- Name the checks and reports expected after a successful run.
- Confirm worker availability and licensed SAFE environment before launch.
Run SAFE in the configured environment
SAFE execution requires the licensed local environment connected through the AEIS Windows worker. The browser workspace coordinates the record; it does not replace the desktop analysis application.
Track worker availability, run identity, progress, cancellation, and failure state explicitly. Treat interrupted or ambiguous runs as incomplete until the engineering record shows a terminal success or a reviewed failure.
- Verify worker connectivity and SAFE license state before starting.
- Record run identity and link it to the frozen build package.
- Handle cancellation and failure as first-class outcomes, not silent timeouts.
Review checks, logs, and extracted results
After the run, inspect extracted results, foundation checks, and logs against the original source and approved assumptions. Governing utilizations, warnings, and unresolved messages belong in the review, not only in a success banner.
Compare the engineering story across stages: IFC intent, build idealisation, SAFE response, and check outcomes. Inconsistencies at any link are reasons to revise or rerun.
- Confirm the run completed successfully against the expected package identity.
- Review governing checks and open warnings with engineering ownership.
- Keep logs with the delivery record for later audit and rerun decisions.
Assemble reports and delivery artifacts
Collect SAFE inputs, run artifacts, extracted results, checks, logs, and foundation reports into one controlled package. Every issued file should belong to the approved run identity.
Do not mix artifacts from abandoned builds or partial reruns. Delivery credibility depends on package coherence as much as on individual numbers.
- Verify each artifact’s run identity before issue.
- Include the assumption and source revision notes with the report package.
- Exclude superseded files from the issued set.
Accept, revise, or rerun
A qualified engineer decides whether the foundation delivery is accepted, revised, or rerun. AEIS organizes the sequence and evidence; it does not certify the foundation design.
Document the decision and the basis for it. If the team revises source, soil springs, or build options, restart from the affected stage rather than patching the final report in isolation.
- Confirm the run completed successfully and matches the approved inputs.
- Review governing checks and unresolved warnings before issue.
- Verify every issued artifact belongs to the approved run.
- Record accept, revise, or rerun with clear engineering ownership.