evorthon-data-harness 1.0.2__tar.gz

evorthon_data_harness-1.0.2/.claude/settings.json

@@ -0,0 +1 @@
+{"hooks": {}, "plugins": []}

evorthon_data_harness-1.0.2/.gitattributes

@@ -0,0 +1 @@
+* text=auto eol=lf

evorthon_data_harness-1.0.2/.github/agents/evorthon-data-harness-builder.agent.md

@@ -0,0 +1,3 @@
+# Evorthon Data Harness builder
+
+Read `../../AGENTS.md`; execute only an approved change contract and use canonical Koine generators.

evorthon_data_harness-1.0.2/.github/agents/evorthon-data-harness-reviewer.agent.md

@@ -0,0 +1,3 @@
+# Evorthon Data Harness reviewer
+
+Read `../../AGENTS.md`; independently challenge an artefact through its canonical paired Koine reviewer.

evorthon_data_harness-1.0.2/.github/copilot-instructions.md

@@ -0,0 +1,3 @@
+# Evorthon Data Harness Copilot instructions
+
+Read `../AGENTS.md`. Use `prompts/` and `skills/` only as discovery pointers to canonical Koine prompt owners.

evorthon_data_harness-1.0.2/.github/prompts/autobuild-approved-item.prompt.md

@@ -0,0 +1 @@
+Read `../../adapters/autobuild/contract.md`; execute only a ready, approved item.

evorthon_data_harness-1.0.2/.github/prompts/koine-advise-on-fault-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/advise-on-fault-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-advise-on-fault.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/advise-on-fault.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-build-data-platform-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/build-data-platform-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-build-data-platform.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/build-data-platform.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-design-data-platform-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/design-data-platform-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-design-data-platform.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/design-data-platform.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-discover-greenfield-capabilities-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/discover-greenfield-capabilities-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-discover-greenfield-capabilities.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/discover-greenfield-capabilities.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-execute-plan.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/method/build-pipeline.md` before executing approved work.

evorthon_data_harness-1.0.2/.github/prompts/koine-frame-platform-outcome-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/frame-platform-outcome-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-frame-platform-outcome.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/frame-platform-outcome.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-intake-use-case-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/intake-use-case-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-intake-use-case.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/intake-use-case.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-plan-first.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/method/intent-readiness.md` before proposing work.

evorthon_data_harness-1.0.2/.github/prompts/koine-setup-data-platform-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/setup-data-platform-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-setup-data-platform.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/setup-data-platform.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-trace-current-estate-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/trace-current-estate-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-trace-current-estate.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/trace-current-estate.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-verify-data-platform-review.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/reviewers/verify-data-platform-reviewer.md`.

evorthon_data_harness-1.0.2/.github/prompts/koine-verify-data-platform.prompt.md

@@ -0,0 +1 @@
+Read `../../koine/prompts/generators/verify-data-platform.md`.

evorthon_data_harness-1.0.2/.github/skills/advise-on-fault/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/advising-on-a-fault/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/build-data-platform/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/building-data-platform/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/design-data-platform/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/designing-data-platform/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/discover-greenfield-capabilities/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/discovering-greenfield-capabilities/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/frame-platform-outcome/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/framing-platform-outcome/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/intake-use-case/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/intaking-use-case/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/setup-data-platform/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/setting-up-data-platform/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/trace-current-estate/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/tracing-current-estate/SKILL.md`.

evorthon_data_harness-1.0.2/.github/skills/verify-data-platform/SKILL.md

@@ -0,0 +1 @@
+Read `../../../koine/skills/verifying-data-platform/SKILL.md`.

evorthon_data_harness-1.0.2/.github/workflows/ci.yml

@@ -0,0 +1,38 @@
+name: repository-check
+on: [push, pull_request]
+jobs:
+  fast:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with: {python-version-file: pyproject.toml}
+      - uses: astral-sh/setup-uv@v5
+      - name: Validate the checked-out tree
+        shell: bash
+        run: |
+          # A published candidate carries a finalized inventory, so the candidate
+          # branch takes no provisional allowance. Only an unpublished candidate
+          # still holds a provisional inventory, and it is not what CI checks out.
+          if [ -f PUBLIC-INVENTORY.json ] && [ -f PUBLIC-LEAKAGE-POLICY.json ]; then
+            python scripts/check_public_candidate.py
+          else
+            uv run --locked --group dev python scripts/run_tests.py --lane fast
+          fi
+  vectors:
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with: {python-version-file: pyproject.toml}
+      - uses: astral-sh/setup-uv@v5
+      - name: Compare the committed canonical vectors
+        shell: bash
+        run: uv run --locked --group dev python scripts/run_tests.py --lane fast tests/verification/test_canonical_identity.py
+      - name: Run the fast lane
+        shell: bash
+        run: uv run --locked --group dev python scripts/run_tests.py --lane fast

evorthon_data_harness-1.0.2/.github/workflows/release.yml

@@ -0,0 +1,89 @@
+name: Publish the reviewed distributions
+
+# This workflow uploads the distributions a person has already reviewed and
+# attached to a tagged publication. It builds nothing of its own, and it stops
+# before uploading anything whose digest disagrees with the digests published
+# beside it.
+
+on:
+  workflow_dispatch:
+    inputs:
+      release_tag:
+        description: The tag whose attached distributions are published, in the form vX.Y.Z
+        required: true
+        type: string
+
+concurrency:
+  group: pypi-publish
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  publish:
+    name: Publish to the package index
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/evorthon-data-harness/
+    permissions:
+      contents: read
+      id-token: write
+
+    steps:
+      - name: Download the distributions the tag carries
+        env:
+          GH_TOKEN: ${{ github.token }}
+          RELEASE_TAG: ${{ inputs.release_tag }}
+          REPOSITORY: ${{ github.repository }}
+        shell: bash
+        run: |
+          set -euo pipefail
+          if [[ ! "$RELEASE_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            echo "release_tag must use the form vX.Y.Z" >&2
+            exit 1
+          fi
+
+          mkdir -p assets
+          gh api "repos/$REPOSITORY/releases/tags/$RELEASE_TAG" --jq '.assets[] | [.name, .url] | @tsv' > catalogue.tsv
+          while IFS=$'\t' read -r name address; do
+            case "$name" in
+              evorthon_data_harness-*.whl|evorthon_data_harness-*.tar.gz|SHA256SUMS)
+                gh api -H "Accept: application/octet-stream" "$address" > "assets/$name"
+                ;;
+            esac
+          done < catalogue.tsv
+
+      - name: Verify the downloaded distributions against the published digests
+        shell: bash
+        run: |
+          set -euo pipefail
+          mkdir -p dist
+          cd assets
+          shopt -s nullglob
+
+          test -f SHA256SUMS
+          wheels=(evorthon_data_harness-*.whl)
+          sdists=(evorthon_data_harness-*.tar.gz)
+          test "${#wheels[@]}" -eq 1
+          test "${#sdists[@]}" -eq 1
+          packages=("${wheels[0]}" "${sdists[0]}")
+
+          listed=$(awk '{ name = $2; sub(/^[*]/, "", name); print name }' SHA256SUMS | sort)
+          expected=$({ echo "${wheels[0]}"; echo "${sdists[0]}"; } | sort)
+          test "$(wc -l < SHA256SUMS)" -eq 2
+          test "$listed" = "$expected"
+          sha256sum --check --strict SHA256SUMS
+
+          cp -- "${packages[@]}" "$GITHUB_WORKSPACE/dist/"
+
+      # The published v1 line of the trusted-publishing action, pinned by commit.
+      - name: Publish the verified distributions
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33
+        with:
+          packages-dir: dist
+          verify-metadata: true
+          skip-existing: false
+          attestations: true
+          print-hash: true

evorthon_data_harness-1.0.2/.gitignore

@@ -0,0 +1,7 @@
+.venv/
+__pycache__/
+*.py[cod]
+.pytest_cache/
+artifacts/
+work/
+.claude/settings.local.json

evorthon_data_harness-1.0.2/ADOPTION-GUIDE.md

@@ -0,0 +1,99 @@
+# Adopting Evorthon Data Harness
+<!-- evorthon-implements: EVD-README-032 -->
+
+Start with a report, dataset or consumer view whose success you can describe and check. Gather the material that explains it and involve the people who can decide what should change.
+
+Evorthon Data Harness provides a specialist AI coworker, delivery records and Python tools for recording and verifying the work. Adapters connect it to separately released delivery tools. The adopting team supplies platform access, model authorization and the people who accept the result.
+
+## Work through an example
+
+Choose the [customer service reporting example](examples/modernisation/customer-service-reporting/outcome-brief.md) for an existing estate, or the [renewable asset example](examples/greenfield/renewable-asset-observability/outcome-brief.md) for a new platform. Both use synthetic data and named fictional decision owners.
+
+Read the outcome brief first, then follow the records in that example's directory through discovery, design, implementation planning and verification. Use them to understand what a completed record contains before adapting the [templates](koine/templates/) to your own work.
+
+## Prepare the first use case
+
+1. Name the consumer and the output they need. Record how often they need it, what success means and who can accept delivery.
+2. Gather existing schemas, data extracts, transformations, reports, schedules and catalogue exports. Facts recorded from them retain their source and whether they are extracted, inferred or confirmed.
+3. Define the output's fields, what each row represents and its identifying keys. These are the minimum facts needed to assess a segment of processing for build readiness.
+4. Name the people responsible for source evidence, technical decisions, policies and acceptance. Record unresolved questions and constraints alongside the outcome.
+
+For modernisation, document the current estate and the behaviour that must continue. For greenfield delivery, do not simply skip discovery: document required capabilities and constraints in a reviewed capability-discovery record. Both routes then produce a platform design, implementation plan, delivery contract and verification record.
+
+Missing data can be filled with labelled synthetic datasets. Readiness is calculated per segment, so another segment's missing facts need not stop ready work. Acceptance records show what was covered, what evidence was used and what remains outside the accepted version.
+
+## Use the coworker and delivery tools
+
+The [Koine coworker pack](koine/INDEX.md) provides prompts and templates for the delivery conversation. A generation prompt drafts a record; a separate reviewer challenges it. People resolve the findings and approve the decisions.
+
+Pinax holds work state and dependencies, while Ergasterion generates outputs from suitable contracts. Eligible, approved work can run through build and review cycles in AutoBuild. The [dependency contracts](docs/dependency-contracts.md) describe how Evorthon Data Harness connects to those separately released tools.
+
+Use Python 3.11 or later in a virtual environment. From the root of a repository checkout, install the package and its delivery tools:
+
+```text
+python -m pip install ".[delivery]"
+```
+
+Inspect the available commands and delivery dependencies:
+
+```text
+evorthon-data-harness diagnose
+evorthon-data-harness use-case --help
+evorthon-data-harness verification --help
+```
+
+## Model access
+
+Every model call passes through an authorization gateway. A call requires current, unrevoked authorization issued by your environment for the case, purpose, route, destination and exact fields. It also names the data class, retention policy and evidence policy.
+
+A provider credential alone does not authorize sending material. The people responsible for model access control both the authorization and the provider account. They can inspect the permitted fields before use.
+
+### Intake
+
+The generator call carries the use-case identity, engagement mode, open questions, confirmed answers and admitted artefact references. Each reference includes its identity, version, digest, handling classification and logical location within the source.
+
+It may also carry a bounded sample of artefact text, limited by a declared number of rows and characters. Text crosses only when its handling classification is permitted by the authorization's field scope. A small artefact may fit entirely within those limits.
+
+For higher classifications, the round uses the digest and recorded facts without sending artefact text. Each round reports the amount sent for each artefact or the reason its text was withheld.
+
+### Independent review
+
+The review call carries recorded facts, their provenance, and artefact identities and digests. It carries no artefact text at any classification.
+
+### Diagnostic advice
+
+The diagnostic adviser receives declared text fields and evidence identities from a fault packet that has passed the privacy check. It receives no raw rows, keys, field values or approved case text.
+
+The reply is stored as an inert advice record for a person to read. The product does not execute, apply or forward the reply.
+
+### Source references and connection details
+
+A logical locator names an artefact and a position within it. Connection details belong in your environment's configuration. The record refuses a locator containing any of these machine-location forms:
+
+- an address under any scheme
+- a path from the root of a machine
+- a lettered volume
+- a share host
+- a written home directory
+- a climb out of where it starts
+- a path written with a machine path's separator
+
+The same forms are refused in fault packets and tracker notes. The record admits a locator that reads like a dotted server name followed by a path or a port, or like a connection string. The intake round reports a warning on it.
+
+These forms need human review because a dotted name cannot be told from an ordinary written name by the pattern check. The warning leaves the locator admitted. Keep actual connection details in environment configuration.
+
+Credential-shaped patterns are refused before an artefact is admitted. These checks recognise declared patterns; they do not establish that arbitrary text contains no sensitive information. Review the material and authorize only the fields and samples suitable for your model provider.
+
+## Connect your environment
+
+Two adapter contracts connect verification to your material: one reads stored evidence and one produces candidate outputs. The adopting team implements the code that accesses its platform. Reference adapters can read values held in memory or material in a directory you select.
+
+Each adapter declares its capabilities and the evidence supporting its answers. A conformance suite checks those declarations against the contract, including unsupported capabilities, missing assurance inputs, invalid values, machine locations and credential patterns.
+
+Access, capture, credentials, signing, retention and certification belong to your environment. The [environment-adapter contract](docs/verification/environment-adapters.md) describes the interfaces and their conformance checks.
+
+## Verify and accept
+
+Agree the comparison rules and expected results before the run. The [verification engine](docs/verification/README.md) compares candidate outputs against frozen evidence and reports confirmed differences and evidence gaps.
+
+A named person decides whether the result is acceptable, including when evidence is synthetic or incomplete. Keep live organisational evidence, review records, credentials and operational work state in your team's environment.

evorthon_data_harness-1.0.2/AGENTS.md

@@ -0,0 +1,5 @@
+# Evorthon Data Harness
+
+Use the canonical Koine co-worker and its paired reviewers with the supplied synthetic examples.
+
+The [D2 model](docs/architecture/solution-architecture.d2) is the sole owner of component routes and ownership mapping. Its Markdown and SVG are mechanically generated readable projections.

evorthon_data_harness-1.0.2/LICENSE

@@ -0,0 +1,15 @@
+MIT License
+
+Copyright (c) 2026 Georgios Antikatzidis
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.

evorthon_data_harness-1.0.2/PKG-INFO

@@ -0,0 +1,189 @@
+Metadata-Version: 2.5
+Name: evorthon-data-harness
+Version: 1.0.2
+Summary: Data engineering harness for modernising an existing estate or building a new platform
+Project-URL: Documentation, https://github.com/antikas/evorthon-data-harness#readme
+Project-URL: Issues, https://github.com/antikas/evorthon-data-harness/issues
+Project-URL: Repository, https://github.com/antikas/evorthon-data-harness
+License: MIT
+License-File: LICENSE
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Quality Assurance
+Requires-Python: >=3.11
+Provides-Extra: delivery
+Requires-Dist: autobuild-factory>=0.5.0; extra == 'delivery'
+Requires-Dist: ergasterion-factory>=0.6.1; extra == 'delivery'
+Requires-Dist: pinax-tracker>=0.1.3; extra == 'delivery'
+Provides-Extra: test
+Requires-Dist: pytest-timeout<3,>=2; extra == 'test'
+Requires-Dist: pytest<9,>=8; extra == 'test'
+Description-Content-Type: text/markdown
+
+# Evorthon Data Harness
+
+Delivering a data platform means carrying business definitions, design decisions and evidence from discovery through engineering to acceptance. When that work is split across documents and tools, teams spend time reconstructing what was agreed and how to check it.
+<!-- evorthon-claim: EVD-README-036 -->
+
+Evorthon Data Harness is a **data engineering harness**: software and a specialist AI coworker that help a team turn a business outcome into reviewed, built and verified data products. It supports both modernising an existing estate and building a new platform.
+<!-- evorthon-claim: EVD-README-037 -->
+
+People set the outcome, scope, policies and acceptance rules. Evorthon Data Harness records those decisions, carries them through delivery and retains the evidence for a named person to accept the result.
+<!-- evorthon-claim: EVD-README-038 -->
+
+## Delivery example
+
+The included [customer service reporting example](examples/modernisation/customer-service-reporting/outcome-brief.md) starts with service leaders needing a daily view by 09:00. It uses synthetic case, interaction and workforce data, preserving the existing cutoff and metric definitions.
+<!-- evorthon-claim: EVD-README-002 -->
+
+Its agreed checks detect missing keys, changed totals and populations that fail to reconcile. The example requires two successful synthetic daily publications before its named sponsor accepts delivery.
+<!-- evorthon-claim: EVD-README-003 -->
+
+The engagement follows these stages:
+<!-- evorthon-claim: EVD-README-040 -->
+
+1. Record the business outcome, measurable success criteria, scope and decision owners.
+<!-- evorthon-claim: EVD-README-004 -->
+2. Establish the starting point: the current estate for modernisation, or required capabilities and constraints for a new platform.
+<!-- evorthon-claim: EVD-README-005 -->
+3. Design the platform and operating model, including the transition and delivery increments.
+<!-- evorthon-claim: EVD-README-006 -->
+4. Turn the accepted design into tracked work with dependencies and approval points.
+<!-- evorthon-claim: EVD-README-007 -->
+5. Build in bounded increments. Suitable contracts can generate repeatable outputs from the same approved inputs.
+<!-- evorthon-claim: EVD-README-008 -->
+6. Configure and run verification, including expected results, failure cases and checkpoints that help locate differences.
+<!-- evorthon-claim: EVD-README-009 -->
+7. Present the results, review findings and remaining uncertainty to the people responsible for acceptance.
+<!-- evorthon-claim: EVD-README-010 -->
+
+The agreed decisions and constraints form a delivery contract that the coworker, tools and reviewers use throughout the work.
+<!-- evorthon-claim: EVD-README-041 -->
+
+## Two delivery modes
+
+### Modernise an existing estate
+
+For modernisation, the coworker examines existing processing, data, interfaces and controls. The team identifies behaviour that must continue and agrees a transition in separately accepted increments.
+<!-- evorthon-claim: EVD-README-011 -->
+
+### Build a greenfield platform
+
+For greenfield delivery, the team starts with required outcomes, capabilities, constraints and operating needs. The [renewable asset example](examples/greenfield/renewable-asset-observability/outcome-brief.md) follows this route, using approved scenarios to check a new platform.
+<!-- evorthon-claim: EVD-README-012 -->
+
+## Delivery workflow
+
+An engagement records who owns the business outcome, source evidence, technical decisions and final acceptance. Those people review the decisions before work enters delivery.
+<!-- evorthon-claim: EVD-README-013 -->
+
+Each consumer outcome has a use-case record containing its outputs, inputs, reference data, processing steps, scenarios and versions. An engagement can contain several use cases, each split into packages of build work.
+<!-- evorthon-claim: EVD-README-043 -->
+
+The specialist coworker helps gather requirements, draft delivery records and link decisions to evidence. Each generation step has a separate review. The supplied prompts and templates define this role, called the Koine data coworker.
+<!-- evorthon-claim: EVD-README-014 -->
+
+Intake starts with existing schemas, extracts, transformations, reports and schedules. Recorded facts identify their source and location, who extracted them, and whether they are extracted, inferred or confirmed. The coworker asks about gaps left by that material.
+<!-- evorthon-claim: EVD-README-044 -->
+
+Model calls require authorization from the adopting environment. Intake may send a bounded sample of permitted artefact text; independent review receives recorded facts and references. Diagnostic advice remains text for a person to assess. The [adoption guide](ADOPTION-GUIDE.md#model-access) explains each route and its limits.
+<!-- evorthon-claim: EVD-README-050 -->
+
+Readiness is calculated for each span of processing, called a segment. Its output definition must specify fields, what one row represents and identifying keys. Other missing facts receive labelled substitutes or tracked follow-up work, allowing ready segments to proceed.
+<!-- evorthon-claim: EVD-README-045 -->
+
+The work tracker holds dependencies, readiness, claims and completion. Evorthon Data Harness uses the separately released Pinax tracker for this shared operational record.
+<!-- evorthon-claim: EVD-README-015 -->
+
+Pinax shares state changes through Git. It reads shared state before claiming work and refuses a claim that loses a race with another worker.
+<!-- evorthon-claim: EVD-README-046 -->
+
+Two further tools support delivery: Ergasterion generates outputs from suitable contracts, and AutoBuild runs eligible work through build and review cycles. Evorthon Data Harness connects to their released packages through narrow adapters.
+<!-- evorthon-claim: EVD-README-016 -->
+
+Verification begins when the team defines success, evidence ownership and failure conditions. The product provides the comparison engine; platform delivery includes the contracts, checks and environment adapters needed to use it.
+<!-- evorthon-claim: EVD-README-017 -->
+
+A named person accepts delivery with its check results and review findings attached. A model cannot accept its own work.
+<!-- evorthon-claim: EVD-README-018 -->
+
+Acceptance can cover one segment. The version records included outputs, scenarios, data provenance and excluded work. An accepted intermediate product can then serve another use case.
+<!-- evorthon-claim: EVD-README-047 -->
+
+## Verification
+
+A verification case freezes the inputs, reference data, expected outputs, comparison rules and available checkpoints for a run. The responsible people can read and change those rules before running the case.
+<!-- evorthon-claim: EVD-README-019 -->
+
+Where data is missing, the team can generate synthetic datasets with recorded seeds and constraints. Cases, results and acceptance records retain that label. Passing synthetic checks establishes progress against those scenarios; demonstrating parity with real data requires real evidence.
+<!-- evorthon-claim: EVD-README-048 -->
+
+The engine runs the candidate against frozen evidence, compares actual and expected outputs, and reports the earliest confirmed difference. Gaps between checkpoints remain explicitly unknown. Routine verification works without a live legacy system.
+<!-- evorthon-claim: EVD-README-020 -->
+
+Portable verification records hold identifiers, fingerprints, counts and approved summaries. The adopting environment owns raw data access, credentials, storage, signing, retention and certification.
+<!-- evorthon-claim: EVD-README-021 -->
+
+A failed comparison produces a fault record naming the affected checkpoint and supporting evidence. A diagnostic adviser may propose a correction. It cannot change tolerances, replace evidence, execute work or accept the outcome.
+<!-- evorthon-claim: EVD-README-022 -->
+
+## Checks and acceptance
+
+- People set and can inspect the outcome, scope, policies, tolerances and acceptance rules.
+<!-- evorthon-claim: EVD-README-023 -->
+- Generation and review are separate. A named authority resolves or accepts review findings.
+<!-- evorthon-claim: EVD-README-024 -->
+- Approved work enters the tracker before execution, with an explicit scope.
+<!-- evorthon-claim: EVD-README-025 -->
+- Tests cover successful cases and deliberate failures to check that defects are detected.
+<!-- evorthon-claim: EVD-README-026 -->
+- Verification reports evidence gaps and uncertainty for human acceptance.
+<!-- evorthon-claim: EVD-README-027 -->
+- Readiness, provenance and assurance inform decisions. People may accept synthetic or incomplete evidence. Integrity checks refuse contradictory records, mismatched evidence digests, stored credentials, actors of the wrong kind and changes to immutable records.
+<!-- evorthon-claim: EVD-README-049 -->
+
+Comparison results come from deterministic checks against the case's declared rules.
+<!-- evorthon-claim: EVD-README-042 -->
+
+## Scope and limits
+
+Evorthon Data Harness is specific to data-platform delivery.
+<!-- evorthon-claim: EVD-README-028 -->
+
+The adopting team chooses its cloud, processing engine, storage and target architecture.
+<!-- evorthon-claim: EVD-README-029 -->
+
+Platform engineers, data owners, security teams and operators remain responsible for their decisions and the delivered platform.
+<!-- evorthon-claim: EVD-README-030 -->
+
+Live connections, credentials, protected data and certified evidence stores remain under the adopting environment's control. Connecting them requires environment-owned adapters. The synthetic examples provide no certification of a live platform.
+<!-- evorthon-claim: EVD-README-031 -->
+
+## For engineers
+
+Start with the [adoption guide](ADOPTION-GUIDE.md) and a [worked example](examples/INDEX.md). The [architecture record](docs/architecture/solution-architecture.md) explains component responsibilities. The [coworker pack](koine/INDEX.md) contains the method, prompts and templates.
+<!-- evorthon-claim: EVD-README-032 -->
+
+The Python package requires Python 3.11 or later. Optional delivery dependencies provide the tracker, generator and build runner; their declared minimum versions follow the interfaces this product uses.
+<!-- evorthon-claim: EVD-README-033 -->
+
+Use `evorthon-data-harness diagnose` to inspect installed delivery capabilities. To run the repository's fast checks with [uv](https://docs.astral.sh/uv/):
+<!-- evorthon-claim: EVD-README-034 -->
+
+```text
+uv run --locked --group dev python scripts/run_tests.py --lane fast
+```
+
+To check that a downloaded public copy matches its published file list, run:
+<!-- evorthon-claim: EVD-README-035 -->
+
+```text
+python scripts/check_public_candidate.py
+```
+
+Implementation and test references are checked for consistency.
+<!-- evorthon-claim: EVD-README-039 -->
+
+See [capabilities and evidence](docs/product/capability-status.md) for implementation and test references.
+<!-- evorthon-claim: EVD-README-001 -->