Ordifile v0.5.1

Ordifile v0.5.1 — Consolidated researcher workflows

Ordifile v0.5.1 publishes the backward-compatible capabilities consolidated on main
after v0.5.0. It improves repeated local workflows, direct YoungIn chromatogram conversion,
mixed-vendor Preflight, and workbook integrity without changing the existing CLI, Python API,
or adapter API. Existing Recipe and Mapping JSON remain loadable, and established workbook
sheet names and one- and two-dimensional scientific semantics remain compatible.

Highlights

• Create and reuse a named Saved Setup directly in the desktop interface without writing
  JSON in the ordinary workflow.
• Convert validated YoungIn YL-Clarity PRM chromatograms directly to retention-time and
  detector-response series without a Clarity or YL-Clarity runtime installation.
• Distinguish exact, compatible scientific, compatible structural-only, unsupported,
  malformed, mapping-required, and drifted inputs before conversion.
• Keep otherwise identical Peak_Matrix columns separate when their Area units differ.
• Use the simplified Inputs → Output → Preflight → Convert desktop workflow with the
  public Ordifile application icon and researcher pilot guidance.

Saved Setup

The desktop interface can save the current reusable conversion configuration under a local
name before conversion or after a successful conversion. Confirmed generic table mappings are
collected automatically; multiple approved layouts are represented internally by the existing
Mapping Set contract. A saved setup remains available after restart and supports explicit
update, save-as-new, rename, duplicate, delete, import, and export operations.

Saved Setup uses the unchanged ConversionRecipe schema version 1. It does not store input
paths, output paths, or measured scientific rows. It can contain private column labels,
worksheet titles, or user metadata, so it remains local unless the researcher reviews it for
sharing. Storage failures do not block direct conversion, and concurrent or stale revisions
are not overwritten silently.

YoungIn PRM direct chromatograms

The validated YL-Clarity 9.0.1.19 and 9.1.0.76 PRM profiles share direct retention-time
and numeric detector-response semantics. The retention-time axis uses minutes. The validated
response units are:

Exact profile	FID	TCD
YL-Clarity 9.0.1.19	mV	mV
YL-Clarity 9.1.0.76	pA	mV

Strictly fingerprint-compatible unvalidated 9.x files may expose the compatible scientific
series with an unresolved response unit. A structurally safe file whose scientific fingerprint
is incomplete remains structural-only; incompatible or malformed input is rejected. This is
not a claim that all YL-Clarity or all 9.x versions are validated.

Ordifile does not derive Peaks, Area, or Height from PRM signals. Use the supported YoungIn
Result export path for explicit RT, Area, and Height results. No numerical integration,
automatic peak detection, signal-to-peak matching, or compound inference is performed.

Table intake and mixed-vendor integrity

Generic structured Result intake adds bounded Table Options for UTF-8/UTF-8-BOM, CP949,
or Windows-1252 text decoding, one-based header-record selection, and visible XLSX worksheet
selection. These explicit settings are stored with Mapping/Profile data and reused by Mapping
Sets and Saved Setup without scientific inference.

Preflight and conversion now share the same ownership and capability decisions. Unsupported
or malformed proprietary inputs are not reported as ready, exact adapters retain precedence,
and generic Mapping does not claim proprietary files. Scientific signals, explicit integrated
Results, and structural records remain separate in Signals, Peaks, and Signals_Records.

When Area units differ, Peak_Matrix creates separate columns instead of combining or
normalizing values. Underlying RT, Area, Height, and signal values are unchanged.

Compatibility

This release preserves:

• existing CLI commands and the public convert() API;
• ConversionRecipe schema version 1, its semantic-hash contract, and CLI --recipe;
• existing Mapping and Mapping Set JSON;
• Adapter API version 1;
• existing workbook sheet names and one- and two-dimensional scientific semantics.

Python 3.11 through 3.14 remain supported. Install the CLI/API package with:

python -m pip install ordifile==0.5.1

Install the optional Python-package desktop interface with:

python -m pip install "ordifile[gui]==0.5.1"
ordifile-gui

Boundaries

• Public Windows .exe, Windows standalone ZIP, macOS .app, and macOS application ZIP
  artifacts are not part of v0.5.1. The optional PyPI gui extra is included.
• Other proprietary adapters retain their exact evidence boundaries.
• No private fixture, workbook, Recipe, Mapping file, vendor binary, SDK, or executable is
  included in the wheel, source distribution, or release assets.
• Vendor and product names identify file-format compatibility only; no affiliation or
  endorsement is claimed.

Release provenance

The annotated-tag workflow builds the wheel and source distribution once, verifies the exact
wheel in clean CLI and GUI environments, publishes and verifies the same bytes on TestPyPI and
PyPI through Trusted Publishing, attests the distributions and checksums, and attaches the
verified files with SHA256SUMS.txt to the GitHub Release.

Ordifile v0.5.0

Ordifile v0.5.0 — Reusable mixed-result conversion workflows

Ordifile v0.5.0 is a backward-compatible feature release for repeated laboratory
conversion workflows. It connects exact Experimental Result adapters, explicit generic
peak-table mapping, reusable Mapping Profiles and Sets, deterministic preflight, local
Conversion Recipes, and one researcher-facing Excel workbook.

Highlights

• Adds an exact Experimental LECO ChromaTOF 4.72 GCxGC Result Text profile with explicit
  RT1/RT2 seconds and source Area/Height AU values.
• Adds an optional secondary retention coordinate and conditional
  Peak_Order_Matrix_2D output while preserving existing one-dimensional semantics.
• Adds explicit Generic Peak Table Mapping for user-selected RT and Area columns in the
  existing CSV, TSV, semicolon-TXT, and audited XLSX containers.
• Adds reusable Mapping Profiles, bounded Mapping Set JSON, exact structural routing,
  schema-drift diagnostics, and user-confirmed clone repair.
• Adds deterministic Conversion Preflight through ConversionPlan, CLI --dry-run,
  and the desktop review flow. Reviewed plans revalidate source, configuration, routing,
  and output state before conversion.
• Adds strict local ConversionRecipe JSON with optional embedded Mapping/Mapping Set
  configuration for repeated experiments. Recipes contain conversion behavior, not
  scientific source rows or input/output paths.
• Improves the existing workbook sheets with fixed headers, frozen identity columns,
  bounded widths, filters, a Samples entry tab, and a shared count-only result summary.
• Resolves the repeated macOS Python 3.14/PySide6 test termination report by preparing a
  clean Qt offscreen test environment before QApplication creation.

Exact Experimental Result boundaries

This release supports four specific Result profiles. These are exact-profile
compatibility statements, not broad manufacturer or file-extension claims.

Result profile	Controlled peak evidence	RT	Area	Height
Agilent ChemStation Result XML	36	min	pA*s	pA
Shimadzu LabSolutions Result ASCII	83	min	numeric, unit unresolved	numeric, unit unresolved
YoungIn YL-Clarity Result Table CSV	6	min	mV.s	mV
LECO ChromaTOF 4.72 GCxGC Result Text	100	RT1 s, RT2 s	AU	AU

The controlled scientific baseline is 225 peak rows across four exact vendor ecosystems,
four one-dimensional streams, and one two-dimensional stream. Actual privacy-bearing
fixtures remain outside Git and distributions; public tests use synthetic or otherwise
redistributable data. Ordifile performs no Area normalization, RT-based compound
inference, row interpolation, or unsupported unit/detector invention.

Explicit mapping and repeated templates

Unsupported structured Result tables can be converted only when the user explicitly
selects the RT and Area columns. A reusable Mapping Profile applies only to the same exact
structural fingerprint. A Mapping Set routes multiple approved templates; zero or
multiple matches fail closed. Exact Result adapter ownership remains authoritative.

When a template changes, Ordifile reports a schema-drift diagnostic. Repair requires an
explicit user review and creates a new profile without mutating the original. Generic
mapping does not establish exact vendor support.

Preflight and Conversion Recipes

The safe conversion sequence is:

Inputs + effective options
  -> Conversion Preflight
  -> review routes and known failures
  -> revalidate source/configuration/output state
  -> convert
  -> one Excel workbook

Dry run does not create a workbook or canonical scientific rows. A reviewed
ConversionPlan is same-process, immutable at its public boundary, and non-serializable.
Conversion fails closed when the plan is stale.

Recipes are strict, bounded UTF-8 JSON local configuration. They may embed an approved
Mapping or Mapping Set, but do not store scientific inputs, measured rows, absolute
source/output paths, overwrite authority, or serialized plans. Recipe display labels and
private semantic mapping identities are not copied into public workbook provenance.

Workbook behavior

• Manifest remains the first worksheet and Samples is the active researcher entry tab.
• Existing sheet names and one-dimensional scientific columns remain compatible.
• Peak_Order_Matrix_2D appears only when secondary retention coordinates are present.
• Numeric RT, Area, and Height values retain their canonical values and General display;
  presentation does not round or normalize scientific data.
• Recipe JSON, Recipe local paths, and full Conversion Plans are not stored in the workbook.

CLI, API, and desktop GUI

Existing commands and APIs remain available. Additive workflows include
--peak-mapping, --peak-mapping-set, --dry-run, and --recipe, plus the typed
ConversionPlan and ConversionRecipe APIs.

Install the command-line/API package with:

python -m pip install ordifile==0.5.0

Install the optional Python-package desktop GUI with:

python -m pip install 'ordifile[gui]==0.5.0'
ordifile-gui

The default wheel remains Qt-free. The GUI uses the same public conversion APIs and
adapter registry as the CLI. Public Windows .exe and macOS .app standalone artifacts
are not included in v0.5.0; Issue #6 remains open for that separate distribution scope.

Compatibility, privacy, and licensing

• Python 3.11–3.14 is validated in continuous integration.
• Existing generic conversion, exact adapters, CLI commands, public function signatures,
  Mapping JSON schemas, Adapter API v1, and one-dimensional workbook semantics remain
  compatible.
• No private fixture, Recipe, mapping file, workbook, vendor binary, SDK, or executable is
  included in the wheel, source distribution, or release assets.
• Vendor and product names identify file-format compatibility only; no affiliation or
  endorsement is claimed.
• Ordifile remains Apache-2.0 and includes LICENSE, NOTICE, and
  THIRD_PARTY_NOTICES.md in both distributions.

Release provenance

The annotated-tag workflow builds the wheel and source distribution once on the reviewed
DGX environment and verifies the exact wheel in clean CLI and GUI environments. It
publishes and verifies the same immutable bytes on TestPyPI, attests them, and attaches
them with SHA256SUMS.txt to a draft GitHub Release. Only after those same bytes are
published and independently verified on PyPI does the workflow make that draft public.
No native standalone binary is part of this release.

Ordifile v0.4.0

Ordifile v0.4.0 — Three-vendor results and an offline desktop interface

Ordifile v0.4.0 adds a third exact Experimental Result adapter and the first optional
offline desktop interface. Agilent, Shimadzu, and YoungIn Result rows now use the same
canonical conversion and workbook pipeline from both the CLI and GUI.

Highlights

• Adds the exact owner-validated YoungIn YL-Clarity Result Table CSV profile.
• Preserves explicit YoungIn RT min, Area mV.s, Height mV, source signal
  sections, and source observation order.
• Confirms the actual cross-vendor baseline of 36 Agilent + 83 Shimadzu + 6 YoungIn
  rows: 125 Peaks rows and four populated Peak_Order_Matrix streams.
• Adds the Experimental PySide6 Qt Widgets desktop interface with files, folders,
  drag and drop, registry-backed preview, background conversion, progress, partial
  failure reporting, and output opening.
• Adds public inspect_inputs() and shared BatchOutcome behavior so the CLI and GUI
  use the same discovery, detection, parsing, sorting, and workbook implementation.

Exact YoungIn Result boundary

The supported bytes are one owner-validated profile: CP949-compatible, no BOM, CRLF,
tab-delimited .csv exports with repeated nine-column Result Table headers, explicit
signal sections, Total/no-peak rows, and the observed trailer grammar. The two local
exports contain six actual peak rows.

The bytes do not contain a producer or version marker. This release therefore does
not claim broad YL-Clarity CSV compatibility. It also does not:

• promote source Signal Name values to verified detector identity;
• interpret W05 as an integration boundary;
• use percentages or Total rows as peak Area;
• infer compounds from empty compound-table headers or retention-time similarity; or
• require a PRM sibling or vendor application for Result-only conversion.

The actual owner exports remain local-only. Public tests use independently constructed
synthetic fixtures, and privacy-sensitive sources retain SHA-derived public identity.

Three-vendor Result workbook

The controlled actual regression preserves:

Result profile	Peak rows	RT unit	Area unit	Height unit
Agilent ChemStation Result XML	36	min	pA*s	pA
Shimadzu LabSolutions Result ASCII	83	min	unresolved	unresolved
YoungIn YL-Clarity Result Table CSV	6	min	mV.s	mV

The workbook has 125 Peaks rows and four populated Peak_Order_Matrix streams.
Unlike or unresolved Area units remain separate. No normalization, RT matching, or
compound inference is performed.

Experimental desktop interface

Install the optional GUI dependency separately:

python -m pip install --no-cache-dir 'ordifile[gui]==0.4.0'
ordifile-gui

The default pip install ordifile==0.4.0 remains Qt-free. The GUI calls public
Ordifile APIs and the core adapter registry; it has no vendor-specific parser or
hard-coded adapter inventory. The interface is offline-only and has no upload,
telemetry, cloud, embedded browser, shell, or vendor-executable integration.

PySide6-Essentials==6.11.2 and its exact shiboken6 companion are optional
LGPL/GPL/commercial-license distributions installed by the package manager. Ordifile
does not bundle their binaries. Standalone .exe/.app artifacts, Qt redistribution,
signing, notarization, and clean-machine packaging remain future Issue #6 work.

Compatibility and upgrade notes

• Existing generic CSV, TSV, semicolon TXT, and audited XLSX behavior is unchanged.
• Existing Agilent and Shimadzu exact Experimental adapters retain their documented
  boundaries.
• YoungIn raw PRM structural conversion remains independent of Result CSV support.
• Python 3.11–3.14 remains supported.
• Existing CLI commands remain available and do not import Qt.

Privacy, fixtures, and licensing

• Actual YoungIn exports, all native vendor fixtures, and generated external
  workbooks remain outside Git, Actions artifacts, wheels, and source distributions.
• Private filenames, paths, operators, samples, and non-allowlisted trailer metadata
  are not exported to public provenance.
• No vendor binary, SDK, executable, protected implementation, or copied copyleft
  parser code is included.
• Vendor and product names identify compatibility only; no affiliation or endorsement
  is claimed.
• Ordifile remains Apache-2.0 and includes LICENSE, NOTICE, and
  THIRD_PARTY_NOTICES.md in both distributions.

Release provenance

The normal annotated-tag workflow builds the wheel and source distribution once on
DGX, verifies the same wheel in a clean environment, and publishes immutable bytes
through TestPyPI, PyPI, and the public GitHub Release only after all gates pass. This
release preparation does not itself create a tag or publish any package.

Ordifile v0.3.1

Ordifile v0.3.1 — Cross-vendor result release with corrected package verification

Ordifile v0.3.1 publishes the reviewed v0.3 result-first feature set with a corrected,
deterministic installed-package verification path. The scientific adapters and
canonical workbook behavior are unchanged from the reviewed v0.3.0 source.

Why v0.3.1

The immutable annotated v0.3.0 tag built and tested successfully, passed DGX wheel
smoke, and published byte-identical wheel and source distributions to TestPyPI. The
workflow stopped after installation because its verifier searched the host PATH for
ordifile, while the isolated environment intentionally does not alter PATH.

Version 0.3.0 was never published to PyPI and has no GitHub Release. Its tag and
TestPyPI files remain unchanged as an audit record. Version 0.3.1 resolves the console
entry point from the active isolated Python environment's scripts directory and tests
that behavior with the scripts directory absent from PATH.

Cross-vendor result highlights

• Converts the exact supported Agilent ChemStation Result XML and Shimadzu
  LabSolutions Result ASCII profiles without requiring native raw siblings.
• Maps explicit retention time and peak area rows through the same canonical
  PeakRecord, Peaks, Peak_Order_Matrix, and explicit-compound Peak_Matrix
  pipeline.
• Keeps raw adapters independent and accepts mixed raw and result inputs in one batch.
• Adds the Experimental YoungIn YL-Clarity .PRM structural converter while leaving
  YoungIn result RT and area unsupported pending an actual result export fixture.

Controlled external validation combined 36 Agilent result rows and 83 Shimadzu result
rows into one workbook: 119 Peaks rows and two independent
Peak_Order_Matrix streams. The workbook reopened successfully without exposing
privacy-bearing source identities.

Result-first workbook output

exact vendor Result Adapter
  -> canonical PeakRecord
  -> Peaks / Peak_Order_Matrix / Peak_Matrix
  -> one Excel workbook

Peak_Order_Matrix preserves original observation order as atomic RT/area pairs with
manufacturer, detector, channel, RT-unit, and area-unit provenance. Peak_Matrix
continues to contain only explicit compound assignments. Ordifile does not infer
compound identity from similar retention times.

Exact Experimental boundaries

Adapter	Exact tested profile	Result or signal output	Explicitly unsupported
Agilent ChemStation Result XML	C.01.10 [201], one FID1/A, Percent/Area	Result RT min, Area pA*s, Height pA, start/end, observation order, non-empty calibrated names	other revisions, multiple signals/detectors, other quantitation modes, raw data, automatic pairing
Shimadzu LabSolutions Result ASCII	5.82 Data File, GC-2014, one SFID1 / Ch1	Peak#, Result RT/start/end min, raw Area and Height, observation order	other versions/instruments/channels, physical Area/Height units, compound identity for the tested blank-ID profile, raw data, automatic pairing
YoungIn YL-Clarity .PRM	observed 9.0.1.19 structural profile	ordered stored binary32 records and allowlisted stored labels	RT, area, peaks, time axis, scaling, physical unit, verified detector semantics
Agilent ChemStation .CH	internal v181 exact GC-FID profile	structural record index and raw integer	RT, scaling, physical unit, peak results, other versions
Shimadzu LabSolutions .GCD	5.82, GC-2014, single SFID1	chromatogram RT min and signal uV	peak results and untested profiles
Shimadzu GCMSsolution .QGD	exact File Property 4.00 TIC profile	RT min and native TIC integer	physical TIC unit, scientific MS1/m/z export, identification, quantitation

These are exact-profile compatibility statements, not general support claims for a
manufacturer, product family, or file extension.

Units and scientific limits

• Agilent Result Area retains pA*s; Height retains pA.
• Shimadzu Result Area and Height retain numeric source values, but their physical
  units remain unknown.
• YoungIn result RT and area remain unsupported.
• Ordifile does not normalize or directly equate areas with different or unknown
  units, and it does not merge peaks by RT similarity.

Privacy, fixtures, and licensing

• Privacy-sensitive vendor sources use content-derived public SHA-256 identities;
  private basenames, paths, operators, sample identities, and non-allowlisted metadata
  are excluded from public workbook and diagnostic surfaces.
• External Agilent and Shimadzu result fixtures remain controlled validation inputs
  under their documented upstream repository license boundaries. YoungIn owner data
  remains local-only.
• No external fixture, generated workbook, proprietary implementation, or copyleft
  implementation code is included in the source tree, wheel, or source distribution.
• Ordifile remains Apache-2.0 licensed and is not affiliated with or endorsed by the
  named instrument vendors.

Installation

After the v0.3.1 release workflow completes successfully, install from PyPI in a clean
Python 3.11–3.14 environment:

python -m pip install --no-cache-dir ordifile==0.3.1
ordifile --version
ordifile formats

Checksums and provenance

The normal annotated-tag workflow builds the wheel and source distribution once on
DGX, exercises that same wheel, and publishes the same immutable bytes through
TestPyPI and PyPI using Trusted Publishing. SHA256SUMS.txt, exact index byte checks,
GitHub build-provenance attestations, and final GitHub Release asset checks protect the
distribution identity. The historical v0.2.1 recovery modes are not used for v0.3.1.

License

Ordifile is distributed under the Apache License 2.0. The wheel and source distribution
include LICENSE, NOTICE, and THIRD_PARTY_NOTICES.md.

Ordifile v0.2.1

Ordifile v0.2.1 — Experimental GC instrument readers

Ordifile v0.2.1 adds three narrowly bounded Experimental proprietary readers while
retaining the verified generic table-conversion workflow from v0.1.0. Experimental
means exact tested profiles only: unsupported variants are rejected, fixture coverage
is intentionally limited, and each capability is documented separately.

No earlier v0.2-series package was published. The protected v0.2.0 tag remains an
unpublished audit record after its workflow stopped before artifact build or upload.

Highlights

• Adds an Experimental Shimadzu LabSolutions 5.82 .GCD reader for one exact
  GC-2014, single-SFID1 profile. It exports all 66,255 source retention-time and
  uV chromatogram points without interpolation and was compared point by point with
  a same-run LabSolutions ASCII reference.
• Adds an Experimental Shimadzu GCMSsolution .QGD TIC reader for one exact File
  Property 4.00 profile. It exports all 16,800 source retention-time and unsigned TIC
  values. The physical TIC unit is unknown. MS1 blocks are validated structurally but
  spectra are not exported and encoded mass is not called m/z.
• Adds an Experimental Agilent ChemStation .CH internal-v181 structural decoder for
  one exact GC-FID profile. It exports decoded record ordinals and raw integers, not
  retention time, scaled signal, or a physical unit.
• Keeps the core batch workflow: multiple supported inputs become one ordered,
  auditable Excel workbook with source hashes, provenance, and per-file failure
  isolation.

Exact Experimental boundaries

Reader	Tested boundary	Output	Explicitly unsupported
Agilent ChemStation .CH	internal version 181, exact tested GC-FID profile	structural decoded record index + raw integer	retention time, scaling, unit, peaks, other versions, .D, TCD/MS
Shimadzu LabSolutions .GCD	5.82, File Property 5.01, GC-2014, single Ch1/SFID1, identity factors	retention time in minutes + uV signal	other versions, factors, units, detectors, channels, multichannel, peaks
Shimadzu GCMSsolution .QGD	File Property 4.00, exact 16,800-scan profile	retention time in minutes + raw unsigned TIC	physical TIC unit, scientific MS1/m/z, SIM/MRM, identification, quantitation

These rows are not umbrella Agilent or Shimadzu support claims. See the format pages in
docs/formats/ for detection, output, warning, and corruption boundaries.

Validation and supply-chain controls

• Every native fixture remains outside Git and release distributions.
• Maintainer-only DGX workflows fetch only reviewed URLs with exact file size,
  SHA-256, and license acknowledgement, upload no raw fixture artifact, and clean the
  fixture cache after the job.
• Proprietary parsers enforce bounded files, containers, streams, counts, offsets, and
  record lengths. Malformed files fail independently without corrupting unrelated
  batch output.
• GPL/LGPL readers were research comparisons only. No GPL/LGPL implementation is
  copied, translated, bundled, or added as a runtime dependency.
• Release distributions are built once, verified, installed in a clean environment,
  published unchanged through TestPyPI and PyPI Trusted Publishing, and accompanied by
  checksums and GitHub attestations.

Installation

After the release workflow completes successfully:

python -m pip install --no-cache-dir ordifile==0.2.1
ordifile --version
ordifile formats

Python 3.11 through 3.14 are supported package targets. The release CI and external
real-fixture workflows run on the shared Linux ARM64 DGX runner with Python 3.14.

Upgrade notes

This is a backward-compatible feature release. Existing generic CSV, TSV, TXT, and
XLSX conversion commands remain unchanged. Proprietary readers are built-in but remain
Experimental; applications should inspect adapter status and structured warnings rather
than assuming all files with a matching extension are supported.

YoungIn/YL-Clarity remains unsupported pending a real native fixture and paired vendor
exports. QGD MS1 scientific export remains deferred until independent m/z evidence and
a bounded, lossless workbook representation are available.

License

Ordifile is distributed under the Apache License 2.0. The wheel and source distribution
include LICENSE, NOTICE, and THIRD_PARTY_NOTICES.md.

Ordifile v0.1.0

Ordifile v0.1.0

Ordifile v0.1.0 is the first public package release of the batch converter for
documented scientific-instrument table exports.

Highlights

• Discovers multiple files or folders and continues past ordinary per-file failures.
• Detects verified generic CSV, TSV, semicolon-delimited TXT, and non-macro XLSX tables
  by content and documented schema, not extension alone.
• Sorts by acquisition time, sequence, natural filename, or input order with recorded
  fallback provenance.
• Produces one ordered Excel workbook with audit information and source SHA-256 values.
• Provides ordifile formats, ordifile inspect, and ordifile convert for automation.
• Supports external adapters through the ordifile.adapters entry-point group without
  coupling format parsers to Excel output.

Installation

After the release workflow has completed successfully, install the exact release from
PyPI in a clean Python 3.11–3.14 environment:

python -m pip install --no-cache-dir ordifile==0.1.0
ordifile --version
ordifile formats

Verified input formats

The built-in adapters support only the documented Ordifile generic schema in these
containers:

• UTF-8 or UTF-8-BOM comma-delimited .csv;
• UTF-8 or UTF-8-BOM tab-delimited .tsv;
• UTF-8 or UTF-8-BOM semicolon-delimited .txt;
• audited transitional, non-macro .xlsx with one explicitly selected or unambiguous
  compatible worksheet.

Peaks require explicit peak columns. Signals require explicit time and signal columns.
Unknown fields and invalid raw lexemes are retained as provenance instead of being
assigned invented scientific meanings. Generic means the documented Ordifile schema,
not arbitrary vendor exports.

Workbook output

The default output is Ordifile_Result.xlsx. It contains:

• Manifest
• Samples
• Peak_Matrix
• Peaks
• Metadata
• Import_Log
• Signals_<channel> only when signal output is requested and signal rows were parsed

The workbook records the requested and effective ordering, fallbacks, adapter identity,
file status, warnings and errors, source hash, output limits, and any explicit sidecar.
Rows and columns are split before Excel limits are reached; data is not silently
truncated.

Safety and integrity behavior

• Inputs are read-only and checked for mutation during processing.
• Symbolic links are rejected, duplicate file identity is reported, and equal content
  alone is not silently deduplicated.
• One ordinary parse failure is isolated so valid inputs can still produce an explicitly
  partial workbook.
• Formula-like output remains literal text with formula and URL conversion disabled.
• XLSX packages pass bounded ZIP, relationship, namespace, coordinate, type, numeric,
  date, formula, and resource audits before a worksheet is parsed.
• Original signal axes and values are retained without interpolation.
• Every release distribution is built once, hashed, tested from the wheel outside a
  source checkout, and reused for TestPyPI, PyPI, and the GitHub Release.

Known limitations and unsupported formats

• Proprietary vendor raw formats are not supported in v0.1.0.
• A desktop GUI is not included in v0.1.0.
• Generic means the documented Ordifile schema, not arbitrary vendor exports.
• One input file represents one sample.
• Text encoding and delimiter guessing are not performed.
• Units are copied, not converted.
• Compound identity is never inferred from retention time, and repeated compounds are
  never silently aggregated.
• XLSX macros, templates, Strict OOXML, unsupported namespace variants, and formula
  evaluation are not supported.
• GC proprietary adapter research does not constitute format support.

See the generic format contract
for the precise schema and safety limits.

Upgrade notes

This is the first packaged release. No legacy package or CLI alias is provided. Source
users should install into a new virtual environment and invoke ordifile.

Checksums and provenance

The GitHub Release includes the wheel, source distribution, and SHA256SUMS.txt.
Verify the downloaded files against that manifest before installation. The tag workflow
also creates GitHub artifact attestations for the distribution files and checksum
manifest.

License

Ordifile is distributed under the Apache License 2.0. The wheel and source distribution
include LICENSE, NOTICE, and THIRD_PARTY_NOTICES.md.