Project Bourne v0.8.1::: MCP Metadata and Tool Discoverability

Project Bourne v0.8.1 — MCP Metadata and Tool Discoverability

This patch release improves how Project Bourne’s MCP server is presented to MCP clients and catalogs such as Glama. It does not change scientific execution behavior.

Improvements

• Added glama.json repository metadata and a Glama README badge.
• Expanded the descriptions for:
  • bourne_site_discover
  • bourne_site_policy_claim
  • bourne_site_candidates
  • bourne_site_select
• Documented tool preconditions, persistence behavior, side effects, lifecycle, and relationships with adjacent tools.
• Added descriptions for top-level and nested policy, provider, inventory, selection, and container parameters.
• Clarified that candidate sessions are ephemeral, selected plans are immutable, policy claims are durable, and selection does not execute a workload.
• Added regression tests for the MCP schemas visible to Glama and other MCP clients.

Compatibility

There are no changes to execution semantics, storage formats, scheduler behavior, container execution, or scientific provenance records.

Existing Project Bourne v0.8 workflows remain compatible.

Project Bourne v0.8.0 :: Runtime Evidence and Scheduler Coverage

Project Bourne v0.8.0 — Runtime Evidence and Scheduler Coverage

The release adds first-class IBM LSF discovery and lifecycle support, bounded
execution-scoped runtime evidence, more precise partial/failure semantics, and
optional execution through an already-existing Apptainer/Singularity image.
It preserves the v0.7 control-plane/one-shot-worker architecture and exact argv
boundary.

Architecture delta from v0.7

• ExecutionRequest v2 adds explicit lsf; released v1 remains readable.
• SQLite schema 7 persists one versioned runtime-evidence record and
  termination evidence atomically with an execution result.
• worker-result v3 carries runtime and termination evidence; v1/v2 readers
  remain intact.
• staged-plan v4 carries current ExecutionRequest v2 payloads and optional
  immutable existing-image execution; v1/v2/v3 are still read without
  reinterpretation.
• remote-worker v1 is unchanged.

LSF uses bounded queue discovery, stdin bsub submission, exact-ID active
bjobs, recent-finished bjobs -a, durable bhist reconciliation, and
exact-job bkill. Resource mapping is
limited to portable Bourne-owned concepts. Site-specific memory/GPU syntax and
generic LSF expression building are intentionally excluded.

Linux process-tree sampling is local to the execution worker and records
coverage explicitly. macOS and unavailable metrics remain truthful rather
than becoming zeros. GPU visibility is not reported as utilization or proven
scheduler allocation.

Apptainer/Singularity support uses existing local images only. There is no
build, pull, install, registry, Docker-daemon, Kubernetes, or shell-string
execution path. v0.8 does not orchestrate multi-node container launch, choose
MPI-launcher/container ordering, or inject MPI launchers.

Bounded limitations

Live LSF and live Apptainer validation have not yet been performed. Runtime
sampling is execution-scoped and does not automatically aggregate across a
multi-node allocation. Bourne does not inject MPI launchers or automatically
choose container/MPI ordering. Portable LSF memory/GPU resource syntax remains
site-specific and unresolved.

This release adds no Docker requirement, automatic dependency
installation/build, cross-cluster placement, bulk data synchronization,
monitoring daemon, distributed telemetry service, Rust component, or v0.9 work.

See Runtime evidence and scheduler coverage for evidence
semantics, protocol details, and bounded limitations.

Project Bourne v0.7 adds site-aware, constraint-based scientific execution

Project Bourne v0.7.0 — Site-Aware Planning

Project Bourne v0.7 adds site-aware, constraint-based scientific execution
while preserving a strict HPC security boundary:

local control / optional AI / local stdio MCP
  → existing OpenSSH configuration
  → one-shot non-AI user-space worker on the access node
  → existing Slurm or PBS scheduler
  → execution-scoped worker inside the allocation
  → exact scientific argv

No AI agent, MCP server, AI credential, inbound service, root access,
persistent daemon, or public-internet access is required on the cluster.

Planning and provenance

• Durable local and remote_ssh sites contain no secrets.
• Discovery records where each fact was observed; login-node observations are
  not promoted to compute-allocation facts.
• Site policy claims retain sources and conflicts. Only explicit normative
  hard policy can reject a candidate; advisory evidence cannot. Applicability
  scopes prevent queue/partition/node-class/account policy from leaking into
  unrelated shapes, and typed Core/MCP submission retains the evidence kind.
• ResourceShape is first-class and separates nodes, ranks, CPUs, threads,
  accelerators, memory, and wall time. Real scheduler discovery now feeds a
  bounded request-shape generator without converting visibility into access.
• Candidate exploration is deterministic, ephemeral, capped at 64, and reports
  search coverage and truncation. Hard pruning plus fair group enumeration
  prevents an early shape from starving later viable shapes.
• Declarative providers use a versioned typed JSON AST. Trusted-code providers
  require explicit local enablement and must already exist at the remote site.
• Workload variants are separately staged, hashed, linked, and safety-classed;
  the original source is never overwritten. Selection now materializes a
  changed provider-bound JSON input automatically after an explicit semantic
  trust/declaration/approval decision.
• Environments are selected only from existing observations. Activation is
  typed and execution-scoped; v0.7 does not install or build dependencies.

Remote execution integrity

OpenSSH and SCP use exact argv with shell=False; Bourne does not weaken host
trust or accept arbitrary remote command text. A compatible remote worker may
already exist, or Bourne bootstraps an exact-version, digest-verified zipapp to
the user's cache without installing dependencies.

Execution identity is created before submission. Remote state is written
atomically. Once a scheduler accepts a job, the scheduler owns its lifetime and
no keepalive is required. A lost or ambiguous SSH response is never treated as
permission to resubmit: the same execution identity is reconciled against
durable remote state and the exact scheduler job. Missing evidence remains
unknown and never becomes a fabricated successful experiment.

Interfaces and compatibility

The CLI, Python service, and local stdio MCP adapter expose site inspection,
site discovery, candidate generation, explicit selection, execution, and
reconciliation. MCP exposes no generic shell or remote-filesystem primitive.

ExecutionRequest remains version 1. The remote-worker protocol is v1, the
worker-result protocol is v2, and the staged-plan protocol is v3; released
staged payloads remain backward-readable. SQLite migrates transactionally to
schema 6 while preserving released databases. The Python package remains
compatible with Python 3.10+, keeps zero base runtime dependencies, and
preserves the optional mcp extra.

The Bourne control plane is supported and tested on Linux and macOS. Native
Windows is not yet validated or supported.

Development tooling

uv.lock is committed and uv is the canonical contributor, dependency-locking,
test, and build frontend. CI uses locked/frozen semantics and release builds use
uv build --no-sources. setuptools remains the build backend. uv is not a
runtime, pip-user, npm-launcher, remote-worker, or HPC-node dependency.

Release artifacts are version-coupled as bourneprov 0.7.0,
@project-bourne/mcp 0.7.0, and MCP Registry server version 0.7.0.

Project Bourne v0.6.0::: MCP and Agent Interface

Project Bourne v0.6.0 — MCP and Agent Interface

Project Bourne v0.6 adds an optional, vendor-neutral agent interface while
preserving the v0.5 deterministic execution and provenance model.

Highlights

• bourne mcp serves ten structured tools over local stdio using the official
  MCP Python SDK and current 2026-07-28 protocol.
• bourneprov keeps zero base runtime dependencies; MCP is installed with the
  bourneprov[mcp] extra.
• Agents validate ExecutionRequest v1, inspect inventory, plan, and then execute
  an existing immutable plan as separate actions.
• Product errors are machine-readable, uncertainty is preserved, and process
  status, verification, telemetry, and scientific validity remain separate.
• @project-bourne/mcp is a zero-runtime-dependency Node.js 22+ launcher with
  exact Python-version coupling, npx support, diagnostics, and optional
  isolated bootstrap that does not modify scientific environments.
• Official MCP Registry metadata uses the stable identity
  io.github.KozakHou/project-bourne; it is published only after the matching
  final npm package exists.
• skills/project-bourne/SKILL.md provides portable, vendor-neutral behavioral
  guidance without granting broad shell permission.
• Python, npm, Registry, and Skill discovery metadata describe reproducible
  scientific execution, provenance, HPC, and verification intent.
• Python and npm distributions remain under Apache-2.0.

Compatibility

• SQLite schema remains version 5.
• ExecutionRequest remains bourne.execution-request version 1.
• Staged-plan and worker-result protocol version 2 remain current; version 1
  remains readable.
• Existing CLI commands and v0.5 request files remain supported.
• The MCP adapter and Node launcher target Linux and macOS. This release does
  not claim complete Windows scientific process-tree semantics.

The final coupled release versions are bourneprov 0.6.0 and
@project-bourne/mcp 0.6.0.

Limitations

• MCP uses local stdio only; v0.6.0 has no production HTTP or hosted MCP
  transport.
• Bourne contains no embedded LLM or natural-language parser.
• Deterministic verification evidence remains distinct from general scientific
  validity.
• The MCP adapter and Node launcher target Linux and macOS. Windows does not
  have complete scientific process-tree support in this release.
• When no compatible runtime is installed, npm launcher bootstrap requires
  network access to install the exact matching bourneprov[mcp] version into
  its private cache.

No v0.6.0 artifact is published during release-candidate preparation.

Project Bourne v0.5.0:::Unified Execution Requests, Telemetry and Verification

Project Bourne v0.5.0 — Unified Execution Requests, Telemetry and Verification

Overview

Project Bourne v0.5.0 adds a versioned, machine-readable user-intent boundary
to the v0.4 workload and execution architecture. It also adds low-overhead
summary telemetry and deterministic verification of captured output artifacts.
The runtime remains framework-independent, local-first, and free of third-party
dependencies.

The progression is cumulative:

• v0.1 answered: What ran?
• v0.2 answered: What went in, what came out, and what was derived from what?
• v0.3 answered: What execution infrastructure is available?
• v0.4 answered: What does the workload need, where can it run, and how is it
  executed?
• v0.5 answers: What execution does the user actually want, how can multiple
  frontends express that intent through one stable contract, did the expected
  deterministic outputs appear, and what low-overhead evidence was observed?

Why ExecutionRequest

ExecutionRequest is the immutable record of what a user asked Bourne to do.
It is deliberately distinct from Bourne's bounded workload interpretation, a
plan for a particular inventory, an execution attempt, scheduler facts, and
the resulting scientific experiment. This separation preserves user intent
without confusing it with decisions or observations made later in execution.

bourne.json

External request documents use kind bourne.execution-request and schema
version 1. The packaged JSON Schema is available through
bourne request schema; bourne request init, validate, and show provide
bounded data operations that do not discover, plan, or execute a workload.

The standard-library parser rejects duplicate and unknown fields, enforces
document, collection, string, and nesting limits, and never expands a shell,
imports project code, or executes user code. Relative working directories are
resolved from the request file while their lexical form is retained.

Unified frontend pipeline

Request files, existing CLI flags, and Python callers all compile through the
same pipeline:

ExecutionRequest -> WorkloadSpec -> ExecutionPlan -> ExecutionAttempt
                                                        -> Experiment

bourne plan --request bourne.json and
bourne execute --request bourne.json use this pipeline. Released flag-based
syntax remains supported and does not maintain a separate execution path.

Intent fidelity

A requested parent experiment may be a full ULID, a unique prefix, latest,
or @N. Bourne persists that lexical reference on the request and separately
records the canonical ULID resolved for the compiled workload. An invalid or
ambiguous parent prevents persistence; resolving the parent never overwrites
the user's original request or changes request identity.

Telemetry

Summary telemetry is enabled by default and derives only from evidence Bourne
already captured: wall duration, UTF-8 stdout/stderr byte counts, complete
declared-artifact byte totals, requested and allocated resources, and scheduler
queue timing when timestamps establish it. It performs no utilization sampling
or profiling. Missing metrics remain unavailable rather than becoming zero.
"telemetry": {"mode": "off"} disables the summary.

Verification

The first deterministic checks are output_exists, output_min_bytes, and
output_sha256. They evaluate captured output Artifact records and produce
passed, failed, or unknown evidence plus a separate aggregate result.
Process status is never rewritten: an experiment can complete while
verification fails. These checks establish artifact facts, not general
scientific validity.

Worker protocol

New staged plans and worker results use protocol version 2. The controller
validates staged request identity, telemetry policy, verification checks,
experiment relationships, and bounded result data before one transactional
import. The compute-side worker captures artifacts and builds telemetry and
verification evidence without requiring Bourne to be installed on the compute
node.

Direct execution

Direct requests reuse Bourne's live stdout/stderr, process-group interruption,
artifact capture, lineage, experiment persistence, telemetry, and verification
services. A failed command remains a persisted experiment, and execution status
remains separate from verification status.

Slurm and PBS compatibility

The v0.4 planning and scheduler lifecycle model remains intact. Request-backed
Slurm and PBS executions stage protocol-2 data through the same worker trust
boundary. Submission, scheduler state, allocation observations, experiment
status, telemetry, and verification remain distinct provenance facts.

Security

Request parsing and planning do not invoke a shell, expand environment
variables, evaluate templates, import project modules, or run the requested
command. Exact argv values are preserved. Secrets and arbitrary environment
variables are not captured. Scheduler result import remains bounded,
relationship-checked, identity-checked, and transactional.

Migration

SQLite schema 5 adds execution-request records and links, telemetry summaries,
verification runs, and verification checks. Opening schema 1, 2, 3, or 4 data
performs a deterministic transactional migration. Existing history is retained
without inventing requests, telemetry, or verification for earlier records.

Backward compatibility

Existing run/list/show/compare/trace, discovery/inventory, workload planning,
and direct/Slurm/PBS execution workflows remain supported. The v0.5 worker and
controller safely read released v0.4 staged-plan/result protocol version 1;
request-less v0.4 work does not acquire fictional v0.5 history. The external
request schema remains version 1, while new staged plans and results use
protocol version 2.

License

Beginning with v0.5.0, Project Bourne is distributed under the Apache License
2.0. Earlier releases through v0.4.0 remain under the MIT License terms under
which they were released.

This licensing transition does not change runtime behavior, SQLite schema 5,
the ExecutionRequest version-1 contract, worker protocol 2, compatibility with
released worker protocol 1, or the zero-runtime-dependency policy.

Limitations

v0.5.0 does not provide high-frequency CPU/GPU/memory/I/O sampling, profiling,
arbitrary verification programs, automatic artifact discovery, automatic
dependency or module installation, retries, remote copying, SSH orchestration,
container orchestration, general scientific-validity inference, or a web
interface. Captured stdout and stderr remain accumulated in memory before final
persistence.

What comes next

Future MCP, TypeScript/npm and npx, Skill, or natural-language agent
frontends should produce or validate the same version-1 ExecutionRequest and
call Bourne's structured services:

Human -> Agent or Skill -> ExecutionRequest -> Bourne core
                                             -> workload -> plan -> backend

Those future producers should not duplicate workload inspection, inventory
resolution, scheduler submission, execution supervision, artifact capture,
telemetry, or verification. No MCP server, TypeScript/npm or npx package,
Skill, natural-language agent, autonomous loop, or graph engine is implemented
in v0.5.0.

Project Bourne v0.4.0... Workload Planning and Scheduler Execution

Project Bourne v0.4.0 — Workload Planning and Scheduler Execution

Overview

Project Bourne v0.4.0 turns discovered compute infrastructure into executable
scientific plans. Bourne can inspect generic workloads, resolve compatible
execution paths, run directly on local systems, and submit and collect
scientific execution through Slurm or PBS while preserving execution-plane
provenance.

The release continues a provenance-first progression:

• v0.1: What ran?
• v0.2: What went in and what came out?
• v0.3: What execution infrastructure is available?
• v0.4: What does this workload need, where can it run, and how do I execute it?

The model is not HPC-only. Direct execution remains first-class on laptops,
workstations, DGX-class personal systems, and lab GPU machines; Slurm and PBS
extend the same model to scheduler-backed sites.

Highlights

• Immutable, framework-independent WorkloadSpec with evidence-backed
  requirements
• Bounded non-executing workload inspection with explicit evidence states
• Immutable ExecutionPlan tied to one inventory snapshot
• Conservative direct/Slurm/PBS resolution that refuses material ambiguity
• DirectBackend, SlurmBackend, and PBSBackend
• Portable standard-library-only compute worker
• Requested resources kept separate from observed allocation
• Submission, scheduler job, allocation, experiment, and lifecycle-event records
• Exact-job scheduler observation and identity-checked cancellation
• Trusted POSIX effective identity independent of login-name environment values
• Bounded JSON result validation and transactional, idempotent collection
• Shell-safe scientific argv preserved as an argument vector
• Append-only execution lifecycle evidence
• Transactional schema 4 migration preserving schema 1–3 history
• Zero third-party runtime dependencies

Workload model

WorkloadSpec is an immutable description of the requested command, working
directory, exact argv, declared artifacts, resource requirements, constraints,
and evidence. Evidence remains classified as explicit, observed, inferred,
historical, or unknown; inference is never promoted to observation.

Bounded inspection considers the explicit argv and an allowlist of marker names
in the exact working directory. It does not execute an unknown scientific
binary, import user modules, inspect marker contents, or recursively crawl the
working tree. Planning unknown software therefore does not mean executing it.

Execution planning

An immutable ExecutionPlan records one resolution decision against one
inventory snapshot. The conservative resolver applies explicit constraints,
rejects known hard incompatibilities, reports unresolved conditions, and
refuses to guess between materially ambiguous targets.

A visible target is not proof of authorization. Historical evidence is not
current availability. Unknown compatibility is not compatibility. A plan is a
recorded decision, not an execution.

Direct execution

DirectBackend runs the exact command through Bourne's established experiment
runner. It retains live and captured stdout/stderr, process-group interrupt
handling on POSIX, Git and system provenance, execution-context observations,
declared artifacts, and immediate lineage.

Scheduler execution

SlurmBackend and PBSBackend stage an immutable plan and a standard-library
worker, submit through the scheduler, observe only the recorded job, and import
the worker result. The worker resolves and preflights the executable on the
allocated host before launching the scientific process.

Bourne does not install dependencies, load environment modules, transfer
arbitrary scientific files, infer accounts/QoS/reservations, or bypass site
policy. Shared visibility of the staging and working directories remains a site
requirement.

Execution-plane provenance

Requested resources live in the workload and plan. Allocation facts are
observed on the execution host and stored separately. Execution attempts,
scheduler submissions/jobs, allocation observations, lifecycle events, and the
actual scientific experiment remain distinct durable records.

Scheduler submission is not a scientific experiment. Scheduler COMPLETED is
not scientific success. Without a valid worker result, Bourne records
collection_failed and does not create a successful experiment.

Slurm lifecycle

Slurm submission uses sbatch --parsable. Active observation uses exact-job
squeue scoped to the submitting identity. When the job leaves that view,
Bourne attempts an optional, bounded exact-job sacct lookup. Missing or
failed accounting remains explicitly unobservable rather than being reported
as completion.

Waiting begins at a configurable 15-second poll interval, backs off by 1.5x to
60 seconds, and has no arbitrary default scientific wall-clock timeout.
Cancellation accepts a Bourne execution reference and validates its recorded
submitting identity before issuing scancel for the exact recorded job ID.

PBS lifecycle

PBS submission uses qsub; observation uses exact-job qstat; cancellation
uses the exact recorded ID through qdel. Recognized unknown/purged-job
responses become explicit unobservable observations. Other status failures
remain query errors. An absent worker result never establishes scientific
success.

Security

Scheduler clients are invoked with explicit argv and shell=False, bounded
output, and timeouts. Scientific argv is stored as JSON and passed to the
scientific process as argv; it is never flattened into scheduler shell syntax.
The controller never queries all users, cancels an arbitrary caller-supplied
job ID, SSHes to compute nodes, escalates privileges, mutates containers, or
changes scheduler policy.

On POSIX, Bourne derives scheduler ownership from the effective UID and the
system password database. It does not trust USER, LOGNAME, LNAME, or
USERNAME. The scheduler remains the final authorization boundary.

Worker results use bounded, versioned JSON. Import validates identities, types,
relationships, size, nesting, collection counts, and consistency with the
immutable plan before a single transactional write. Repeated collection is
idempotent.

Examples

Direct planning and execution:

bourne discover
bourne plan --backend direct -- python examples/demo.py
bourne execute --backend direct -- python examples/demo.py
bourne execution list
bourne execution show @1

Scheduler-oriented planning and lifecycle:

bourne plan --backend slurm --cpus 8 --memory 16G --walltime 30m -- ./solver case.yaml
bourne execute --plan @1
bourne execution show @1
bourne execution wait @1

While the recorded scheduler job is active, cancellation is requested with
bourne execution cancel @1. Use --backend pbs for a PBS inventory target.

Compatibility

The release supports Python 3.10 through 3.13 and is continuously tested on
Linux and macOS. The runtime has no third-party dependencies. Existing v0.1.1,
v0.2.0, and v0.3.0 databases migrate transactionally to schema 4 while
preserving their prior experiment, artifact, lineage, execution-context,
inventory, and discovery-evidence records.

The v0.1–v0.3 CLI remains available: run, list, show, compare, trace,
discover, and inventory, including declared inputs/outputs and
derived_from lineage.

Current limitations

• Scheduler allocations must provide Python 3 and see the staging directory.
• Scientific working directories and declared files are not copied or archived.
• There is no automatic dependency installation, module loading, launcher
  injection, container orchestration, SSH execution, retry, or policy inference.
• Slurm/PBS parsing needs more validation across real vendor/site variants.
• Slurm accounting is optional and may be absent or delayed.
• stdout and stderr are captured in memory; large-log spooling is future work.
• Native Windows scheduler execution and process-tree supervision are not
  claimed.
• Execution status does not establish scientific correctness; verification is
  a separate future capability.

What comes next

The v0.4 release stops at trustworthy planning and execution provenance. A
future milestone may add explicit scientific-verification evidence, but v0.4
does not implement verification, autonomous repair, agents, or a graph engine.

See Workload planning and scheduler execution for the
full model and operational details.

Project Bourne v0.3.0:::: Compute Site Discovery

Project Bourne v0.3.0 — Compute Site Discovery

Project Bourne v0.3.0 introduces safe, read-only discovery of the scientific
execution environment available to the current researcher, from personal
workstations and laptops to scheduler-backed HPC systems.

Overview

v0.3 extends Bourne from experiment and artifact history to a structured,
durable understanding of the execution environment available to a researcher.
Each discovery is an immutable local snapshot; Bourne observes infrastructure
without operating or modifying it.

Highlights

• Immutable compute-site inventory snapshots
• Current identity and access-target observations
• User-relevant storage discovery and filesystem/mount observations
• Discovered system, Conda, virtualenv, container-metadata, and loaded-module
  execution contexts
• Generic executable capability discovery, including unknown software as a
  first-class capability
• System and hardware capability observations
• Read-only Slurm partition and PBS queue summaries
• Historical Bourne execution evidence
• Explicit provider status: complete, unavailable, partial, error, or
  timeout
• Structured JSON output and exact capability search
• Transactional schema 3 migration
• Zero third-party runtime dependencies

Example

bourne discover
bourne inventory
bourne inventory --find mpirun
bourne inventory --json

Compute topology

Bourne can represent:

current identity
    ↓
access target
    ↓
scheduler
    ↓
visible execution-target classes

Storage, execution contexts, and capabilities are recorded alongside this
topology. Scheduler summaries do not require SSH connections to compute nodes.
An access target and a scheduler-visible compute target remain distinct.

Generic local compute

The same model works for a personal laptop, desktop workstation, DGX-class
machine, or laboratory GPU system. Scheduler discovery may simply be
unavailable; a scheduler-free machine is a complete and valid discovery target.
HPC is one supported topology, not the definition of the product.

Safety

• Direct PATH scanning is non-recursive, bounded, and never executes unknown
  binaries.
• Provider subprocesses use explicit argument vectors, bounded execution time,
  and bounded captured output.
• Discovery does not traverse other users' homes, recursively scan storage,
  inspect SSH credentials, or dump arbitrary environment variables.
• Discovery does not submit or cancel scheduler jobs and does not SSH to
  compute nodes.
• Container providers do not start, stop, mutate, attach to, or execute inside
  containers.
• Discovery does not query network registries or perform Internet discovery.

Truthful evidence

Current observations, historical evidence, unavailable or partial providers,
and unknown authorization are represented distinctly. Historical success does
not establish current availability, and visibility does not prove permission.
Before persistence, evidence references are validated against subjects of the
declared type in the same snapshot; a record cannot claim both current
observation and historical-only evidence.

Compatibility

The existing experiment and artifact workflow remains available:

bourne run
bourne list
bourne show
bourne compare
bourne trace
bourne completion
--input
--output
--derived-from

Existing v0.1.1 and v0.2.0 databases migrate transactionally to schema 3 while
preserving experiment outcomes, artifacts, lineage, and execution context.

Current limitations

• No workload requirement inference or execution-context resolver
• No scheduler submission or automatic execution planning
• No remote SSH topology discovery or compute-node scanning
• No container-internal capability probing
• No institutional policy discovery; retention, quota, backup, and purge policy
  remain unknown
• Visible scheduler targets are not proven authorized
• No dependency resolution, scientific verification, or profiling/resource
  telemetry
• No MCP or agent interface
• Experiment stdout/stderr still accumulate in memory before final persistence

Design principle

Bourne understands scientific execution infrastructure generically. Unknown
software remains a first-class workload and capability.

Every experiment has a history.

Project Bourne v0.2.0 — Artifacts and Lineage

Project Bourne v0.2.0 — Artifacts and Lineage

Project Bourne v0.2.0 expands the provenance core from recording executions to recording how scientific results are produced.

This release introduces first-class artifact provenance, experiment lineage, traceability, and safer execution-context capture while remaining application-, language-, framework-, and domain-agnostic.

Highlights

• Declare experiment inputs and outputs explicitly with --input and --output.
• Record a distinct version for every artifact capture, including:
  • stable artifact ULID
  • original and resolved paths
  • artifact role
  • capture time
  • file size
  • modification time
  • SHA-256 content identity
  • capture diagnostics
• Stream SHA-256 hashing in bounded chunks instead of loading entire files into memory.
• Distinguish artifact state truthfully using:
  • existence_state: present, missing, unknown
  • capture_status: complete, unreadable, unsupported, changed
• Record experiment lineage with --derived-from.
• Resolve lineage references using full ULIDs, unique prefixes, latest, and @N.
• Trace an output back to the experiment that produced it with bourne trace.
• Refuse to guess when an artifact reference is ambiguous.
• Capture safe execution-context information, including:
  • requested executable
  • resolved executable path
  • Bourne recorder executable
  • allow-listed Conda and virtualenv hints
  • conservative container-presence information
• Transactionally migrate existing v0.1.1 databases from schema version 1 to schema version 2 without resetting historical experiments.
• Preserve zero third-party runtime dependencies.

Example

bourne run \
  --input config.json \
  --output result.csv \
  -- python simulation.py config.json result.csv

bourne show @1

bourne run \
  --derived-from @1 \
  --input config_next.json \
  --input result.csv \
  --output result_next.csv \
  -- python simulation.py config_next.json result_next.csv

bourne trace result_next.csv

Conceptually:

config.json
    │
    ▼
Experiment A
    │
    ▼
result.csv
    │
    ▼
Experiment B
    │
    ▼
result_next.csv

Bourne can now preserve and inspect this provenance chain.

Artifact correctness

Bourne does not turn uncertainty into false provenance.

A missing artifact means Bourne established that the file was absent:

existence_state = missing
capture_status  = complete

If Bourne cannot determine whether an artifact exists, for example because it cannot inspect the path, the state remains explicitly unknown:

existence_state = unknown
capture_status  = unreadable

Other incomplete capture conditions are represented explicitly as well:

present + unsupported
present + unreadable
present + changed

Only artifacts captured as present + complete may use SHA-256 as valid content identity.

Compatibility

All existing v0.1.1 functionality remains available:

• bourne run
• bourne list
• bourne show
• bourne compare
• full and shortened experiment IDs
• latest
• @N
• Bash, Zsh, and Fish completion
• failed experiment persistence
• interrupted experiment persistence
• live stdout/stderr streaming

Existing v0.1.1 databases are migrated automatically and transactionally when opened by v0.2.0.

Current limitations

This release intentionally keeps the scope focused.

Not yet included:

• automatic artifact discovery
• artifact archival or uploading
• directory or object-store artifacts
• multiple lineage parents
• environment discovery or automatic environment selection
• dependency installation
• resource profiling and telemetry
• scientific verification
• remote execution
• Slurm or PBS orchestration
• MCP integration
• natural-language agents

stdout and stderr still stream live but accumulate in memory before final persistence.

Design principle

Bourne remains generic by default.

The core does not depend on Python, machine learning, fusion software, Docker, MPI, or any particular scientific application.

An unknown executable remains a first-class workload.

Future application-specific integrations can add additional knowledge without changing the underlying provenance model.

Every experiment has a history.

Project Bourne v0.1.1

Full Changelog: https://github.com/KozakHou/project-bourne/commits/v0.1.1