Publish first-class observation APIs across all SDKs - #74
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Yield already projects privacy-safe run receipts, stores them durably, and
builds local reports. Those capabilities were internal to the CLI, and the
language-neutral receipt schema did not yet have programmatic readers in every
supported SDK.
What changed
github.com/operatorstack/yield/observationwith the existingyield.observation.v1receipt typesProject, strictParse,CanonicalBytes, andVerifyCanonicalAPIsStoreand deterministicBuildReportaggregation
onto the public Go package
TypeScript, Python, and Rust SDKs
The Go supervisor remains the only component that projects receipts from the
authoritative append-only run journal. TypeScript, Python, and Rust consume the
same portable IR: they validate its closed schema, reproduce Yield's
integer-only RFC 8785 canonicalization profile, and verify the embedded SHA-256
digest. They do not read or mutate journals, write receipt storage, or
participate in replay.
Compatibility and boundaries
This does not change
yield.v1,yield.observation.v1, canonical receiptbytes, receipt digests, storage paths, CLI behavior, replay behavior, or outbox
delivery. Existing v0.6 journals remain inputs and are never rewritten.
The append-only journal remains authoritative. Projection is read-only; local
receipt persistence remains isolated in
observation.Store; journal mutationremains in the supervisor; and replay still has no receipt or sink dependency.
Generic sink delivery and pure SDK evaluators remain separate follow-up
changes.
Verification
npm run format:checkgo vet ./...go test -count=1 ./...go build ./...go test -race ./observation ./internal/runlog ./internal/engine ./internal/outboxnpm run test:releasenode scripts/check-release-control.mjsTests cover deterministic projection, schema alignment, legacy journals,
privacy exclusions, malformed and partial prefixes, strict canonical parsing,
digest mismatch, durable store convergence, engine materialization, outbox
compatibility, external Go package use, and exact cross-language parsing of the
shared canonical fixture.