Independent Implementation Challenge: build an ĀML verifier without the reference runtime

[aruintelligence]

Challenge

Build an ĀML verifier in an outside repository/runtime using the public protocol, schemas, vectors, verifier-contract snapshot, and reference-code-free External Verifier Kit — without importing or wrapping the canonical aml-core verifier/runtime as the decision engine.

The goal is falsifiable interoperability evidence, not endorsement.

Start with:

• publications/INDEPENDENT_IMPLEMENTATION_CHALLENGE.md
• publications/EXTERNAL_VERIFIER_CHALLENGE.md
• publications/WITNESS_SUBMISSION.md
• protocol/VERIFIER_CONTRACT_VERSIONING.md

Build the reference-code-free kit:

node scripts/build-external-verifier-kit.mjs

Then run the black-box harness against your implementation:

node scripts/run-verifier-conformance.mjs -- <your-verifier-command> [args...]

Report

Please publish PASS / FAIL / MIXED and include:

• outside implementation repository + immutable commit SHA;
• language/runtime version;
• exact ĀML release/commit tested;
• verifier-contract snapshot ID;
• challenge and witness-vector SHA-256 identifiers;
• case-corpus SHA-256 when available;
• per-case outcomes;
• reproduction command;
• any ambiguity, divergence, or unsupported behavior you found.

Negative evidence is welcome. If the public material is underspecified, a reproducible FAIL or MIXED report is useful evidence and should drive a contract fix rather than be explained away.

Independence boundary

For independent-implementation credit, the implementation should live outside aruintelligence/aml-core, should not import the project-maintained reference verifier, and should not shell out to the aml-core CLI/API as its underlying decision engine. Disclose meaningful shared implementation code or dependencies.

A project-defined black-box PASS is compatibility evidence for the exact tested contract. It is not certification, proof of implementation independence, standards-body approval, scientific validation, regulatory compliance, safety, production suitability, or broad adoption.

Technical implementation/testing also does not automatically grant official ĀML™ branding, certification-style marks, endorsement, partnership, or other reserved trademark rights. See LICENSING.md and TRADEMARKS.md.