ActQL conformance

Specification index

This document owns claims, profile-dependencies, corpora, evidence, release-combinations. It does not define other owners' wire protocols or a particular Host implementation. Cross-owner links outside the declared dependencies are informative navigation to protocol bindings or conformance evidence; they do not import those documents' requirements. Narrow machine contracts remain authoritative for their explicitly referenced values and envelopes.

On this pageCopy Anchor Link

• Conformance profiles
• Conformance and versioning
• Product boundary acceptance
• Conformance claims
• Module closure workloads
• Conformance tests and reports
• Additional Operations conformance
• Versioning
• Artifact and companion contract index (normative)

Conformance profilesCopy Anchor Link

ActQL 0.1 defines a required language Core, a required RelA module, three optional algebra modules, and the optional profiles listed below. Each claim covers the complete profile, not a selection of its operations:

actql-core/0.1   sources, contracts, diagnostics, Results, delivery, receipts, checked effects
actql-rela/0.1   relation algebra
actql-sga/0.1    graph algebra
actql-veca/0.1   vector algebra
actql-tea/0.1    event algebra
actql-infer/0.1  bounded structured model acquisition
actql-text-time/0.1 composable pure text, UTC time, and regular expressions
actql-lookup/0.1 bounded acquisition for a keyed external join
actql-content/0.1 bounded Artifact serialization
actql-text-rank/0.1 pure lexical ranking over a finite corpus
actql-search/0.1 bounded external ranked candidate acquisition
actql-calendar/0.1 explicit-zone Gregorian buckets and series

The Core/RelA combination includes the expression 0.1 contract pinned by Language. Parsing alone does not establish typed lowering, demanded bounds, or execution conformance to that contract.

Expression conformance includes boolean-null preservation in values and condition consumption, all-branch static checks versus demanded conversion failures, aggregate-filter-before-argument evaluation, cast/structured identity, typed-null and empty-array inference, nullable parents, invalid versus out-of-range indices, join qualification, decimal negation, string boundary cases, and unchanged Effect selector restrictions. Optimized and reference execution are compared for required failure and logical limits as well as values, under the exact pinned value laws.

An implementation MUST accept every valid program and reject every invalid program within every module it claims. A generally usable ActQL 0.1 implementation MUST claim Core and RelA together. SGA, VecA, TEA, infer, text-time, lookup, artifact, text-rank, search and calendar are optional claims, but each is indivisible. Text-rank additionally requires the pinned Unicode normalization/case-fold laws, not a claim to every text-time function. Calendar requires TEA and its pinned timezone/transition contract. Search requires Core/RelA acquisition contracts, not VecA: vector requests additionally require their declared vector value contracts, while pure nearest remains VecA. Implementing one or two named operators is partial support, not module conformance. An implementation MUST publish complete module claims separately from partial operation support and MUST reject an unimplemented operation during check rather than changing its meaning.

Within their supported profile sets, conforming checkers MUST produce the same canonical AoA Fragments, Executable Plan, and semantic identities for the same source, bound values, and Check Environment under the contracts in Canonical identities and AoA fragments and algebra lowering. This equality concerns the canonical checked envelope, not identical physical execution strategies (Typed barriers and Plan Documents).

An unclaimed checker profile MUST be rejected with ACTQL_E_PROFILE_UNSUPPORTED before computation, provider access, byte publication, or Effect dispatch. Rejection does not require complete type checking, lowering, or Plan identity assignment for that profile. Known profile vocabulary MUST NOT be reported as unknown or silently lowered to weaker semantics.

A checker MAY publish a fully validated Plan with unsupported when only execution is unsupported. Any published Plan MUST satisfy the same canonical contracts as a supported Plan.

Profile workloads, conformance evidence, and versioning are specified in Conformance and versioning.

Conformance and versioningCopy Anchor Link

Product boundary acceptanceCopy Anchor Link

The adopted stage, authorization, recovery, Catalog, infer, numeric observation, input normalization, parameter and projection rules are adopted semantics. A full claim MUST include positive/negative, crash, replay, scope, canonical artifact and independent cross-target evidence for those rules. Schema validation or unrelated passing tests do not establish their execution conformance. Alpha/beta distribution policy is a separate gate: it may disclose partial support and known gaps, but cannot claim full compliance or silently execute unsupported syntax with different semantics.

The non-normative acceptance mappings connect design requirements to independent acceptance cases, Program fixtures and Host assumptions. These definitions do not constitute execution evidence. Compatible Connector-lock automatic renewal and cross-Run model cache remain deferred, not implied by stale renewal or replay. Existing pinned contracts remain available to retained Runs; secret rotation does not alone invalidate static Catalog identity.

Authoring and execution verificationCopy Anchor Link

The authoring surface is SQL with Pipe syntax (query text); the stage model with map/ordered-array derive and select is the canonical lowered form it compiles to. Authoring evaluation measures intent preservation, successful checking, diagnostic repair, field leakage, shadowed-value confusion, coverage and cost. Evaluation does not introduce unregistered source spellings. Explicit frontend profiles and their implementation evidence are tracked in the Frontend r1 registry; adoption alone does not establish parser or Host conformance. Independent curators seal task variants, contract pins, seeds and oracles before isolated sessions; answers stay out of author context and failed attempts remain in the results. Examples and acceptance cases are not execution evidence by themselves.

Before freezing the source syntax for a Final release, authoring evaluation MUST measure first-check validity, intent agreement and one-repair convergence on isolated holdout tasks. The adopted syntax remains the implementation target; an evaluation that has not run is reported as unexecuted, not as passing evidence.

Runtime evidence compares direct stages and extracted graph Programs for local approval noninterference, membership, shared budget, normal/exceptional cursor commit, fault/replay and recovery eligibility. Schema tests alone are not these execution tests.

Conformance claimsCopy Anchor Link

An implementation is conforming only if it publishes one exact content- addressed ConformanceClaim and:

1. accepts every valid program within its claimed profile set and rejects unclaimed profiles as specified in Conformance profiles;
2. rejects every program that violates a closed vocabulary or required semantic choice;
3. produces byte-identical canonical AoA IR for every algebraic fragment and byte-identical canonical Executable Plans and semantic identities under the same bound values, Check Environment, and semantic contracts (Conformance profiles);
4. records every authoring normalization and deterministic completion;
5. does not resolve a semantic ambiguity by guessing; and
6. preserves the determinism and ordering requirements in this specification.

Module closure workloadsCopy Anchor Link

Operation count is not a completeness criterion. A module claim is valid only when independent conformance programs can express and execute its closure workload without Python post-processing, hidden carrier manipulation, or a provider-specific semantic escape hatch:

The normative operation and law inventory for these flows is published by ACTQL_MODULES.

Conformance tests and reportsCopy Anchor Link

The nest canonical corpus is generated by the independent Python lowering, not by the production compiler. It covers the declared fixture subset, including reference aliases, existing-order reuse, item/byte binding proofs and typed empty arrays. Its exact-graph checks supplement, rather than replace, the separate value/order oracle and runtime failure tests. The corpus includes explicit staged inputs, stage and Program identity envelopes, and canonical AoA identities.

A conforming implementation MUST publish and pass:

1. parser rejection cases for YAML features outside the JSON data model;
2. valid and invalid examples for every operation;
3. canonical-vocabulary negative tests proving undocumented spellings cannot execute;
4. deterministic-completion idempotence tests;
5. ambiguity-preservation tests with stable candidate order;
6. AoA Carrier-sort, arity, field, identity, bridge, and ordering negative tests;
7. independent oracle cross-checks for Core/effect semantics, the required RelA closure workload, and every optional algebra module claimed;
8. empty-Result schema and manifest tests;
9. Run Receipt, Result Manifest, Result Artifact, delivery-receipt, and delivered-byte tamper tests;
10. five-run reproducibility tests over fixed inputs;
11. canonical diagnostic ordering, replacement/candidate exclusivity, stable candidate ordering, and diagnostic-CID reproducibility tests;
12. row-effect tests covering AoA EFFECT.plan lowering, per-row values, complete resolved mapping contract identity, exact permission derivation, duplicate identity, missing target, target type mismatch, differently named output/target upsert keys, explicit write fields, max_items, normative row idempotency, execution-account routing without a Connector approval floor, single-effect/failure-policy semantics, and preview-CID reproducibility;
13. typed-input, unnest, complete closed expression, representative-dedupe, composite/full join cardinality/null/output-bound, global/partitioned rank, order-sensitive operation, and append schema/nullability tests;
14. for each claimed algebra, an end-to-end closure-workload test from Module closure workloads, including negative vectors for every semantic choice and exclusion;
15. SGA path-order/identity oracle tests, VecA quantization/pool/ranking-merge oracle tests, and TEA boundary/session/dedupe/as-of/sequence oracle tests whenever those modules are claimed;
16. pinned diagnostic-catalog and AoA-contract CID tests;
17. for each claimed acquisition or Artifact profile, bound-overflow, duplicate/correlation, atomic-publication, captured-replay, data-egress, and no-implicit-join-back negative vectors;
18. for a claimed Run Graph or HTTP companion profile, independent portable contract/CID validation plus adversarial retry, SSRF, receipt, lock, and failure-transition vectors;
19. independent validation of every JSON Schema keyword used by the public Plan Document, Plan Result, and Run State protocols, including their conditional unions, nested closed objects, canonical identities, and cross-artifact bindings;
20. independent acquisition and restoration of a fixed reference identity set, verifying consistent equality, join, distinct, grouping, uniqueness, and canonical identity ordering. Vectors cover reference-only and mixed candidate keys with unorderable payloads, reordered and empty inputs, primitive ranking with reference tie completion, admitted reference partition/correlation keys, and source-print/recheck preservation without authored reference orders. Negative vectors cover explicit reference orders and tie-breaks, ordered comparisons including BETWEEN/NOT BETWEEN, and min/max including pivot; text/tree predicates agree, deferred order-domain checks reject references before ordering, and opaque-field access remains rejected;
21. SourceView resolution and observation vectors: sole-view completion with journal evidence; zero-view rejection; multiple-view rejection with candidates; exact selector matching even with a pinned contract CID; rejection of unregistered extraction contracts and contracts requiring implicit model invocation before provider access; and Catalog, Plan, and acquisition-review presentation of classification and contract identities; and
22. expression-text vectors for every spelling, signature, precedence level, and exclusion in Expression text: independent decoding to the same structured trees; equal Program identities across text/tree forms; canonical printer round trips including structured fallback; Unicode diagnostic spans; unchanged literal/metadata/request strings; and rejection of computations in restricted Effect positions. Vectors include decimal/binary64 separation, literal-NULL comparison rejection, and grammar/lock drift;
23. source-decoding vectors for scalar resolution, normalized-key collisions, Unicode and line endings, numeric limits, and source versus artifact admission;
24. type/evidence vectors for recursive compatibility, nullable parent paths, and canonical key selection independent of proof enumeration order; and
25. lifecycle vectors for preparation versus Run Checkpoints, typed dispatch outcomes, strength-specific review rows, and acyclic receipt dependencies;
26. nest vectors: empty inputs and typed empties versus all-null children; duplicate parent correlations and legal child multiplicity; reference-key completion and authored-order rejection; independent sibling arrays; guard/byte/depth/overflow failure before consumers; preserved upstream failures, completeness and policy; and independent lowering/value/CID checks;
27. Discovery vectors: fixed snapshot pagination, scope and cursor isolation, exact versus projected identity, closure/issuer admission, partial-list ambiguity, current disclosure authority, and no provider observation; and
28. read collection vectors: exact slot/Result evidence, required/all-source failure, closed permitted classes, retained attempt costs, coverage admission, canonical ordering, no fabricated artifacts, and replay without dispatch.

Additional Operations conformanceCopy Anchor Link

The expanded RelA claim includes values, set multiplicities, bounded cross join, analytics, added aggregates, offset and outer unnest. SGA includes subgraph, equality, typed Delta application, means and extended paths; VecA includes row-local vector expressions and RRF; TEA includes carrier-preserving session, finite series and interval joins. Separate lexical, external-search and calendar claims cover their complete Language definitions.

Each claimed operation MUST have independent source/checked-type/canonical-node and success/rejection/failure vectors, including empty inputs and resource breaches. Golden values are derived from the normative law rather than copied from one runtime. Comparison covers complete output contracts, semantic IDs, ordered outputs, root/demand and limit bindings, policy and completeness, not merely matching row payloads. Existing kernel tests, parser acceptance, aggregate test counts and rehashed-fragment self-CIDs do not substitute for these vectors.

Required cases are:

• RelA: typed empty values; literal data resembling expression tags; set NULL equality and ALL multiplicities; input permutations and row order; zero/ singleton/general cross products and overflow; analytic peers versus identity tie-break; empty/truncated ROWS frames; own aggregate filters and different orders; conditional argument failures; offset past end; outer synthetic rows versus actual null elements; statistical insufficient samples and rounding.
• SGA: empty and edge-filtered induced graphs; exact equality versus identity relabeling; invalid graph rejection; diff/apply roundtrip; wrong base, missing targets and dangling edges; mean support boundaries, zero weights, absent entities versus null properties, unequal sampling and non-associative means; source/target selection modes, zero-cost ties and hop-constrained paths.
• VecA/search: composed vector functions, null demand and dimension overflow; RRF rank-window versus output-k, input duplicates, score-scale independence and canonical numerical folds; lexical tokenizer/normalization fixtures, empty corpora, df/document-length changes and correctly rounded ln; search zero-hit coverage, partial/exact orthogonality, replay without new requests, request egress rejection and failure without fabricated zero rows.
• TEA/calendar: preserved event identity after session labeling; explicit session partition use; finite empty grids without absence claims; touching intervals, invalid endpoints and multiplicity limits; DST gaps/folds, skipped dates, leap years, week/year boundaries and pinned TZDB changes.

No complete expanded-profile claim exists until its machine registry, schema, law and runtime evidence agree. Partial implementation remains reportable without changing the adopted source semantics or rewriting old attestations.

Conformance reports MUST state Core support, the required RelA claim or its gaps, every claimed normative optional module, optional connectors, and Effect application capabilities. Profile claims follow Conformance profiles; an AoA registry entry alone is not evidence of support. All conforming Core compilers MUST check all six Effect declarations; Host application remains a separately declared capability. Reports MUST also include ACTQL_DIAGNOSTIC_SEMANTIC_PROFILE_CID and ACTQL_AOA_CONTRACT_CID. Reports claiming exact diagnostic catalog compatibility additionally include ACTQL_DIAGNOSTIC_CATALOG_CID.

Agent-usability holdouts are not language conformance, but a frozen evaluation SHOULD separately report first-check validity and one-repair convergence. It SHOULD record the initial and aggregate diagnostic-code distributions together with the diagnostic catalog CID, so a repair-rate change cannot be attributed to an unidentified diagnostic surface.

VersioningCopy Anchor Link

The grammar, diagnostic, portability, and protocol contract bodies MUST agree with the normative definitions. A release's conformance manifest MUST bind their exact recomputed identities. Release evidence is immutable and attests only the exact artifacts it identifies.

actql/0.1 source, Program semantics, ordering, identity, and authority laws are immutable once released as Final. Each runtime and CLI artifact protocol is separately versioned and MUST reject unknown versions. The machine-readable compatibility policy is actql-version-policy/0.1, exported as ACTQL_VERSION_POLICY_CID; mutable release pointers live separately in release/actql-release-index.json.

The source parser MUST reject an absent or unsupported version before lowering; Structural grammar (normative) defines the admitted source version. Unknown document, input, operation, parameter, result, and effect fields MUST fail closed. ActQL 0.1 has no extension namespace, deprecated operation aliases, or alternate compatibility mode in the canonical Program model. An explicitly registered frontend can provide a different representation of that same model. An implementation accepts only its installed profiles and their closed syntax; it does not infer support from a backend language or retry another frontend after a parse or type error.

An implementation patch MAY fix execution or rejection of source whose status was already determined by the frozen specification, reject source that was invalid under that specification, optimize without changing observable semantics or identities, and improve non-normative prose. A patch MUST NOT accept a new source spelling, alias, field, default, or completion; change AoA lowering or observable semantics of a valid program; or change a frozen grammar, diagnostic, artifact, module, law, or contract CID in place. A source-language change requires a new ActQL language version and conformance corpus. An incompatible machine-artifact or CLI change requires a new artifact protocol version and package major revision, while preserving all earlier frozen evidence.

The adopted Frontend r1 work is an explicit initial-0.1 specification decision, not permission for implementation patches to invent further syntax or bump versions. Its profile names separate frontend surfaces from Program semantics. Actual grammar changes are accompanied by the applicable manifest, pins and conformance corpus; their evidence is not inherited from JSON/YAML decoding.

A runtime MUST reject unsupported ActQL, AoA IR, Connector SPI, and artifact versions. Authoring tooling MUST bind the compiler's exact Grammar Manifest CID, not merely a semver range. AoA execution MUST bind the exact frozen AoA contract CID.

Migration is an explicit source transformation, not a parser compatibility mode. A migration MUST refuse a transformation whose target, authority, or typed Command Contract requires an unresolved semantic choice. It MUST produce new source and an edit journal rather than reinterpret a stored Program in place. Tool-specific migration syntax is outside this specification.

Core, RelA, SGA, VecA, and TEA publish independent module contract CIDs and maturity status. A distribution may claim only a subset, but a semantic change inside any Final 0.1 module requires a new module and ActQL language version; an implementation cannot relabel partial operation coverage as that module.

Artifact and companion contract index (normative)Copy Anchor Link

The following documents supply machine-readable definitions by reference. Their released identities are bound by the conformance manifest (Versioning). Exported constant names below identify those contracts; importing a particular implementation package is not a conformance requirement.

Normative prose and machine contracts describe the same design. A disagreement is a specification defect, not permission for an implementation to choose whichever definition it prefers (Versioning).

Core publishes versioned canonical schemas and individual schema CIDs for:

actql-parameter-values/0.1
actql-bound-invocation-template/0.1
actql-source-evidence/0.1
actql-normalization-journal/0.1
actql-result-artifact/0.1
actql-effect-preview/0.1
actql-review-projection/0.1
actql-authoring-context/0.1
actql-approval-attestation/0.1
actql-effect-apply-receipt/0.1
actql-effect-set-apply-receipt/0.1
actql-effect-reconciliation-receipt/0.1
actql-result-manifest/0.1
actql-result-delivery-receipt/0.1
actql-result-definition/0.1
actql-run-invocation/0.1
actql-result-retention-policy/0.1
actql-durable-result-binding/0.1
actql-publication-request/0.1
actql-publication-attempt/0.1
actql-publication-record/0.1
actql-manifest-read-grant/0.1
actql-result-read-grant/0.1
actql-delivery-attempt/0.1
actql-delivery-record/0.1
actql-public-index-entry/0.1
actql-run-receipt/0.1
actql-plan-result/0.1
actql-plan-document/0.1
actql-run-state/0.1
actql-run-definition/0.1
actql-prepared-invocation/0.1
actql-run-policy/0.1
actql-run-authorization/0.1
actql-execution-checkpoint/0.1
actql-checkpoint-resolution/0.1
actql-runtime-error/0.1

The normative envelopes are published as ACTQL_ARTIFACT_SCHEMAS and ACTQL_ARTIFACT_SCHEMA_CIDS. The Connector/opaque-value protocol envelopes are published as ACTQL_PROTOCOL_SCHEMAS and ACTQL_PROTOCOL_SCHEMA_CIDS, and the aggregate schema identity is ACTQL_PROTOCOL_SCHEMA_CID.