1. Declared steps — what runs, in what order, from which inputs
2. Pinned software — the same tool versions every time
3. Rerun logic — only redo what changed Snakemake handles all three. Here's a minimal paired-end RNA-seq workflow: trim reads with fastp, then quantify transcripts with Salmon. Layout project/ ├── Snakefile ├── envs/ │ ├── fastp.yaml │ └── salmon.yaml ├── data/ # {sample}_R1.fastq.gz, {sample}_R2.fastq.gz └── ref/ └── salmon_index/ The Snakefile SAMPLES = ["ctrl_1", "ctrl_2", "treat_1", "treat_2"]

rule all: input: expand("results/salmon/{sample}/quant.sf", sample=SAMPLES)

rule fastp: input: r1="data/{sample}_R1.fastq.gz", r2="data/{sample}_R2.fastq.gz" output: r1="results/trimmed/{sample}_R1.fastq.gz", r2="results/trimmed/{sample}_R2.fastq.gz", html="results/qc/{sample}.fastp.html", json="results/qc/{sample}.fastp.json" conda: "envs/fastp.yaml" threads: 4 shell: "fastp -i {input.r1} -I {input.r2} -o {output.r1} -O {output.r2} " "-h {output.html} -j {output.json} -w {threads}"

rule salmon_quant: input: r1="results/trimmed/{sample}_R1.fastq.gz", r2="results/trimmed/{sample}_R2.fastq.gz", index="ref/salmon_index" output: "results/salmon/{sample}/quant.sf" params: outdir="results/salmon/{sample}" conda: "envs/salmon.yaml" threads: 8 shell: "salmon quant -i {input.index} -l A -1 {input.r1} -2 {input.r2} " "-p {threads} --validateMappings -o {params.outdir}" Snakemake works backwards from rule all: it sees which quant.sf files are missing, figures out they need trimmed reads, and schedules fastp first. Pinned environments envs/salmon.yaml: channels:

• conda-forge

• bioconda dependencies:

• salmon=1.10.3 envs/fastp.yaml follows the same pattern with fastp=0.23.4. Pin whichever versions you've actually tested; the point is that the version is written down, not which one it is. Run it Always dry-run first. It shows what would execute without running anything: snakemake -n --cores 8 For these four samples, that plans 9 jobs: 4 × fastp, 4 × salmon_quant, and the final all. Then run for real with conda environments enabled (--sdm conda in Snakemake 8 and later; older versions use --use-conda): snakemake --cores 8 --sdm conda Change one sample's input and rerun: only that sample's jobs execute again.

• What to add next

• Move SAMPLES into a config.yaml or sample sheet

• Add a MultiQC rule to summarise the fastp reports

• Add log: directives so failures are traceable

• Containerise for clusters where conda is awkward

• Run the dry run in CI on every push

• Putting this on a resume

  Hiring managers for computational biology roles often check your GitHub, and a repo like this says more than "proficient in Snakemake." On the resume itself, describe pipelines by what they guarantee and at what scale: number of samples processed, runtime cut, environments pinned, adoption by other people.

  For a full layout, avua's computational biologist resume example includes a sample resume with a dedicated technical proficiencies section, a bank of quantified achievement bullets that includes pipeline and workflow automation work, and a common-mistakes table that flags a missing GitHub link. Useful for seeing how reproducibility work reads as impact rather than housekeeping.

  Which workflow manager do you use — Snakemake, Nextflow, something else — and how do you pin environments?

It's tempting to read that as "the model is full of problems." More often it means the clash rules are noisy. The hard part of coordination isn't finding clashes. It's turning them into a short list of real issues, each with an owner, and driving them to closure.

Quick context: what is federation?

On a big project, each discipline (civil, structural, mechanical, piping, electrical, equipment) builds its own model. A BIM coordinator federates them: combines them into a single coordinated view, typically in tools like Navisworks, and runs automated checks for geometric conflicts.

A clash is usually one of two kinds:

• Hard clash: two objects physically intersect (a pipe through a beam)
• Clearance clash: an object intrudes on required space (maintenance access, insulation, a hoist path)

Why raw clash counts mislead?

Common sources of noise:

1. Intended intersections. Pipe supports meeting steel, or cables entering trays, are often designed to touch.
2. Duplicates. One misplaced duct can register as dozens of clashes against each element it crosses.
3. Wrong tolerances. Zero-tolerance tests flag tiny overlaps that don't matter on site.
4. Stale models. A supplier model in the wrong coordinate system or an out-of-date revision generates false hits.

If you send 10,000 clashes to a design team, the useful 40 get lost.

Step 1: write rules that ask real questions

Instead of "everything vs everything," build targeted tests:

• Large-bore piping vs primary structure (hard, low tolerance)
• Equipment vs maintenance-access zones (clearance)
• Cable tray vs HVAC duct (hard, with a sensible tolerance)
• Exclude known-intended pairs (supports vs their supporting steel)

Each test should map to a question someone actually needs answered.

Step 2: group and triage

Group individual hits into issues, such as all clashes caused by one duct run. Then triage:

That last row matters: every false positive should improve your rules, not just get closed.

Step 3: assign one owner per issue

An issue without an owner doesn't get fixed. Record for each one:

{

  "issue_id": "CL-0142",

  "description": "Duct run clashes with secondary steel, level 2",

  "disciplines": ["HVAC", "Structural"],

  "owner": "HVAC lead",

  "priority": "High",

  "status": "Open",

  "target_model_revision": "P05"

}

Then re-run the test on the next model drop and confirm closure from the model, not from a status update.

Step 4: control the inputs

Coordination only works if everyone federates the right files. That means checking supplier models for format, coordinates and data, and making sure only approved, current deliverables are published to the Common Data Environment (CDE). On projects following ISO 19650, the BIM Execution Plan sets these rules.

Why it matters more on nuclear projects?

On a nuclear build, a clash found on site isn't just rework. Fixing it may require a formal design change, re-analysis or extra inspection, and the plant may be very hard to modify later. Coordinators there also deal with security-controlled information and strict configuration control. The fundamentals are the same, but the cost of a missed clash is higher.

If you're a developer or digital-engineering specialist curious about this work, this overview of the BIM coordinator role on nuclear projects covers the tools, standards and routes in.

Takeaways

• A big clash count usually signals noisy rules, not a broken model.
• Write targeted tests that each answer a real question.
• Group hits into issues, triage them, and give each one owner.
• Confirm closure by re-running the test on the next model.
• Feed every false positive back into your rules.

What's the worst clash report you've ever been handed? Bonus points if it had a five-digit count.

\

In an Enterprise Asset Management (EAM) system that runs a power plant, that feeling can be misleading. A record can be internally perfect and still point to the wrong physical equipment.

This post looks at why, using the kind of structures found in IBM Maximo, SAP EAM and similar platforms.

What an EAM system actually holds?

An EAM platform is the digital record of physical assets and the work done on them. The core objects are usually:

• Locations: where something sits in the plant (a system, a room, a functional position)
• Assets: the physical item installed there, often with a serial number
• Hierarchy: parent-child relationships (system → subsystem → component)
• Job plans: the standard steps for a type of work
• Preventive maintenance (PM) records: rules that generate work orders on a schedule or meter reading
• Work orders: the actual instruction a technician receives

The PM record is where data quality stops being academic. It generates real work.

Failure mode 1: the hierarchy is valid but wrong

Say a pump is replaced during an outage. The new asset is created and attached to a location, but the old record is never retired. Both records are valid. Both have parents. Now a PM tied to the old asset keeps generating work orders against equipment that no longer exists, while the new pump has no PM at all.

No validation rule catches this, because nothing is syntactically wrong.

A simple reconciliation query helps surface candidates:

-- Locations with more than one active asset installed

SELECT location, COUNT(*) AS active_assets

FROM asset

WHERE status = 'ACTIVE'

GROUP BY location

HAVING COUNT(*) > 1;

Table and column names vary by platform and configuration; treat this as a pattern, not copy-paste code.

Failure mode 2: the PM trigger is plausible but drifting

A meter-based PM fires every 2,000 running hours. Someone changes the meter reading unit during a migration. The trigger still fires, just at the wrong interval. Again, every field is populated and every value is in range.

The fix isn't a stricter constraint. It's a reconciliation step after any change that touches meters, units or frequencies, plus reporting that watches for PM intervals changing unexpectedly.

Failure mode 3: migration preserves records but loses meaning

Platform upgrades are a big source of this. Many nuclear operators are moving from older Maximo Nuclear versions to Maximo Application Suite. Record counts can match perfectly after conversion while relationships, status semantics or workflow states shift underneath.

Good migration practice reconciles more than counts:

1. Row counts per object type
2. Critical fields (criticality, classification, status) per asset class
3. Parent-child relationships for a sample of complex systems
4. Active PMs and their next-due dates before vs after
5. Workflow states for open work orders

The principle: system accuracy ≠ asset accuracy

The strongest analysts in regulated industries treat the database as a claim about the plant, and they check that claim against independent evidence: drawings, equipment lists, walkdown records, engineering documents.

This is why domain knowledge matters so much in these roles. A Maximo consultant can configure a workflow. A maintenance planner understands the plant. The person who understands both (why the hierarchy drives PM generation, how isolation and permit workflows interact with work orders) is much harder to find.

Where this matters most?

In high-consequence environments like nuclear, an incorrect PM or hierarchy isn't bad data. It can send work to the wrong component, hide overdue maintenance or break the link between a job and the safety controls around it. Nuclear EAM configurations can include technical specifications, surveillance, clearances and corrective-action processes, so the blast radius of a bad record is larger.

If you're a developer or data analyst curious about moving into this space, this profile of the nuclear asset management systems analyst role covers the platforms, skills and routes in.

Takeaways

• Validation proves internal consistency, not physical truth.
• Reconcile after every change that touches hierarchy, meters or PM frequency.
• In migrations, reconcile relationships and semantics, not just counts.
• Domain knowledge isn't a nice-to-have; it's how you spot data that's "valid" but wrong.

What's the most convincing "valid but wrong" record you've ever found? Drop it in the comments.

\

The categories map neatly too: Range checks — a value outside a plausible window (heart rate of 0 or 400) Cross-field checks — logical consistency (an adverse event end date before its start date) Cross-form checks — a medication listed as "for adverse event #3" when AE #3 doesn't exist Protocol checks — a visit outside its allowed window relative to randomisation A minimal Python version EDC systems have their own check-building tools, but CDMs and programmers increasingly use Python or SAS for offline listings and secondary checks. Here's an illustrative example on a flattened export: import pandas as pd

def check_ae_dates(ae: pd.DataFrame) -> pd.DataFrame: """Cross-field check: AE end date must not precede start date.""" ae = ae.copy() ae["AESTDTC"] = pd.to_datetime(ae["AESTDTC"], errors="coerce") ae["AEENDTC"] = pd.to_datetime(ae["AEENDTC"], errors="coerce") bad = ae[ae["AEENDTC"].notna() & (ae["AEENDTC"] < ae["AESTDTC"])] return bad.assign(QUERY="AE end date is before start date. Please verify.")

def check_sbp_range(vs: pd.DataFrame, low=60, high=250) -> pd.DataFrame: """Range check on systolic blood pressure (mmHg).""" sbp = vs[vs["VSTESTCD"] == "SYSBP"] bad = sbp[(sbp["VSORRES"].astype(float) < low) | (sbp["VSORRES"].astype(float) > high)] return bad.assign(QUERY=f"Systolic BP outside {low}-{high} mmHg. Please verify.") The column names follow CDISC SDTM conventions (AESTDTC, VSTESTCD), which is the standard structure many sponsors submit to regulators. The thresholds are placeholders; real ones come from the protocol and the study's Data Validation Plan. And yes, you should test your tests: def test_ae_end_before_start_flags(): df = pd.DataFrame({"USUBJID": ["001"], "AESTDTC": ["2026-03-10"], "AEENDTC": ["2026-03-01"]}) assert len(check_ae_dates(df)) == 1 In regulated work, check logic is typically documented and validated before go-live — the equivalent of a reviewed, version-controlled test suite. Where developers fit in? If you come from software, the transferable skills are real: writing deterministic validation logic, thinking in edge cases, version control, and reading a spec carefully. What you'd need to learn is the domain — GCP, CDISC standards, how sites actually enter data, and what "database lock" means for change control. Putting this on a resume Most CDMs undersell this work as "performed data cleaning." It's more specific than that. Bullets that name the check categories, the EDC platform, the standards (CDASH/SDTM), the query volume handled and the milestone hit (on-time database lock) read far more clearly to a hiring manager. For a full layout, avua's clinical data manager resume example includes a sample resume, a skills breakdown and a bank of quantified achievement bullets you can adapt - useful for seeing how to describe validation work in a way that reads as engineering, not admin. If you work in pharma or CRO data: which EDC do you use, and do you unit-test your offline checks? Curious how others handle it.

• Built ETL pipeline for large datasets
• Wrote scripts to clean and transform data If any of that work touched biological data, coursework or a side project, name it in domain terms:
• Built a Snakemake pipeline aligning [N] RNA-seq samples to GRCh38 with STAR, cutting per-batch runtime from [X] to [Y] hours
• Wrote Python QC scripts flagging low-quality FASTQ files (Phred < [threshold]) before alignment Same engineering, but now a reviewer can see file formats, tools and a reference genome. That's what an ATS and a lab lead both scan for. Refactor 2: Separate interfaces from implementation Put a Core Competencies block near the top, grouped so it's scannable: Languages: Python (pandas, Biopython), R (Bioconductor), SQL, Bash Workflow: Nextflow or Snakemake, Docker, Git Analysis: sequence alignment, variant calling, differential expression, statistics Data sources: NCBI, Ensembl, UniProt, public GEO datasets Only include what you've actually used. Bioinformatics interviews often include a practical task, and a padded skills list shows up fast. Refactor 3: Document like it's going to production Your GitHub is part of the application. Pick one or two repos and treat them like a release: A README stating the biological question, the dataset (with accession numbers for public data) and how to run it A pinned environment file or container so results reproduce A short results section: a plot and two sentences on what it shows A single reproducible analysis of a public dataset is worth more than a dozen tutorial forks. Don't skip the biology You don't need a biology degree for every analyst role, but you do need to show you understand what the data represents. A line under Education or Training listing relevant coursework (molecular biology, genetics, statistics) or a completed course helps a reviewer trust your outputs. Reference implementation If you want a full worked example to diff against, avua's bioinformatics analyst resume guide has a complete sample resume, achievement bullets you can adapt, and an ATS formatting checklist. Next step: open a branch of your resume, apply the three refactors and see how many bullets survive unchanged. Usually it's not many.

We'll use energy contract roles in Oman as the running example, but the pattern works for any sector.

The query model

A focused job search has four parts:

Specialization + Sector + Location + Employment type

Each part has synonyms. An "Electrical Engineer" might be listed as "E&I Engineer", and "contract" might appear as "contractor" or "fixed-term". A good generator expands each part into an OR group and joins the groups with AND.

The synonym map javascript const SYNONYMS = { employment: { contract: ["contract", "contractor", "fixed-term", "project-based"], permanent: ["permanent", "full-time", "staff"], }, sector: { energy: ["energy", "power", "utilities"], oilgas: ["oil and gas", "O&G", "upstream", "downstream"], renewables: ["renewable", "solar", "wind"], nuclear: ["nuclear", "NPP"], }, role: { electrical: ["Electrical Engineer", "E&I Engineer", "Electrical Supervisor"], hse: ["HSE Engineer", "HSE Officer", "Safety Engineer"], project: ["Project Engineer", "Project Manager", "Site Engineer"], commissioning: ["Commissioning Engineer", "Start-up Engineer"], }, }; Building the query javascript const quote = (term) => (term.includes(" ") ? "${term}" : term);

const orGroup = (terms) => terms.length === 1 ? quote(terms[0]) : (${terms.map(quote).join(" OR ")});

function buildQuery({ role, sector, location, employment }) { const parts = [ SYNONYMS.role[role], SYNONYMS.sector[sector], [location], SYNONYMS.employment[employment], ].filter(Boolean);

return parts.map(orGroup).join(" AND "); }

console.log( buildQuery({ role: "electrical", sector: "energy", location: "Oman", employment: "contract", }) );

Output:

("Electrical Engineer" OR "E&I Engineer" OR "Electrical Supervisor") AND (energy OR power OR utilities) AND Oman AND (contract OR contractor OR fixed-term OR project-based) Generating variations in bulk

A single query misses listings that use different wording, so generate every role and sector combination:

javascript function buildAll({ roles, sectors, location, employment }) { return roles.flatMap((role) => sectors.map((sector) => ({ role, sector, query: buildQuery({ role, sector, location, employment }), })) ); }

const queries = buildAll({ roles: ["electrical", "hse", "project"], sectors: ["energy", "oilgas", "renewables"], location: "Oman", employment: "contract", });

console.table(queries);

That produces nine focused queries from one config object.

Platform caveats Google supports OR, quotes, and parentheses. AND is implicit, but writing it explicitly does no harm. LinkedIn supports full Boolean in keyword search. The operators must be uppercase. Most job boards support only partial Boolean. If results look strange, drop the parentheses and run the groups separately. Keep queries under about 32 terms. Google silently ignores anything past that. Extending it

A few ideas if you want to take it further:

Add a NOT group to exclude noise such as -intern -trainee Build URL-encoded search links for specific sites with encodeURIComponent Load the synonym map from JSON so non-developers can edit it Wrap it in a small form UI so candidates can generate their own strings

The takeaway: structured inputs plus synonym expansion beat hand-typed searches every time. The same pattern powers sourcing tools and job-matching filters. At avua we apply similar structured matching across energy and technical roles, and you can see how contract listings are organized on avua's contract jobs page.