Skip to content

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

@consiliency/contract

The Consiliency cross-repo contract package — the single, neutral rulebook that agent-harness and governed-pipeline vendor (owned by neither). It defines:

  • the .consiliency/ layout + manifest schema
  • the archetype registry — product / service / library / infra / tooling-meta / experiment / document, plus modifiers (data-bearing / public / regulated / user-facing), with baseline-only as a legal declaration
  • the required-document sets per archetype (the 7 document classes)
  • the interface-declaration schema (realized + promised cross-repo edges)
  • the loop-gate protocol (presence / freshness / integrity / version-skew)
  • the canonical_html.v1 display schema
  • the version-skew protocol
  • adoption + governance-scoping (CS-0.12) — the adoption profile (a partial-adoption profile, not a boolean; its presence = consent to be governed), the governed-set allowlist-by-declaration, the default ignore-set registry, and the present-nonconforming / foreign / unmanaged governance labels
  • lease + inbox coordination (CS-0.10b) — the lease (TTL + heartbeat + auto-expiry, soft/hard, repo/path-set/symbol scope), the append-only lease_event stream, the lease_store protocol (sole source of truth) and the coordination_channel inbox protocol (never authoritative)
  • projection discovery + git-discipline (Slice C0) — the projections.index.v1 schema (a deterministic pure-merge index of per-artifact projection manifests, no generated_at, so every driver reproduces byte-identical entries), the git_discipline_protocol (pipeline-owned ref classes, lease + write-footprint, merge policy, and the NEVER-DELETE-HUMAN-REFS invariant as a schema-level rule), and the pipeline_ref_classes registry both runtimes read to agree on ref ownership
  • interchangeability conformance (Slice X) — scripts/interchangeability/run_driver_equivalence.py proves the pure-merge claim above isn't just asserted by this package's own reference mergers: it feeds the projections-index-pure-merge-deterministic vector through the real spec-render/build_projections_index.py producer and asserts byte-identical output, honestly scoped (see scripts/interchangeability/README.md)
  • authority-event contract core (XG-1 Slice 1) — the single, cryptographically-authenticated authority_event_protocol.v1 schema with the core/chain signing split (Portal signs the slot-independent core; spec appends chain OUTSIDE the signature and never re-signs), one canonical-bytes algorithm implementable in dependency-free JS on Node 20 (see docs/design/authority-event-canonical-bytes.md), the vendored digest-pinned authority_key_registry.v1 Ed25519 root of trust (public keys only), an Ed25519 verify reference in both readers, and 13 conformance vectors — a valid event VERIFIES in both readers and every forgery class (bad/missing signature, unknown/attacker key_id, algorithm-confusion, signer↔approver mismatch, revoked/expired key, cert_digest mismatch) REJECTS
  • the certified label rescope (CS-1.4, XG-1 Slice 5) — splits the single certified evidence label into parity-certified (byte-reproducible parity cert, no authority event — what CS proj-S certification ships today) and authority-certified (parity PLUS a verified, human-ratified authority event — reserved until the XG-1 authority loop lands end-to-end); certified survives only as a deprecated alias of parity-certified, never authority-certified, so existing producers/consumers keep validating (see docs/design/CS-1.4-certified-label-rescope.md)
  • supervised-run status + admitted-launch envelope (provisional) — a neutral (harness- and language-neutral) contract that harnesses consume later: admitted_launch_envelope.v1 (what a harness receives after admission, its fixed enforcement tiers and the refusals that happen before any process starts) and supervised_run_status.v1 (the per-attempt append-only run journal, its derived projection, bounded pages and the reader view, which keeps runtime state apart from work outcome and evidence). Both schemas and their golden control/negative conformance vectors live in core/supervised-run/, shipped byte-for-byte and digest-pinned in core/supervised-run/provenance.json; conformance/SHA256SUMS there is the contract's own manifest. See core/supervised-run/conformance/README.md for how to read a vector
  • admitted-launch envelope v2 (provisional) — admitted_launch_envelope.v2, published alongside the frozen v1 (every v1 byte unchanged). It keeps every v1 field and adds a required, closed launch block that binds, by digest or logical locator, every input that determines the launch: instruction and ordered reference bytes from the workspace, a declared root or a descriptor; the argument vector of the outermost spawn (SHA-256 of its UTF-8 RFC 8785 array); the ordered wrapper-and-executable chain; the captured source tree (including overlays), the worker cwd and the target map; a credential-safe environment commitment (non-secret values plus secret names, never secret values); the trusted configuration, template and qualification digests; action, route and stdin delivery; the stopping policy (timeout_seconds, 1–3600); and optional grants, each with an explicit canonical form. Every launch-side commitment must agree with the captured material it describes. Admission needs exactly one validator-held qualification record for the route, and unqualified means refused. Interactive terminal delivery is out of scope. Conformance covers admission (including exact schema-error sets), RFC 8785 and source-tree capture, and the write_scope apply check with its runtime journals; see core/supervised-run/conformance/README.v2.md

Dual-published: npm @consiliency/contract + PyPI consiliency-contract, from shared JSON data + conformance vectors so the two language readers stay byte-identical.

Status — 0.7.0 adds the provisional admitted_launch_envelope.v2 (core/supervised-run/admitted-launch-envelope.v2.schema.json, with conformance/envelope.v2.vectors.json and conformance/README.v2.md) next to the frozen v1: no v1 schema, vector or README byte changes, and the v1 manifest stays verbatim as the first five lines of conformance/SHA256SUMS. v2 binds every launch-determining input in a required launch block, keeps secret values out of every commitment, and states that a tier describes semantics, not installed-tool qualification. Minor bump: the version-skew compatibility window moves to >=0.7.0 <0.8.0. v2 consumers reconcile at adoption. 0.6.6 distributes the provisional supervised-run status and admitted-launch-envelope contract (admitted_launch_envelope.v1, supervised_run_status.v1) with its conformance vectors under core/supervised-run/, verbatim and digest-pinned, for harnesses to consume later. Additive only: no existing schema semantics change. Consumers were reconciled for the one provisional rule added before relocation (attempt_evidence_copied: a later attempt never repeats an earlier attempt's evidence-envelope digest). Any further change to this provisional contract needs reconciliation with every consumer. 0.6.5 defines the canonical protected_source_category vocabulary (the protocol's first producer↔consumer conformance boundary) as a two-level scheme: a required coarse category (seven execution-flow buckets — the pre-existing six plus a new governance_contracts bucket for producer-side governance sources) plus an optional free-form subtype carrying the producer's fine granularity. The protected_source_categories registry pins the coarse enum, the registered fine set, and the canonical fine→coarse map for all ~14 governed-pipeline fine categories; the protected_source_category schema validates a {category, subtype} descriptor. SoT definition only — additive, no existing schema semantics change; governed-pipeline and phase-loop conform in later phases. 0.6.4 distributes the frozen parity certificate schema and its result-state $ref closure (verbatim from spec, digest-pinned in core/spec-parity/provenance.json) so external consumers (e.g. greenfield XG-6) validate against the real parity-cert schema instead of a hand-rolled, repo-owned proof cert — additive only, no existing schema semantics change. 0.6.0 splits the certified evidence label into parity-certified (byte-parity cert, no authority event — what CS proj-S certification ships today) and authority-certified (parity PLUS a verified, human-ratified authority event — reserved until the XG-1 authority loop lands end-to-end), keeping certified as a deprecated alias of parity-certified only, so existing producers/consumers keep validating (CS-1.4, XG-1 Slice 5; see docs/design/CS-1.4-certified-label-rescope.md). 0.5.1 pins the authority canonical-bytes to spec canon-core v2 (canonical_bytes, not a 4th canon — proven byte-identical + digest-pinned in core/authority-canon/provenance.json) and applies the settled XG-4 domain-separation decision: the Ed25519 signature covers the authority-profile digest preimage spec-canon:v2:authority\n ‖ canonical_bytes(core), converging to zero re-signing when canon-core adds the profile. 0.5.0 added the XG-1 Slice 1 authority-event contract core: the authority_event_protocol.v1 schema (core/chain signing split), the authority_key_registry.v1 Ed25519 root of trust, the canonical-bytes interop algorithm + Ed25519 verify reference in both readers, and 13 forgery conformance vectors. 0.4.2 makes the projections.index.v1 per-kind maturity caps two-sided: proj-code is [presence-only, hash-checked] and proj-S-certified is [realized-edge-observed, certified] (floor-revert), replacing the one-sided not:certified guard. 0.4.1 made the entry per-kind (proj-code pins a code commit + facts; proj-S-certified requires source_S_digest, no facts/commit). 0.4.0 added the Slice C0 projection-discovery + git-discipline contracts (projections.index.v1, git_discipline_protocol, pipeline_ref_classes) on top of the 0.3.0 required-document rebalance, the 0.2.0 CS-0.12 adoption/governance-scoping + CS-0.10b lease/inbox coordination, and the 0.1.0 Phase-0 L0 content. The shared JSON data lives under core/ and conformance/; npm and PyPI readers are intentionally thin loaders over those same bytes.

Reader API

JavaScript:

import {
  CONTRACT,
  CONTRACT_VERSION,
  listVectors,
  loadContract,
  loadRegistry,
  loadSchema,
  loadVector,
  // authority-event core (XG-1 Slice 1)
  canonicalCoreBytes,
  verifyAuthorityEvent,
} from "@consiliency/contract";

Python:

from consiliency_contract import (
    CONTRACT,
    CONTRACT_VERSION,
    list_vectors,
    load_contract,
    load_registry,
    load_schema,
    load_vector,
)
# authority-event core (XG-1 Slice 1); needs the optional `authority` extra
# (cryptography) only for signature verification.
from consiliency_contract.authority import (
    canonical_core_bytes,
    verify_authority_event,
)

Verification

npm test
python -m unittest discover -s tests -p 'test_*.py'
python -m build

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages