ĀML hardening: independent verification, release discipline, evidence corpus

conformance/verifier-challenge-cases.json

@@ -0,0 +1,49 @@
+{
+  "schema": "aml-verifier-challenge-cases/1",
+  "bundle_source": "independent/python/witness-vector.json",
+  "mutation_language": {
+    "schema": "aml-json-pointer-replace/1",
+    "operation": "replace",
+    "path_semantics": "RFC 6901 JSON Pointer",
+    "supported_operations": ["replace"]
+  },
+  "cases": [
+    {
+      "id": "golden-valid",
+      "now": "2030-01-01T00:05:00Z",
+      "expected_valid": true,
+      "mutations": []
+    },
+    {
+      "id": "tampered-purpose",
+      "now": "2030-01-01T00:05:00Z",
+      "expected_valid": false,
+      "mutations": [
+        {
+          "op": "replace",
+          "path": "/evidence/receipt/decisions/0/purpose",
+          "value": "tampered-by-conformance-harness"
+        }
+      ]
+    },
+    {
+      "id": "tampered-challenge",
+      "now": "2030-01-01T00:05:00Z",
+      "expected_valid": false,
+      "mutations": [
+        {
+          "op": "replace",
+          "path": "/challenge/nonce",
+          "value": "tampered-challenge-nonce-000000000000000000000"
+        }
+      ]
+    },
+    {
+      "id": "expired-challenge",
+      "now": "2030-01-01T00:11:00Z",
+      "expected_valid": false,
+      "mutations": []
+    }
+  ],
+  "evidence_boundary": "This file defines project challenge inputs and expected validity. Matching it is black-box interoperability evidence, not certification or proof of implementation independence."
+}

conformance/verifier-challenge.json

@@ -4,6 +4,8 @@
   "canonical_repository": "https://github.com/aruintelligence/aml-core",
   "harness": "scripts/run-verifier-conformance.mjs",
   "witness_vector": "independent/python/witness-vector.json",
+  "cases_file": "conformance/verifier-challenge-cases.json",
+  "cases_sha256": "15409d9b921b8d8e16a54d9cb83760c102fa43ef4e9a349f195e4551e1beaa56",
   "command_contract": {
     "invocation": "<verifier-command> --now <ISO-8601> <bundle.json>",
     "stdout": "single JSON object",
@@ -17,32 +19,6 @@
     "must_bind_exact_witness_vector_sha256": true,
     "verifier": "scripts/verify-verifier-conformance-result.mjs"
   },
-  "cases": [
-    {
-      "id": "golden-valid",
-      "expected_valid": true,
-      "now": "2030-01-01T00:05:00Z",
-      "mutation": null
-    },
-    {
-      "id": "tampered-purpose",
-      "expected_valid": false,
-      "now": "2030-01-01T00:05:00Z",
-      "mutation": "evidence.receipt.decisions[0].purpose is changed"
-    },
-    {
-      "id": "tampered-challenge",
-      "expected_valid": false,
-      "now": "2030-01-01T00:05:00Z",
-      "mutation": "challenge.nonce is changed"
-    },
-    {
-      "id": "expired-challenge",
-      "expected_valid": false,
-      "now": "2030-01-01T00:11:00Z",
-      "mutation": null
-    }
-  ],
   "independence": {
     "required_for_external_witness_credit": true,
     "must_be_maintained_outside_canonical_repository": true,

docs/REAL_SCREEN_EVIDENCE_CONTRACT.md

@@ -0,0 +1,128 @@
+# ĀML™ Real-Screen Evidence Contract
+
+This document defines a common evidence shape for ĀML experiments against actual rendered interfaces.
+
+The purpose is reproducibility and provenance. It does not convert subjective review labels into objective measurements of cognition, attention, wellbeing, accessibility, morality, conversion, or business performance.
+
+## Required separation
+
+A real-screen experiment should keep these layers distinct:
+
+1. **production observation** — what was actually rendered or captured;
+2. **review labels** — explicit human or model-assisted judgments and their provenance;
+3. **deterministic policy** — the rule/version applied to those declared inputs;
+4. **receipt** — the resulting machine-readable decision evidence;
+5. **remediation** — code or content changes made after review;
+6. **after observation** — a new production capture proving what was actually deployed.
+
+Source-code remediation is not, by itself, production-after evidence.
+
+## Recommended experiment directory
+
+```text
+evidence/real-screen/YYYY-MM-DD-slug/
+  README.md
+  capture-metadata.json
+  screen.html
+  labels.json
+  receipt.json
+  REMEDIATION.md            # when a change is made
+  after/                    # when production after-capture exists
+    capture-metadata.json
+    screen.html
+    labels.json
+    receipt.json
+```
+
+Additional untouched screenshot, DOM, network, or browser artifacts may be preserved when the capture system supports them.
+
+## Capture metadata
+
+`capture-metadata.json` SHOULD record, where available:
+
+- source URL;
+- capture date/time and timezone;
+- capture agent/tool;
+- viewport and device-pixel-ratio;
+- scroll position;
+- page title;
+- hashes and byte sizes of screenshot, rendered HTML, DOM snapshot, or other preserved artifacts;
+- a clear description of which artifact is passed to the ĀML harness;
+- limitations of the capture.
+
+A hash proves byte identity. It does not prove that a label is correct or independent.
+
+## Labels and provenance
+
+`labels.json` SHOULD be separate from the captured screen material and SHOULD identify for each reviewed element:
+
+- stable element/review ID;
+- declared purpose;
+- `attention_cost`;
+- `restoration_value`;
+- provenance source kind;
+- reviewer/author identity or role where appropriate;
+- source reference tying the judgment to the capture;
+- whether the review is project-directed;
+- any disagreement or uncertainty worth preserving.
+
+The project MUST NOT describe these numeric labels as objective physiological, neurological, psychological, clinical, or scientific measurements unless independent evidence actually establishes that claim.
+
+## Policy binding
+
+The receipt SHOULD identify the exact policy/rule and software state used to evaluate the labels. For the minimal prototype gate:
+
+```text
+render_allowed = restoration_value >= attention_cost
+```
+
+A deterministic result proves that the declared inputs and rule reproduce the same decision. It does not prove that the inputs are universally correct.
+
+## Deterministic rerun
+
+Where feasible:
+
+1. run the harness once;
+2. preserve the receipt;
+3. run it again from the same captured input and labels;
+4. compare the resulting receipt bytes or documented deterministic fields;
+5. record PASS / FAIL / MIXED.
+
+Any nondeterminism should be surfaced, not hidden.
+
+## `real_screen_evidence_eligible`
+
+A project-controlled experiment SHOULD remain `real_screen_evidence_eligible: false` unless the repository's stated evidence requirements for that status are actually met.
+
+The flag must not be upgraded merely because:
+
+- the source URL is public;
+- the page belonged to ĀRU or a customer;
+- the project generated a receipt;
+- a build passed;
+- the project author agrees with the labels.
+
+## Before/after work
+
+An after-state should be treated as proven only after a new production capture is obtained. Preserve the previous capture rather than overwriting it.
+
+A remediation report SHOULD state:
+
+- exact element(s) changed;
+- what capability or restoration path was preserved;
+- before checkpoint/commit where available;
+- after checkpoint/commit where available;
+- whether production publication is verified;
+- what claims are *not* established by the intervention.
+
+## Capability preservation
+
+A SUPPRESS decision should not automatically mean deletion. For important controls, test whether the useful capability remains reachable through a lower-burden path. This project refers to that engineering pattern as **suppression without capability destruction**.
+
+## External sites
+
+Observational experiments on public third-party interfaces must not imply partnership, endorsement, audit authority, certification, or maintainer approval. Respect applicable terms, access controls, copyright, privacy, and security boundaries.
+
+## Claim boundary
+
+A real-screen evidence package can establish reproducibility of the captured bytes, declared labels, policy inputs, and deterministic output. On its own it does **not** establish conversion lift, user preference, cognitive benefit, accessibility conformance, safety, scientific validity, regulatory compliance, or independent adoption.

docs/RELEASE_DISCIPLINE.md

@@ -0,0 +1,89 @@
+# ĀML™ Release Discipline
+
+This document defines the minimum publication discipline for a release that is presented as a stable or externally testable ĀML™ software/protocol state.
+
+It is an engineering and evidence contract, not a claim of standards-body approval, certification, scientific validation, regulatory compliance, or universal production suitability.
+
+## Release identity
+
+A release intended for outside reproduction SHOULD identify all of the following:
+
+1. semantic version or prerelease identifier;
+2. immutable Git commit SHA;
+3. package version;
+4. applicable verifier-contract snapshot;
+5. applicable conformance/test-vector versions;
+6. cryptographic hashes for published release artifacts where practical;
+7. stable/preview/experimental status.
+
+A moving `main` branch is useful for development but is not a substitute for an immutable release identity.
+
+## Channels
+
+### Stable
+
+A stable release is the current supported package/API contract. Stable does not mean flawless, certified, scientifically validated, or suitable for every production system.
+
+### Preview / release candidate
+
+A preview may contain broader architecture intended for outside testing. Breaking changes remain possible and MUST be stated plainly.
+
+### Experimental
+
+Research artifacts, field experiments, draft RFCs, prototypes, and exploratory interfaces MUST remain distinguishable from the stable package contract.
+
+## Minimum release evidence
+
+Before calling a release ready for broad outside reproduction, the project SHOULD preserve:
+
+- the exact source commit;
+- automated test result(s);
+- public conformance result(s) where applicable;
+- package/artifact manifest and checksums where available;
+- external-verifier kit root and manifest where applicable;
+- verifier-contract snapshot and migration lineage;
+- known limitations and claim boundaries;
+- rollback or previous-stable reference.
+
+Where signed release/provenance artifacts exist, they SHOULD bind the exact artifact bytes and the release identity they represent.
+
+## Independent verification boundary
+
+Project-authored CI proves that project-authored checks passed for a particular state. It does not become independent evidence merely because it runs on GitHub infrastructure.
+
+Independent evidence requires an outside implementation, outside reproducer, or other evidence source that satisfies the relevant independence rules. PASS, FAIL, and MIXED results are all valid evidence states.
+
+## Release candidate checklist
+
+Before advancing a new stable release, verify:
+
+- [ ] package/API version coherence;
+- [ ] full automated test suite passes;
+- [ ] conformance and interoperability checks pass or known failures are disclosed;
+- [ ] security workflows have no unexplained blocking failure;
+- [ ] external verifier/witness artifacts build deterministically where applicable;
+- [ ] published hashes and manifests correspond to the final commit;
+- [ ] documentation links resolve;
+- [ ] licensing/trademark notices match the intended distribution model;
+- [ ] experimental claims are not presented as independent adoption or validation;
+- [ ] release notes state breaking changes, migrations, and known limitations.
+
+## Release receipts
+
+A release receipt SHOULD make it possible to answer, without trusting prose alone:
+
+- Which commit was released?
+- Which package version was released?
+- Which verifier contract applied?
+- Which tests or checks were run?
+- Which artifact hashes were published?
+- Which signing/trust policy applied?
+- What was stable versus experimental?
+
+## No retroactive evidence rewriting
+
+Historical releases, snapshots, receipts, and external witness records should remain append-only wherever practical. If a correction is necessary, preserve the original state and publish a correction or superseding record rather than silently rewriting the historical claim.
+
+## Commercial boundary
+
+Release availability under the repository software license does not itself grant rights to official ĀML™/ĀRU™ branding, certification-style identity, endorsement, OEM/co-branding, managed infrastructure, or separately licensed commercial offerings. See `LICENSING.md`, `TRADEMARKS.md`, and `COMMERCIAL.md`.