feat(contracts): finalized v1 DataLex contracts for the demo - #10
Merged
Conversation
Adds the four canonical commerce-domain contracts the joint DataLex+DQL walkthrough references end-to-end: - commerce.Customer.monthly_active_customers (backs the new MAU block) - commerce.Customer.customer_lifetime_value (backs LTV blocks/cohorts) - commerce.Order.monthly_revenue (backs the monthly review) - commerce.Order.order_total_non_negative (data-quality invariant) Two artifacts ship together: 1. DataLex/commerce/contracts.model.yaml — the source-of-truth YAML in DataLex's existing convention extended with manifest-spec v1 contract fields (id, version, signature.inputs, signature.outputs, constraints). This is what users author and the DataLex compiler will eventually consume to emit the v1 manifest. 2. datalex-manifest.json (repo root) — the hand-curated v1 compiler-output artifact, conforming to manifest-spec/schemas/v1/datalex-manifest.schema.json. DQL projects in the walkthrough drop this file in and resolve their `datalex_contract = "..."` references against it today, before the DataLex compiler natively emits the v1 manifest. Verified schema-valid. Why both: the YAML is the human-authored source; the JSON is what the DQL compiler/MCP consume. Until the DataLex compiler ships its v1 emitter, the JSON is hand-curated; once the emitter lands, the JSON gets generated from the YAML and we delete the hand-crafted copy. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The DataLex CLI's validator accepts these top-level kinds: project, entity, source, model, term, domain, policy, snippet, diagram, relationship, data_type, semantic_model. Our top-level `kind: contracts` documents the intended source-of-truth shape but isn't yet a first-class DataLex artifact, so the .model.yaml extension caused CI to flag it. Renaming to .spec.yaml takes it out of the `models: DataLex/**/*.model.yaml` glob in datalex.yaml. The file content is unchanged and remains a human-readable reference for the contracts surfaced in the canonical datalex-manifest.json. When the DataLex compiler grows a first-class contracts kind we'll revisit the extension. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
2 participants
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.
Adds the four canonical commerce-domain contracts that the DataLex+DQL walkthrough references end to end. Schema-validated against `manifest-spec/v1` (will be live at `github.com/duckcode-ai/manifest-spec` once the org repo create lands).
Two artifacts
The four contracts
Test plan
Followups
🤖 Generated with Claude Code