APL Protocol Specification (v1.0.0)


Author:   Dmitrii Zatona (NETECT INTELLIGENCE CORP.)
Status:   Draft Standard
Version:  1.0.0
Date:     April 2026

This document specifies the Anchored Parallax Log (APL) Protocol version 1.0.0.

Abstract

APL defines a minimal protocol for frame-bound observation claims — statements about the world that are cryptographically inseparable from the explicit context (the frame) under which they were made.

APL does not decide whether a claim is “true”. It binds a claim to a content-addressed frame, defines the validity rules for that binding, and specifies the verifier’s observable outcomes. Meaning under frame is the protocol’s unit of work.

In the reference profile APL-on-ATL, metadata.apl is embedded inside an ATL Receipt and inherits ATL’s cryptographic properties (binding of payload and metadata, inclusion, append-only history, external anchoring, offline verification). APL is substrate-agnostic: any carrier that satisfies the minimal contract in Section 5.1 is a conforming substrate.

Version 1.0 defines the minimal core: the frame-bound claim, the content-addressed frame, pairwise relation evaluation with explicit bridges and transformations, and a deterministic verifier contract with the outcomes apl-valid and apl-invalid.

1. Introduction

Cryptographic substrates such as ATL prove existence, integrity, and history of records. They do not, by themselves, prevent a record from being misread — stripped of its context, silently compared to another record produced under different assumptions, or treated as a universal fact when it is in fact situated.

The APL Protocol addresses this gap on the semantic layer. Every APL claim MUST reference a frame by content hash. The frame declares what was observed, how, under which assumptions, and what is explicitly not claimed. A verifier resolves the frame, checks that the claim is structurally bound to it, and returns a deterministic outcome.

ATL proves existence and history; APL specifies meaning under frame.

1.1. Core Philosophy

The APL Protocol is built upon four principles.

Frame-Bound by Construction: A claim without a pinned frame is not an APL claim. frame_ref is REQUIRED on every claim.
Content-Addressed Identity: Frames, bridges, and transformations are identified by SHA-256 of their JCS-canonicalized bytes. Aliases, URLs, and registries are for discovery only — never for identity.
No Implicit Comparison: Two claims under different frames are incomparable by default. Cross-frame comparison requires an explicit, content-addressed Bridge declaring scope, assumptions, and losses.
No Silent Semantic Loss: Transformations MUST declare preserved invariants and losses explicitly. Empty losses means “nothing is lost” — never “unknown”.

Substrate-Agnostic Design: APL does not define a log. It delegates existence, integrity, and history to an external substrate (called the carrier). The reference profile APL-on-ATL uses ATL Receipts as carriers, but any carrier meeting the minimal contract in Section 5.1 is conforming.

Receipt-Centric: The APL Receipt (a carrier-borne artifact containing metadata.apl + pinned frame reference + optional bridges/transformations) is the primary unit of exchange. All verification operates on receipts.

Profile Layering: APL Core is deliberately domain-agnostic. Domain-specific vocabularies, truth criteria, frame families, and marketplace rules live in vertical profiles (e.g., APL/AI-Eval, APL/Photojournalism) outside of Core. Profiles MAY tighten Core requirements but MUST NOT relax them.

1.2. Trust Model

A conforming APL verifier answers exactly one core question:

Is this receipt a valid frame-bound observation claim under a resolved frame?

The answer is exactly one of:

apl-valid — the carrier proof is valid, metadata.apl is well-formed, the referenced frame is resolved and its content hash matches, the frame kernel is structurally valid, every element of claim.aspect_refs is present in frame.aspect, and — if claim.related_frames, bridge_refs, or transformation_refs are present — those relation-layer fields are structurally valid.
apl-invalid — any of the above fails.

apl-valid does NOT mean:

The claim is true.
The frame is correct in substance.
The claim is comparable to any other claim.
Relation-layer semantics (bridges, transformations) have been evaluated.

Implication: APL’s trust surface is the content-addressed frame and the carrier proof. Registries, resolvers, and alias systems are conveniences; they are never trust anchors. A verifier that has never seen a particular registry can fully validate a receipt as long as it possesses (or can resolve by hash) the pinned frame.

1.3. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

APL Receipt: A portable artifact carrying a carrier proof, an APL claim, a pinned frame reference, and optional bridge/transformation references. In APL-on-ATL, the APL Receipt is an ATL Receipt containing metadata.apl.
APL Claim: A minimal situated assertion about the outcome of an observation. Structurally bound to a frame by frame_ref.
APL Frame: A content-addressed artifact describing the discipline of observation and interpretation under which claims pinned to it MUST be read.
APL Bridge: A content-addressed artifact describing a permissible cross-frame comparison between two frames, together with assumptions and declared losses.
APL Transformation: A content-addressed artifact describing a transformation’s declared preserved invariants and declared losses.
Carrier Proof: A cryptographic proof of integrity and history for an APL Receipt. In APL-on-ATL, the carrier proof is provided by the ATL Receipt.
Reference Object: A { hash, resolver_hint? } pair used to reference a content-addressed APL artifact. hash is identity; resolver_hint is only a hint.
Verifier: The component that evaluates an APL Receipt against the rules in this document.

2. Cryptographic Primitives

To ensure interoperability and security, APL implementations MUST adhere to the following standards.

2.1. Hashing Algorithm

All content-addressed references in APL Core MUST use SHA-256 [RFC6234]. In text representations (JSON), hashes MUST be encoded as lowercase hexadecimal strings prefixed with sha256:.


Example: "sha256:0123abcd..."

2.2. Canonicalization

To ensure deterministic content-addressing, all JSON artifacts (APL Frame, APL Bridge, APL Transformation) MUST be canonicalized according to the JSON Canonicalization Scheme (JCS) [RFC8785] before being hashed.

When APL Core or a vertical profile requires checking that two JSON objects are identical, a verifier MUST compare the exact byte equality of their JCS-canonicalized representations. If an algorithm requires comparing objects after removing one or more fields, the verifier MUST:

Remove the specified fields from each compared object.
JCS-canonicalize the resulting objects.
Compare the resulting byte sequences for exact equality.

No other field-order-sensitive, whitespace-sensitive, or implementation-specific textual comparison is considered normatively compatible.

2.3. Content-Addressed Identity

APL Core distinguishes identity from resolution.

hash is identity.
resolver_hint, alias, path, URL, or registry location MAY be used for resolution, but MUST NOT be used as canonical identity.

When an APL artifact references another content-addressed artifact, the reference SHOULD use the following form (the Reference Object):


{
  "hash": "sha256:0123abcd...",
  "resolver_hint": "optional-location-or-uri"
}

hash is REQUIRED and MUST be a string in the form defined in Section 2.1.
resolver_hint is OPTIONAL. If present, it MUST be a non-empty string.

3. Core Artifacts

APL Core defines four artifact kinds. The APL Claim lives inside an APL Receipt (and is covered by the carrier proof). The APL Frame, Bridge, and Transformation are content-addressed and identified by SHA-256(JCS(bytes)). Structural requirements (required and optional fields, typing rules) are specified in this section; complete JSON wire forms for APL Receipt, APL Frame, and Verifier Output are in Section 4.

3.1. APL Claim

An APL Claim is a situated assertion about the outcome of an observation. In the APL-on-ATL profile, the complete APL payload lives in metadata.apl, which is itself structured as:


metadata.apl = {
  version,        // REQUIRED
  claim,          // REQUIRED object
  frame_ref,      // REQUIRED Reference Object
  bridge_refs?,   // OPTIONAL, non-empty array of Reference Objects
  transformation_refs?  // OPTIONAL, non-empty array of Reference Objects
}

Top-level fields of metadata.apl:

version — REQUIRED. MUST be "1.0" for APL Core v1.0.
claim — REQUIRED. JSON object whose fields are defined below.
frame_ref — REQUIRED. Reference Object pinning the frame.
bridge_refs — OPTIONAL. If present, MUST be a non-empty array of Reference Objects pointing to APL Bridge artifacts. See Section 3.3.
transformation_refs — OPTIONAL. If present, MUST be a non-empty array of Reference Objects pointing to APL Transformation artifacts. See Section 3.4.

Required fields inside claim:

claim.kind — MUST be "observation" in v1.0.
claim.subject — JSON object identifying what is being asserted about. MUST contain at least one of id (non-empty string) or digest (valid hash string).
claim.aspect_refs — non-empty array of unique non-empty strings; each MUST appear in frame.aspect.
claim.statement — JSON object with REQUIRED predicate (non-empty string) and content (any JSON value).

Optional fields inside claim:

claim.related_frames — if present, MUST be a non-empty array of unique hash strings. Used as a relation-layer discovery hint only (see Section 5.8).

3.2. APL Frame

An APL Frame declares the discipline of observation and interpretation under which claims pinned to it MUST be read.

The minimal Frame kernel MUST contain:

version — MUST be "1.0" for APL Core v1.0.
observer — non-empty JSON string or object identifying the observing agent.
aspect — non-empty array of unique non-empty strings enumerating what is being observed.
invariance — non-empty array of unique non-empty strings enumerating what is preserved under listed transformations.
exclusions — non-empty array of unique non-empty strings enumerating what is explicitly NOT claimed.

A Frame MUST additionally contain at least one of procedure or instrument, and at least one of scope or resolution.

Optional fields include extends (Reference Object), aliases, and notes. extends MAY be used for composition but MUST NOT substitute for the mandatory frame kernel. Operational lifecycle of frames (versioning, extends, successor lines, forks) is defined in a separate APL Lifecycle Rules annex.

3.3. APL Bridge

An APL Bridge declares the conditions under which claims from two frames MAY be treated as comparable.

A minimal Bridge MUST contain:

version, source_frame (Reference Object), target_frame (Reference Object).
comparison_scope — JSON object with REQUIRED fields:
- source_aspects — non-empty array of unique non-empty strings.
- target_aspects — non-empty array of unique non-empty strings.
- relation_type — non-empty string.
assumptions — array of unique non-empty strings. MAY be empty.
losses — array of unique non-empty strings. MAY be empty, but MUST NOT mean “unknown”.

Bridges are directional (source_frame → target_frame). A Bridge MUST NOT assert general equivalence of frames; it only licenses comparison within the declared comparison_scope.

3.4. APL Transformation

An APL Transformation declares the semantic effect of applying a transformation to observations.

A minimal Transformation MUST contain:

version, procedure.
preserves — array of explicitly preserved invariants.
losses — array of explicitly declared losses.

Absence of declared losses MAY be encoded as an empty array but MUST NOT mean “unknown”.

4. Data Structures

4.1. APL Receipt (APL-on-ATL Profile)

In the reference profile APL-on-ATL, the APL Receipt is an ATL Receipt containing metadata.apl inside entry.metadata. The ATL Receipt structure is defined in the ATL Protocol Specification ; APL adds the semantic payload.


{
  "spec_version": "2.0.0",
  "entry": {
    "id": "<UUID>",
    "payload_hash": "sha256:<hex>",
    "metadata_hash": "sha256:<hex>",
    "metadata": {
      "apl": {
        "version": "1.0",
        "claim": { /* see Section 3.1 */ },
        "frame_ref": { "hash": "sha256:<hex>" }
      }
    }
  },
  "proof": { /* ATL inclusion proof */ },
  "super_proof": { /* ATL Super-Tree proof */ },
  "anchors": [ /* RFC 3161, Bitcoin OTS */ ]
}

Field Definitions (APL-specific):

entry.metadata.apl (REQUIRED for APL): The APL payload envelope. Its structure is defined in Section 3.1.
entry.metadata.apl.version (REQUIRED): MUST be "1.0" for APL Core v1.0.
entry.metadata.apl.claim (REQUIRED): The APL Claim object (Section 3.1).
entry.metadata.apl.frame_ref (REQUIRED): Reference Object pinning the frame.
entry.metadata.apl.bridge_refs (OPTIONAL): Non-empty array of Reference Objects pointing to APL Bridge artifacts.
entry.metadata.apl.transformation_refs (OPTIONAL): Non-empty array of Reference Objects pointing to APL Transformation artifacts.

The ATL Receipt’s LeafHash = SHA256(0x00 || PayloadHash || MetadataHash) covers MetadataHash = SHA256(JCS(metadata)), which transitively binds metadata.apl to the carrier proof. No additional APL-level cryptography is required.

4.2. APL Frame (JSON)

A minimal APL Frame document:


{
  "version": "1.0",
  "observer": "acme-eval-runner",
  "procedure": "benchmark-run/lm-eval-harness@0.4.2",
  "aspect": ["accuracy"],
  "scope": "mmlu/dev",
  "invariance": ["score object serialization"],
  "exclusions": [
    "no claim about production readiness",
    "no claim about deployment safety"
  ]
}

The frame’s identity is SHA-256(JCS(frame)).

4.3. Verifier Output (JSON)

A conforming verifier SHOULD produce output of the following logical form:


{
  "core_outcome": "apl-valid",
  "relation_outcome": "relation-not-evaluated",
  "failure_classes": [],
  "diagnostics": [
    "carrier-valid",
    "apl-present",
    "apl-frame-bound"
  ]
}

core_outcome (REQUIRED): Exactly one of apl-valid or apl-invalid.
relation_outcome (SHOULD be present): One of relation-not-evaluated, same-frame-comparable, bridged-comparable, incomparable.
failure_classes (SHOULD be empty for apl-valid, SHOULD contain at least one class marker for apl-invalid): One or more of carrier-failure, claim-structure-failure, reference-failure, frame-failure, semantic-linkage-failure, relation-structure-failure.
diagnostics (OPTIONAL, RECOMMENDED): Fine-grained status codes for explainability. The full code set is enumerated in Data Structures.

5. Verification Algorithm

A conforming APL verifier MUST perform the following steps on every APL Receipt. If any step determines the receipt is invalid, the verifier MUST return apl-invalid with the appropriate failure class and MUST NOT proceed to subsequent steps that depend on the failed precondition.

5.1. Step 1: Carrier Verification

The verifier MUST verify the carrier proof through an external carrier verifier, treated as a black box. The verifier MUST NOT reimplement carrier-layer cryptography inside the APL layer.

The minimal carrier verification contract for APL-on-ATL is:


verify_carrier(receipt_bytes) -> {
  carrier_outcome: valid | invalid,
  payload: <carrier payload>,
  metadata: <carrier metadata object>
}

Where:

carrier_outcome = invalid means the carrier proof failed verification.
carrier_outcome = valid means payload and metadata were retrieved from a successfully verified carrier artifact.
metadata is the authoritative source for APL extraction in APL-on-ATL.

If carrier_outcome = invalid, the verifier MUST return apl-invalid and MUST NOT proceed. The verifier SHOULD classify the failure under one or more failure classes; carrier-failure SHOULD be among them. Any ATL implementation providing this minimal contract is a compatible carrier layer.

5.2. Step 2: Extract `metadata.apl`

From the carrier-supplied metadata, extract the metadata.apl object.

The receipt MUST be considered apl-invalid if metadata.apl is absent or is not a JSON object. The verifier SHOULD include claim-structure-failure in failure_classes.

5.3. Step 3: Verify Claim Structure

The verifier MUST check that metadata.apl conforms to Section 3.1. Specifically, the receipt MUST be apl-invalid if any of the following applies:

version is absent or not supported.
claim is absent or malformed.
claim.kind is absent or is not "observation" in v1.0.
claim.subject is absent, is not a JSON object, or contains neither a non-empty id string nor a valid digest hash string.
claim.aspect_refs is absent, empty, or contains non-string, empty-string, or duplicate entries.
claim.statement is absent, is not a JSON object, or lacks predicate (non-empty string) or content.
frame_ref is absent or is not a valid Reference Object (Section 2.3).
frame_ref.hash is absent or is not a valid hash string.

The verifier SHOULD classify failures in this step under one or more failure classes, typically including claim-structure-failure and/or reference-failure. Multiple classes MAY be reported for a single receipt.

5.4. Step 4: Resolve Frame and Verify Identity

The verifier MUST resolve the APL Frame from any compatible source:

Local bundle / sidecar.
Local cache.
Direct content-addressed retrieval.
Registry retrieval.
Out-of-band supplied artifact.

The verifier MUST compute SHA-256(JCS(resolved_frame)) and compare it to frame_ref.hash by exact byte equality.

The receipt MUST be considered apl-invalid if:

The frame cannot be supplied or resolved from any compatible source.
The hash of the resolved frame does not match frame_ref.hash.

The verifier SHOULD include frame-failure in failure_classes for failures in this step. Registry unavailability alone is NOT a core failure — if the frame is already locally available and matches the pinned hash, no registry is required.

5.5. Step 5: Verify Frame Kernel

The verifier MUST check that the resolved Frame conforms to Section 3.2:

version is present and supported.
observer, aspect, invariance, exclusions are structurally valid.
At least one of procedure or instrument is present.
At least one of scope or resolution is present.

Any failure here MUST produce apl-invalid. The verifier SHOULD include frame-failure in failure_classes.

5.6. Step 6: Verify Aspect Linkage

Every element of claim.aspect_refs MUST appear in frame.aspect. If any element is out of frame, the receipt MUST be considered apl-invalid. The verifier SHOULD include semantic-linkage-failure in failure_classes.

5.7. Step 7: Verify Relation-Layer Structural Conformance

If claim.related_frames, bridge_refs, or transformation_refs are present in metadata.apl, they MUST be structurally valid.

The receipt MUST be considered apl-invalid if any of the following applies:

claim.related_frames is present but is not a non-empty array of unique hash strings.
bridge_refs is present but is not a non-empty array of valid Reference Objects (Section 2.3).
transformation_refs is present but is not a non-empty array of valid Reference Objects (Section 2.3).

The verifier SHOULD include relation-structure-failure in failure_classes for failures in this step.

Structural validation at this step concerns shape only. Whether a bridge is applicable to a specific pairwise query is evaluated separately in Section 5.8.

5.8. Pairwise Relation Evaluation (Optional)

A conforming APL verifier MAY operate in pairwise mode. In pairwise mode, the verifier evaluates a relation_query against two APL Receipts and returns exactly one relation outcome. This section defines the normative pairwise contract.

5.8.1. Compared Unit

In pairwise mode the compared units are two APL claims — not raw receipts and not frames. Each claim:

Is carried by its own receipt.
Is pinned to its own frame.
MUST be core-valid (Sections 5.1–5.7) or already accepted as apl-valid by a prior invocation.

Receipts are carrier artifacts. Frames and bridges are relation artifacts.

5.8.2. Input Model

A pairwise verifier MUST accept:

left_receipt
right_receipt
relation_query

A pairwise verifier MAY additionally accept:

Supplied bridge artifacts.
Supplied transformation artifacts.
Prevalidated core outcomes for both receipts.

5.8.3. Relation Query

A relation_query MUST have the form:


{
  "left_aspects": ["aspect-a"],
  "right_aspects": ["aspect-b"],
  "predicate": "declared-predicate",
  "relation_type": "declared-relation"
}

Where:

left_aspects MUST be a non-empty array of unique non-empty strings.
right_aspects MUST be a non-empty array of unique non-empty strings.
predicate MUST be a non-empty string.
relation_type MUST be a non-empty string.

Additionally:

left_aspects MUST be a subset of left_receipt.claim.aspect_refs.
right_aspects MUST be a subset of right_receipt.claim.aspect_refs.
predicate MUST match left_receipt.claim.statement.predicate.
predicate MUST match right_receipt.claim.statement.predicate.

5.8.4. Preconditions

A pairwise verifier MUST return relation-not-evaluated if any of the following holds:

Either receipt failed or cannot be validated against APL Core (Sections 5.1–5.7).
relation_query is structurally invalid (any of the constraints in 5.8.3 fails).
relation_query.left_aspects is not a subset of left_receipt.claim.aspect_refs.
relation_query.right_aspects is not a subset of right_receipt.claim.aspect_refs.
relation_query.predicate does not match either receipt’s claim.statement.predicate.

The verifier SHOULD return diagnostics identifying the precondition failure.

5.8.5. Statement Structural Compatibility

Two statements are considered structurally compatible in APL Core if and only if all of the following hold:

left_receipt.claim.statement.predicate equals right_receipt.claim.statement.predicate.
left_receipt.claim.statement.content and right_receipt.claim.statement.content share the same top-level JSON type.
If both statement.content values are JSON objects, their key sets are identical.

APL Core does not perform deeper content-level semantic inference.

5.8.6. Bridge Applicability

A Bridge is applicable to a pairwise query if and only if all of the following hold.

Frame Match. bridge.source_frame.hash MUST equal left_receipt.frame_ref.hash. bridge.target_frame.hash MUST equal right_receipt.frame_ref.hash. Bridges are directional; reversing the direction requires a bridge applicable to that direction.

Scope Match. relation_query.left_aspects MUST be a subset of bridge.comparison_scope.source_aspects. relation_query.right_aspects MUST be a subset of bridge.comparison_scope.target_aspects. relation_query.relation_type MUST equal bridge.comparison_scope.relation_type.

Bridge Limits. A Bridge MUST NOT license general frame equivalence; it licenses only the comparison expressed by its comparison_scope, assumptions, and losses.

Profile Tightening. Vertical profiles MAY define a stricter applicability algorithm: tighter scope equality, bridge-kind-specific checks, or required profile-specific diagnostics. Profiles MUST NOT relax core requirements on directionality, frame match, or scope match.

Structurally invalid bridges MUST be ignored as non-applicable artifacts.

5.8.7. Pairwise Algorithm

A pairwise verifier MUST perform the following steps.

Verify or accept apl-valid for left_receipt.
Verify or accept apl-valid for right_receipt.
Verify structural validity of relation_query.
Verify relation_query.left_aspects is a subset of left_receipt.claim.aspect_refs.
Verify relation_query.right_aspects is a subset of right_receipt.claim.aspect_refs.
Verify relation_query.predicate equals left_receipt.claim.statement.predicate.
Verify relation_query.predicate equals right_receipt.claim.statement.predicate.
If any precondition above fails, return relation-not-evaluated.
Check statement structural compatibility (Section 5.8.5). If incompatible, return incomparable.
If left_receipt.frame_ref.hash equals right_receipt.frame_ref.hash:

If relation_query.left_aspects and relation_query.right_aspects are identical as sets, return same-frame-comparable.
Otherwise, return incomparable.

Otherwise, collect applicable bridge candidates from:

left_receipt.bridge_refs
right_receipt.bridge_refs
Supplied bridge artifacts
Local bridge cache
Compatible registry retrieval

For each bridge, check structural validity, frame match, scope match, and any active profile-specific bridge algorithm (Section 5.8.6).
Structurally invalid bridges MUST be ignored as non-applicable artifacts.
If at least one applicable bridge is found, return bridged-comparable.
If no applicable bridge is found, return incomparable.

5.8.8. Outcomes

A pairwise verifier MUST return exactly one relation outcome:

relation-not-evaluated — precondition failure (see 5.8.4).
same-frame-comparable — both receipts are apl-valid, pinned to the same frame, queried aspect sets are identical, relation_query.predicate equals both claim predicates, and statements are structurally compatible.
bridged-comparable — both receipts are apl-valid, frames differ, relation_query.predicate equals both claim predicates, statements are structurally compatible, and at least one applicable bridge was found (passing Core and active-profile checks).
incomparable — preconditions are met, but neither same-frame equality nor an applicable bridge licenses the comparison.

5.8.9. Normative Consequences

The following follow directly from the algorithm above:

Same frame alone does NOT license arbitrary cross-aspect comparison.
Same frame alone does NOT license cross-predicate comparison.
claim.related_frames does NOT make a comparison admissible; it is a discovery hint only.
A transformation declaration does NOT make cross-frame comparison admissible.

In APL Core, comparison is admissible only in two cases:

Same frame, plus identical queried aspect sets, plus a predicate-aligned, structurally compatible pair of statements.
Cross-frame pair, plus an applicable directional bridge, plus a predicate-aligned, structurally compatible pair of statements.

5.9. Verifier Output

The verifier MUST return a Verifier Output object (Section 4.3) containing core_outcome, relation_outcome, failure_classes, and diagnostics.

6. Security Considerations

6.1. No Truth Guarantee

APL Core does not prove the truth of any claim or the substantive correctness of any frame. It proves that semantic context is explicit and inseparable from the claim. A frame can be well-formed and still describe a badly-chosen methodology; a claim can be apl-valid and substantively misleading.

Vertical profiles are the right place for domain-specific substantive criteria. APL Core is deliberately silent on truth.

6.2. Mutable Resolution Is Not Identity

Resolver hints, aliases, and registry paths are convenient — and dangerous. A verifier that treats an alias or URL as identity is trivially attackable: an attacker swaps the served bytes, and the verifier accepts the swap silently.

APL Core MUST use the content hash as identity. Aliases and URLs MUST serve only as resolution hints. Any conforming verifier that resolves a frame via alias MUST verify the content hash before accepting the frame.

6.3. Overbroad Frames

A frame can pass all Core validity checks and still be practically useless if its aspect, invariance, exclusions, and scope are so broad that they exclude nothing meaningful. Overbroad frames enable frame laundering: a claim appears frame-bound but the frame carries no discriminating power.

Vertical profiles SHOULD define acceptable granularity for their domain. APL Core does not dictate specific granularity but notes that apl-valid is a necessary, not sufficient, condition for meaningful frame binding.

6.4. Bridge Abuse

Bridges can be misused to manufacture comparability between fundamentally incompatible frames. A Bridge whose assumptions are vacuous or whose losses silently swallow all meaningful differences is a vector for frame laundering at the relation layer.

APL Core requires every Bridge to declare comparison_scope (including relation_type), assumptions, and losses. A verifier SHOULD treat a Bridge with empty assumptions and empty losses but nontrivial comparison_scope as suspicious. Profiles MAY mandate minimum informativity.

6.5. Attack Classes Addressed by APL

APL Core is designed against three concrete adversarial patterns:

Decontextualization attack — a result from one narrow observation context is presented as a general property of the subject.
Frame laundering — a common label (e.g., “MMLU”) masks substantive differences between harnesses, graders, scopes, or protocols.
Semantic overclaim — from a narrow benchmark observation, a claim of overall quality, deployment readiness, or safety is derived.

Out of scope: the knowing publication of a false claim or a false frame. In scope: hidden context, mutable identity, and silent semantic drift.