Skip to content

feat: add deterministic OpenMetadata admission preview receipts - #97

Draft
seonghobae wants to merge 32 commits into
feat/openmetadata-2-read-adapterfrom
feat/openmetadata-admission-receipt
Draft

seonghobae wants to merge 32 commits into
feat/openmetadata-2-read-adapterfrom
feat/openmetadata-admission-receipt

Conversation

@seonghobae

Copy link
Copy Markdown
Contributor

Buyer problem

A normalized projection alone is not enough for reliable cross-product admission. Operators and downstream consumers need to prove which source installation, exact verified compatibility profile, submitted snapshot, and safe projection produced a candidate—without copying sample rows, SQL, DDL, transformation text, or other omitted source values into a general receipt.

Bounded successor

This PR is stacked on #96 and owns only the deterministic, non-mutating admission-preview contract.

  • No database row is written.
  • No raw payload is retained.
  • No OpenMetadata API is called.
  • No credential or egress path is added.
  • No catalog asset becomes authoritative or published.
  • No mutable context-graph-contracts PR head is consumed.

RED contract

Commit 14d4151913c5c2a466a59a7fd5d9e517e96f5876 was written before production code. It requires:

  • canonical JSON hashing independent of object insertion order;
  • identical receipt identity for 2.0.1 and 2.0.1-release;
  • installation-scoped replay identity;
  • separate source-snapshot and safe-projection digests;
  • omitted secret values to affect source identity without entering the receipt;
  • fail-closed rejection of NaN/non-canonical JSON;
  • timezone-qualified observation time;
  • typed POST /integrations/openmetadata/v1/table-snapshots:admission-preview;
  • explicit non-persistence and non-mutation evidence.

Focused RED verification fails at import because preview_openmetadata_table_admission does not exist. Production implementation follows on this branch.

Intended receipt

source installation + exact compatibility profile + canonical source digest
    -> verified safe projection
    -> canonical projection digest
    -> deterministic replay key and receipt ID

The receipt will be suitable as the input contract for the next 3NF persistence slice, but it is not itself a durable admission or source-origin attestation.

Merge discipline

  • feat: add OpenMetadata 2.x read-only normalization boundary #96 must integrate first or this PR must be non-force restacked onto its protected merge result.
  • Full exact-head tests, coverage, docstrings, fuzz/SAST/security, review, and independent approval are required after the production implementation is complete.
  • No predecessor evidence transfers and no bypass merge is requested.

Part of #95.

@coderabbitai

coderabbitai Bot commented Sep 3, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@seonghobae seonghobae added enhancement New feature or request priority: medium Normal-priority or P2 work type: feature New or expanded product capability labels Sep 7, 2026 — with ChatGPT Codex Connector
seonghobae pushed a commit that referenced this pull request Sep 7, 2026
main has no docs/adr/ directory yet, but five open PRs each add ADRs
under the same four-digit ids for unrelated decisions.

ADR 0001 is claimed by #72 (product-authority-boundary), #73
(ontology-catalog-plane), #88 (measurement-context-registry) and #96
(openmetadata-anti-corruption-boundary). ADR 0002 is claimed by #72
(semantic-web-grounding), #73 (corporate-master-resolution-owner) and
#97/#99 (openmetadata-admission-preview-receipts). #97 and #99 sharing a
path is expected since they are the same succession lane.

Whichever PR merges first takes the number; the rest either hit add/add
conflicts or quietly land a different decision under an id that is
already cited elsewhere. This baseline itself cites #73's corporate-master
decision as "ADR 0002", which would silently point at #72's
semantic-web-grounding if #72 merged first.

Per the repair rule a number collision is a rename, not a redesign, so no
PR is closed and no content changes. Records a default allocation derived
mechanically from the merge order already documented here, and notes that
the allocation follows the order if the order changes.

Docs only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QpbqAeggRho3fQA1gn34UY
seonghobae pushed a commit that referenced this pull request Sep 7, 2026
Second finding in the ADR lane, separate from the number collision.

main has no docs/adr/ directory, yet #73's two ADRs already declare
Accepted: 0001-ontology-catalog-plane.md ("Status: Accepted", dated
2026-08-18) and 0002-corporate-master-resolution-owner.md ("Status:
Accepted target contract"). #73 is still open and, per this baseline,
failing trivy-fs and strix.

Every other ADR-bearing PR uses a correct pre-merge status: #72 Draft,
#88 Proposed, #96 Proposed, #97/#99 Proposed. #73 is the only outlier.

A decision that exists solely inside an unmerged PR but claims Accepted
makes decisions on the protected branch indistinguishable from proposals
when reading the documents alone. Queued, pending and unmerged states are
not acceptance evidence. The repair is one status line per file, not a
content change: hold Proposed until #73 lands, then raise to Accepted.

Also confirm the #97 to #99 succession from primary evidence rather than
inference: #99's ADR states "대체 대상: PR #97의 유효 delta를 검증 후
승계", so the merge-order note no longer hedges.

Notes that #73's ADRs already use the owner/repo#num convention for
cross-repository references, which is why the lineage row's bare #74 was
the exception rather than the local norm.

Docs only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QpbqAeggRho3fQA1gn34UY
seonghobae pushed a commit that referenced this pull request Sep 9, 2026
…ur writers

This document flagged the #97/#99 relationship as "successor, but verify
the delta before closing either". Verified: it is not a full succession.

#99 carries every file #97 touches except one —
`tests/test_openmetadata_admission_evidence_verification.py`, whose three
test functions are absent by name from #99's entire diff. #99 also adds
work #97 lacks. The two PRs hold delta in both directions, so closing #97
as superseded would drop three receipt-verification tests. Recorded with
its limit: name absence is not proof that no differently-named test covers
the same guarantee, and the burden sits with the successor.

Separately, both PRs edit this file — #97 at +28/-8 and #99 at +154/-134,
which is a section-level rewrite. With #79 as its single writer and #102
stacked on that branch, this file now has four writers and will conflict
whichever lands first. Raised as a repair finding, not a close: the
baseline delta belongs on #79's branch, and the adapter PRs should stay
inside their own boundary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QpbqAeggRho3fQA1gn34UY
seonghobae pushed a commit that referenced this pull request Sep 9, 2026
This baseline had no diagram, though the merge order it defines is a
dependency graph and the repository already uses mermaid in
docs/prd-trd.md. At 679 lines, the ordering was only recoverable by
reading a hundred lines of prose.

Adds two figures next to the merge order: the PR dependency DAG across the
four groups (security unlock, catalog plane, docs, OpenMetadata), and a
second showing which owner each failing check belongs to.

The prose stays normative and the figures are a summary of it; that is
stated inline so the two cannot silently diverge. The DAG also carries the
open question rather than hiding it — #81 is drawn as the root because
trivy-fs scans the merge ref, with a note that #73 has already cleared the
same CVE on its own head, so which PR holds that root is unsettled. The
#97 to #99 edge is dotted and labelled as an incomplete succession.

Verified before commit: fences balanced, both mermaid blocks have balanced
quotes, brackets and parens, and every PR number in the figures resolves to
a currently open pull request.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QpbqAeggRho3fQA1gn34UY
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request priority: medium Normal-priority or P2 work type: feature New or expanded product capability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant