Judgment Pack Specification v0.3.0-rc.2

v0.3.0-rc.2

This second Core release candidate adds exactly selected retained-column/1 support accepted
at draft maturity through RFC0029. Acceptance and
a draft GitHub release are separate from immutable publication: publication requires the exact
tag, maintainer-published GitHub release and verified artifacts. Core packs declare specVersion 0.3.0, while the
selected leaf names exact distribution version 0.3.0-rc.2, source revision and schema/corpus pins.
This is no final Core, stable interoperability or general preparation-verifier conformance claim.

The accepted design's scope is selected retained columns.
Its closed inventory binds new schema, complete shared corpus,
prose and offline owners; release-identity.json supplies the exact commit without self-reference.
The release build must include those bytes in both archives, checksums and provenance. The existing 47 historical
Dialect recordings remain staged and are not published by this leaf corpus.

Readers refuse unknown exact pins/roles before artifact admission. Writers emit new leaves only
for supported selections. Ordinary documents, absence of optional members, old carrier/preparation
versions, all five conversions/eight original types and retained provenance keep their contracts.
Changed raw rules/frames/inventories require fresh commitments and the existing review/CAS gates.
There is no automatic rewrite of old publications, recipes, receipts or subscriptions.

Published v0.3.0-rc.1, its source/tag/assets/mapping/notes and preserved public schema resources
remain immutable. RC2 retains final v0.3.0 milestone #2. The maintainer records reasonable public
feedback and the treatment of RC2 changes before final Core publication; these notes establish no
completed final Core adopter period or final release gate. Final exact-version conformance still requires the
final published corpus. Same-vendor review under the authorized exception is identified accurately.
The corrected maximum-envelope ledger and its source/history premises are recorded on the
adoption disposition;
the original proof table is superseded. That record closes C1 and dispositions the pre-adoption
RFC comments at draft maturity without claiming outside-adopter feedback. The final Core adopter
period and feedback gates remain required. Real producer/history support, production Desk cutover and exact-head
product/release verification are not inferred from these draft artifacts or synthetic fixtures.
Acceptance does not complete Agent #171.

Judgment Pack Specification v0.3.0-rc.1

v0.3.0-rc.1

This is the single release candidate for Core 0.3.0, distributed under tag
v0.3.0-rc.1 as a GitHub pre-release. Preparation and a draft GitHub release do not publish it.
Once published, it gives adopters about one week to check the renamed manifest maturity status
before the final v0.3.0 release. The final release has not been established by this candidate.

Scope and identity

The proposed format remains exact specVersion 0.3.0, and both corpus manifests name
suiteVersion 0.3.0; packs do not declare 0.3.0-rc.1. Both manifests remain maturity draft,
not the independent-evidence maturity candidate or the 1.0.0 standards maturity release.
Each bundle includes the closed distribution-to-format map and a generated release-identity.json
with this exact RC tag and resolved source commit. Archive checksums and build provenance cover
those bytes. The map creates no compatibility rule for other prereleases.

Included work and reader/writer/semantic migration guidance are described in the prepared
0.3.0 notes. In particular, the historical 0.2.0-draft identifier
and frozen schemas keep their names; readers compare full version selectors. There is no automatic
migration promise or compatibility guarantee for this pre-1.0 draft. The independent Policy
companion keeps its own release route and is excluded from the Core schema/corpus bundle paths.

Adopter checks and claim limits

Check that tooling reads the manifest status value draft in place of the retired
research-preview, independently from the exact specVersion, and preserves/refuses versions
according to its declared reader support. Runtime vendoring must retain historical releases and
record this candidate's exact source identity rather than label it a published final release.
Report incompatible readers, schema/corpus disagreements and migration problems before final
publication; the maintainer reviews that feedback after about one week of public RC availability.

Results against this candidate name its tag and commit and remain provisional. This candidate does
not establish a final 0.3.0 conformance claim or standards maturity. Conformance never proves
truth, authorization, safety or operational fitness.

The accepted Dialect companion prose is included, but conformance/dialect/ vectors remain staged,
export-ignored and absent from the bundles. No preparation-verifier conformance claim becomes
available through this RC. Staged witness and future evaluation rows likewise remain excluded.
This says nothing by itself about a product's separate tool-certification evidence; downstream
claims need their own exact checks and disposition.

Recovery provenance

The signed RC tag and artifact source remain 495535f29a517dc6a36075b77238634011e7371e (annotated tag object c0ddd58e507ce42891947929acb1ad0330faa038). The recovery workflow run used workflow commit dc8825c41b1f834fce63b798a92ef4a115d5bfb6 to check and package that unchanged source. The attestations identify that actual workflow commit, rather than claiming the old tag supplied the recovery workflow.

The attached recovery-evidence.json records both identities, the genuine workflow run, actual toolchains and hashes of the validation logs and artifacts. The original source passed all seven required checks (463 tests), without skipped checks. Both archives contain the same 217 original-source files plus their release identity. Checksums and all three attestations were independently verified before publication.

Recovery and the draft-absence correction are recorded in PR #262, PR #263 and issue #261. The guard correction does not replace these assets or change their provenance.

Judgment Pack Specification policy-v1.0.0-draft.1

Policy companion 1.0.0-draft.1

This describes the first independently versioned Policy release at draft
maturity, using exact document format 1.0.0, Core consumers 0.2.0-draft,
versioned closed schemas and the complete 124-row Policy offline-reader corpus.
The maintainer approved the bounded draft after CI, effective only upon required
green CI and PR 218 merge. The default-branch RFC remains Review until that merge;
this source document alone establishes no immutable publication or conformance
claim. Publication requires the exact policy-v1.0.0-draft.1 tag and a
maintainer-published GitHub release. Maturity remains draft; a conformance claim
also requires the complete published corpus and the companion class requirements.

The format retains exact content/narrative/source/interpretation/consumer bytes,
UTF-8 section anchors, optional existing jps-canon identity, independent strict
artifact versions, role/aggregate bounds and pack-only total scoped coverage.
The JSON release manifest pins exact schemas, format prose and corpus bytes.
The shared release builder refuses publication preparation until draft acceptance
and exact tag/commit/HEAD/clean-tree checks pass. Archive checksums and GitHub
build-provenance attestations use the existing release workflow.

• Reader compatibility: the prototype 0.0.2 wrapper is refused. The corrected
  proposed 1.0.0 input grammar is preserved, but official schema resource IDs and
  valid-result/capability maturity differ. Unsupported formats refuse exactly.
• Writer compatibility: no existing Policy/adoption bytes require rewriting.
  Newly written documents must use exact formatVersion: "1.0.0"; artifact
  version arithmetic or a citation cannot select grammar or create adoption.
• Semantic compatibility: input content/reference/anchor/coverage meaning is
  unchanged from the corrected proposal. The reader result now reports draft
  instead of proposed-draft; clients comparing complete objects must update
  deliberately. No Core evaluator, schema, corpus, Pack execution pin or Dialect
  semantics changes. The earlier candidate/prototype remain archived unchanged.
• Migration compatibility: prototype migration requires explicit intent, new
  immutable Policy/adoption identities, preserved retained bytes and dependent
  snapshot re-review. No approval, permission, role, signature or lifecycle state
  migrates. See the bundled promotion map and migration guide.

Scope excludes Graph consumers/closure, correct natural-language interpretation,
complete organizational policy discovery, authenticated review/signature trust,
provider lifecycle/freshness, currency, current authority and dispatch permission.
No production governance or stable-readiness claim follows. Existing experimental
software pinned to older Spec bytes retains its exact old capability/meaning;
this publication does not upgrade its pin or adopt it on its behalf.

The reference Python reader and Runtime port are Codex-assisted work by this
project, not genuinely independently authored implementations. The maintainer
accepted the limited public review period for this bounded draft and applied the
standing temporary different-vendor-review exception without changing the general
governance rule. The separate OpenAI gpt-6.1-sol/xhigh review reported no
material findings on tree 60b04d452efa49032a0cc7d3ac1e55a3900410a8, committed
unchanged as 7f118278e480d88e53e6a6be2fe084610a2bebf9; its complete record is on
PR 218.
The final CI-fix/acceptance delta requires its own bounded review and required
CI before merge. The conditional disposition
records scope, public-process limits, deferred questions and reopening conditions.
No outside stakeholder review, independent interoperability or publication is
inferred from these records.

Deal evidence readiness v0.2.0 — synthetic demo

A synthetic worked example for Revenue Operations and the Deal Desk: determine which evidence is holding a deal back before an accountable owner reviews it.

Read the walkthrough.

Downloads

• deal-evidence-readiness-v0.2.0.zip — a self-contained project with the pack, 40 project-owned test cases, 13 synthetic source scenarios, Runner mapping, sample inputs, one-page brief, and pilot plan/worksheet.
• deal-evidence-readiness-v0.2.0-one-page.pdf — the shareable business brief.
• checksums.txt — SHA-256 checksums for both downloads. The ZIP also contains per-file SHA256SUMS.

The assets are byte-for-byte identical to the v0.2.0 materials published on the JPS website. No Desk state, job/run records, credentials, customer data, or private meeting notes are included.

Run it

Use Runtime v0.23.1. Verify and extract the ZIP, enter deal-evidence-readiness-v0.2.0, then run:

jpack packs validate --config jpack.json
jpack packs test --config jpack.json

The pack validates and all 40 cases pass: 27 policy cases and 13 using captured Runner projections. The matrix evaluates the supplied inputs; it does not re-fetch sources or re-run the source mapping. The included coverage review explains the remaining advisory conflict probe.

Release scope and verification

This is a non-normative demo prerelease, not a new JPS specification release. Pack version 0.2.0 declares JPS Core 0.2.0-draft. Project configuration, matrices, mapping, scheduling, and briefs remain companion-tool conventions.

• Tag: demo/deal-evidence-readiness/v0.2.0
• Source commit: 14e96c29f6eff5b0197ffc75e61b54f87be5f7b1
• Changes: #90 and #91
• All 82 repository/site checks passed on the released source; production deployment succeeded.
• Assets were rebuilt from a clean checkout of the tagged commit and compared with the live website. Every bundled file digest was checked.
• Checksums provide integrity checks; no GitHub build-provenance attestation is supplied for these demo release assets.

GitHub's automatic source archives are repository snapshots at the demo tag. For the portable example, use the named demo ZIP above. The normative JPS release remains v0.2.0-draft.

Boundaries

All records, entities, amounts, and thresholds are fictional. This is not OpenText policy or a live OpenText/Salesforce integration. Evidence-ready means ready for accountable review, not authorization to sign. Asserted records do not establish authenticity, currentness, approver authority, or freshness by age. Viewing or testing the downloaded example creates no live jobs and sends no external actions.

Judgment Pack Specification v0.2.0-draft

Judgment Pack Specification 0.2.0-draft

This release publishes the second research preview of the Judgment Pack Specification (JPS) under
the immutable tag v0.2.0-draft.

It is intended for design review, synthetic pack authoring, carrier, structural, and semantic
conformance experiments, and — new in this release — evaluator conformance work. It is not an
industry standard, carries no compatibility guarantee, and must not be represented as sufficient for
consequential production decisions.

Scope of the change

0.2.0-draft is the first normative change to Core since the specification was seeded. It adds one
conformance class and changes no part of the document format.

• Evaluator conformance (§3.4). An implementation that, given a conformant pack, a facts
  document, an evidence-availability document, and its own supported-extension set, produces the
  portable disposition of §8.3 under the semantics of §§7–8, reports evaluation errors per §8.4,
  defines the §10 limits, and passes the evaluation corpus for the exact specVersion it names.
• §3.4.1 permits exactly one form of claim — against the class and the corpus, for one exact
  specVersion, with the results stated and with the claim itself saying that every row of the named
  corpus version passed. The claim's scope is the whole §§7–10 contract for every input the
  implementation admits; corpus results are required evidence of that and are not the boundary of it.
  A failed row blocks the claim unless a project-issued, versioned erratum
  (conformance/evaluation/errata.md) marks that row defective for that corpus version, in which case
  the claim must name the row and cite the erratum. A claimant does not get to call a row defective on
  its own authority. Partial claims, claims from prototyping, and claims without corpus results remain
  forbidden, as does any claim under 0.1.0-draft.
• §§7–8 are now normative for that class and informative for everyone else. §7.5's undefined
  "complete evidence manifest" is replaced by the §8.2 tri-state; §8 step 2 is restated in
  three-valued terms; §7.4 defines ordered comparison of decimal strings, excludes units and date/time
  explicitly, requires every operator of an implementation claiming the class, and states that equality
  of decimal strings is string equality and deliberately not decimal-aware.
• The portable disposition (§8.3) — kind, outcomeId iff kind is outcome, reasons as a
  sorted set, and a handoff object carrying state and, when requested, triggeredBy. It does not
  echo the escalation target. Two conforming implementations must produce byte-identical dispositions
  after canonicalization, with exactly one stated seam: equality involving a JSON number an
  implementation cannot represent exactly, which §13 leaves open and §8.3 names.
• Input preflight (§8.2). The inputs are admitted before §8 runs: pack, then facts, then evidence
  availability, with an omitted evidence document meaning the implicit empty object. Any violation of
  §8.2's shape — a non-object evidence input, an undeclared key, a value outside the tri-state — is
  malformed-input. Because preflight completes before step 1, an input error can never be outraced by
  a not-applicable result.
• The error contract (§8.4). An evaluation error is not a disposition: it terminates evaluation
  wherever §8 had reached and yields no result. Every error carries exactly one class — one of the four
  Core classes pack-not-conformant, malformed-input, unsupported-required-extension,
  resource-exhaustion, reported in that fixed precedence order where more than one applies, or a
  documented implementation-defined class for a condition no Core class covers, which uses §9's
  reverse-domain form and never displaces a Core class that applies.
• §10 uplift, split by phase. For implementations claiming the evaluator class, defining
  collection-size and evaluation-work limits is a MUST, and reaching one during evaluation is
  resource-exhaustion rather than a result. A document or carrier limit reached while admitting an
  input is malformed-input instead: §2.1 refuses that document, so preflight never admits it. Either
  way the outcome is an explicit error.

Document conformance is untouched. Nothing above changes whether a document is carrier, structurally,
or semantically conforming.

Included

• Core prose at 0.2.0-draft and a JSON Schema Draft 2020-12 structural schema pinned to it.
• The 0.1.0-draft schemas, preserved for packs and manifests that keep the older value and served at
  the $id each was published under: the Core structural schema at
  schema/judgment-pack-core-0.1.0-draft.schema.json and the document-conformance manifest schema at
  schema/conformance-manifest-0.1.0-draft.schema.json. See the preservation note below for exactly what
  "preserved" means here.
• Five synthetic examples, re-declared at 0.2.0-draft.
• The 47-case carrier, structural, semantic, and capability corpus, re-pinned to 0.2.0-draft.
• A new 20-case seed evaluation corpus in conformance/evaluation/, with its case carrier and four
  pack fixtures: thirteen rows imported from the cross-implementation exercise (ten over the nine
  walked RFC 0006 appendix instances, counting both variants of instance 7, plus three probes) and
  seven constructed here from the specification text.
• A short external-user testing exercise and feedback template.
• Automated repository integrity, corpus, and evaluation-carrier checks.
• Versioned .tar.gz and .zip artifact bundles, SHA-256 checksums, and GitHub build-provenance
  attestations.

What "preserved" means for the 0.1.0-draft schemas

Each preserved file matches the schema published at the immutable v0.1.0-draft tag in every byte
except its $id member. That member was re-pointed to the project's neutral domain when the retired
pre-publication identifier was withdrawn, so that the identifier a 0.1.0-draft document resolves today
is one this project controls and keeps serving. Nothing else was edited: no keyword, no constraint, no
specVersion constant. The tagged v0.1.0-draft release remains the authoritative record of its own
bytes; this release preserves a schema for continued use, and does not restate the tag.

Both forms are published here so the difference is checkable rather than asserted:

Artifact	Form	SHA-256
Core structural schema	at the v0.1.0-draft tag	81f6986edc8d2bbf6f49c28a9bbec4f9054f7c72cab5a5028130e01d2e7274d8
Core structural schema	preserved here (schema/judgment-pack-core-0.1.0-draft.schema.json)	c65c559db33d19d2f327858635266fca7fcc049fb75083a7a8d47517e27224fc
Document-conformance manifest schema	at the v0.1.0-draft tag	fa3f55f53712253551d6374ff3f06621e936b56c04dabd399703bbb05285c740
Document-conformance manifest schema	preserved here (schema/conformance-manifest-0.1.0-draft.schema.json)	f073bde8f6f2189edd0334c81c03fecfacf8fae2bd49305a788c75550dcbc2c5

Compatibility

• Reader: a 0.1.0-draft reader rejects a 0.2.0-draft document, on the exact specVersion
  value and on nothing else. No member was added, removed, or redefined, so such a reader can parse
  and preserve everything else in the document once it gets past that value.
• Writer: a 0.2.0-draft writer's output is rejected by a 0.1.0-draft reader, for that same one
  reason. Both directions are negative; the exact-version rule is deliberate (§11) and the format
  being unchanged does not soften it.
• Migration: specVersion is exact, so a 0.1.0-draft pack must be re-declared as
  0.2.0-draft — that one value, no other edit — to be structurally conforming here. A pack that
  keeps the older value stays valid against the preserved 0.1.0-draft schema. The pack is unchanged in
  representation and in document-conformance meaning; re-declaring it is not semantically inert, because
  it opts the pack into this draft's evaluator semantics, which existed for no consumer under
  0.1.0-draft, and it confers no conformance on any implementation.
• Semantic: results that were informative in 0.1.0-draft are normative for the evaluator class,
  which is a new obligation for evaluators and none at all for validators. Two 0.1.0-draft
  evaluators could legitimately disagree on the same inputs; two 0.2.0-draft evaluator-conforming
  implementations must not.
• Claims: an evaluator-conformance claim attaches to one exact specVersion and to the corpus
  published with it. Nothing is inherited, and no claim is acquired by re-declaring a pack.
• This is a 0.x release. The next one may be incompatible again.

The independence caveat

The evidence behind this change is two implementations and a 13/13 agreement corpus. Both
implementations trace to one maintainer's direction. The second was written clean-room, inside an
information barrier, by a different model family, but from reference texts the same maintainer chose,
including RFC 0006's own implementation-experience notes. Their agreement corroborates the
semantics; it does not independently confirm them.

Acceptance of RFC 0006 is design approval at draft maturity.
It is not a stability claim. The RFC 0000 bar for a stable normative feature — two independent
implementations — is not met, and it is re-tested at stabilization rather than treated as satisfied.
The project also has one maintainer and no independent contributors; see the interim review regime in
GOVERNANCE.md.

Limitations

• No implementation ships an evaluator-conformance claim with this release. The reference runtime's
  evaluator remains experimental and claims nothing; whether it claims the class is a runtime
  decision, made in that repository, not here.
• The evaluation corpus is a seed: four packs, twenty rows, no error rows, no rule-ord...

Judgment Pack Specification v0.1.0-draft

Judgment Pack Specification 0.1.0-draft

This release publishes the first research preview of the Judgment Pack Specification (JPS) under
the immutable tag v0.1.0-draft.

It is intended for design review, synthetic pack authoring, and carrier, structural, and semantic
conformance experiments. It is not an industry standard, carries no compatibility guarantee, and
must not be represented as sufficient for consequential production decisions.

Included

• Core prose and a JSON Schema Draft 2020-12 structural schema.
• Three unrelated synthetic examples.
• A versioned 47-case carrier, structural, semantic, and capability corpus.
• A short external-user testing exercise and feedback template.
• Automated repository integrity and corpus checks.
• Versioned .tar.gz and .zip artifact bundles, SHA-256 checksums, and GitHub build-provenance
  attestations.

Compatibility

This is the first draft release. Later 0.x releases may be incompatible in reader, writer, or
semantic behavior.

Important limitation

Evaluator conformance is not defined. The condition and resolution material records experimental
design intent; it is not a portable runtime contract. Conformance does not establish truth,
authorization, safety, or operational fitness.

See TESTING.md, VERSIONING.md, and conformance/README.md in this release for details.