Add DEVIDENCE acquisition conformance profile v0.2

conformance/README.md

@@ -0,0 +1,25 @@
+# DEVIDENCE Conformance Profiles
+
+This directory contains versioned conformance profiles that specialize existing DSEARCH /
+DEVIDENCE meanings into testable implementation requirements.
+
+A profile in this directory is not part of Base Layer conformance merely because it is
+present in the standards repository. Its normative requirements bind only an implementation
+that explicitly claims the named profile and version.
+
+Profiles may define observable conformance behavior, required distinctions, failure
+semantics, test vectors, bindings, or domain-specific constraints while preserving the
+governing meanings defined by the Terms of Reference, DSEARCH, and DEVIDENCE.
+
+A profile must not silently redefine Base Layer semantics. If operational evidence shows
+that a profile distinction belongs in the Base Layer, that promotion requires a separate
+governed standards change under the then-current standards.
+
+Profiles do not authorize their own adoption or promotion. Repository governance and the
+then-current standards govern acceptance, revision, deprecation, and replacement.
+
+The first adopted profile is:
+
+- `devidence-acquisition-representation-v0.2.md` — acquisition, representation identity,
+  integrity comparison, compound/container materialization, bounded representation-adequacy
+  assertions, reproducible provenance, and associated failure semantics.

conformance/devidence-acquisition-representation-v0.2.md

@@ -0,0 +1,101 @@
+# DEVIDENCE Acquisition and Representation Conformance Profile
+## Version 0.2
+
+Status: ADOPTED EXTERNAL CONFORMANCE PROFILE
+
+Authority scope: implementations explicitly claiming this profile and version
+
+Base Layer authority: NONE
+
+Pre-adoption governing DEVIDENCE standards commit: `c360f66bd624d9c7c57dbf7f7327197a1184aedd`
+
+This document is an adopted external conformance profile. It does not amend DEVIDENCE Base
+Layer meanings and does not become part of Base Layer conformance merely by being present in
+the standards repository.
+
+Normative keywords such as **SHALL**, **SHALL NOT**, **SHOULD**, and **MAY** apply only to an
+implementation that explicitly claims conformance with this profile and version. They have
+no Base Layer force.
+
+## Purpose
+
+This profile defines testable implementation behavior for acquisition and materialization
+using existing DEVIDENCE meanings. It does not introduce new evidence-object types.
+
+## Conformance observations
+
+An implementation claiming this profile SHALL preserve these observations separately:
+
+1. **Acquisition result** — PASS, FAIL, PARTIAL, or UNKNOWN for the attempted acquisition,
+   with route/tool/provenance sufficient to explain the result.
+
+2. **Representation identity** — source- and contract-appropriate identity for the exact
+   representation observed or preserved. A cryptographic digest SHALL be recorded when the
+   source, transport, profile, or governing contract provides or requires one. This profile
+   does not require one universal digest algorithm for every representation.
+
+3. **Integrity comparison** — when an expected identity or integrity constraint exists, the
+   observed representation SHALL be compared against it and the result recorded separately
+   as PASS, FAIL, or UNKNOWN.
+
+4. **Materialization result** — for compound/container sources, PASS, FAIL, PARTIAL, or
+   UNKNOWN for the requested member/record/span. Successful container acquisition SHALL NOT
+   imply successful member materialization.
+
+5. **Bounded representation-adequacy assertion** — when an implementation judges whether a
+   representation can support an intended claim or transformation, it SHALL record:
+   - the explicit target claim or transformation;
+   - the evidence basis used for the judgment;
+   - PASS, FAIL, or UNKNOWN;
+   - a claim ceiling describing what the result does not establish.
+
+   This assertion is a conformance test result. It is not a truth score, confidence score,
+   authority score, or new Base Layer evidence type.
+
+6. **Reproducible provenance** — route, tool/version, source identity, representation
+   identity, transformation/materialization path, and source-supported unknowns needed to
+   reproduce or audit the result.
+
+## Required failure semantics
+
+An implementation claiming this profile SHALL NOT:
+
+- report acquisition PASS solely because an output file exists;
+- report acquisition FAIL solely because an observed representation has zero bytes;
+- convert acquisition failure or member-not-found into source absence;
+- infer member success from container success;
+- report the observed representation as the expected artifact when an integrity comparison
+  fails;
+- infer truth, authority, or completeness from preservation, retrieval success, or identity;
+- discard already valid materialized members solely because a later container member fails,
+  when member boundaries and identity are independently established.
+
+For a PARTIAL container/materialization result, successfully materialized members MAY support
+claims bounded to those members. The failed or unparsed remainder SHALL remain explicitly
+failed, unavailable through that path, or UNKNOWN as supported by the evidence.
+
+## Minimum conformance vectors
+
+The implementation SHOULD be tested against at least:
+
+- successful claim-bearing HTTP acquisition;
+- failed or inadequate HTTP acquisition;
+- non-empty local-file success;
+- intentionally empty local-file success;
+- missing local source;
+- expected-identity mismatch;
+- successful compound/container acquisition;
+- intentionally empty container member;
+- missing container member;
+- member integrity mismatch;
+- malformed/truncated container;
+- partially recoverable container with at least one independently valid member;
+- bounded adequacy PASS, FAIL, and UNKNOWN cases.
+
+## Authority boundary
+
+This profile has conformance authority only for implementations that explicitly claim this
+profile and version. It does not amend DEVIDENCE Base Layer meanings, establish truth, grant
+authority to evidence merely because it was preserved or retrieved, or authorize other
+profiles. Changes to this profile remain subject to governance under the then-current
+DEVIDENCE standards.

digital_search_commons.md

@@ -11,6 +11,8 @@ The architecture is now described through four coordinated documents rather than
 - **`dsearch.md` — DSEARCH.** This document describes the search/discovery commons, its Base Layer, interoperability boundaries, decentralization, resilience, governance, and search-oriented contracts.
 - **`devidence.md` — DEVIDENCE.** This document describes preservation, acquisition, representation, provenance, derivation, historical backfill, evidentiary observations, disagreement, and the richer evidence surface from which searchable projections may be produced.
 
+Versioned implementation conformance profiles live under **`conformance/`**. These profiles specialize existing shared meanings into testable requirements for implementations that explicitly claim a named profile and version. Presence in `conformance/` does not make a profile part of Base Layer conformance and does not grant it authority to redefine Base Layer semantics.
+
 The split is intended to make the architecture easier to reason about without separating concerns that need to remain connected.
 
 ```text