Skip to main content
You can help shape draft v0.1 by describing the questions your business asks, the pricing rules it uses and the points where a person must decide. Keep contributions reference, not production, and use synthetic examples instead of customer details.

​
Start with a traceable change

Read the repository’s CONTRIBUTING.md, LICENSE, NOTICE and CLA.md before proposing changes. The repository’s spec text, schemas, packs and code use Apache-2.0. You must sign the Contributor License Agreement with 1G Media Inc. before a contribution can be accepted; the CLA is still a draft pending legal review, with signing instructions to follow once finalized. You should also respect the UQP and Universal Quoting Protocol names held by 1G Media Inc.; the repository says a trademark policy will be published at version 1.0.

​
Preserve pack and research boundaries

When you change a pack, map questions to factors, record provenance and assumptions, and add synthetic test cases for exceptions. Keep the tattoo and laser-removal packs marked unvalidated. Label sample prices example data; implemented pricing rules are not evidence of market prices or clinical validity. Review the questionnaire harness and evidence before using research material. The harness is an offline, synthetic demonstration, not authorization to collect real pages. You must resolve the study’s permission, sampling, retention and analysis gates before any future collection. Do not submit personal information, customer answers or private images as fixtures.

​
Keep generated documentation in sync

Edit the source schema, binding, pack or research document rather than its generated MDX page. From the repository root, regenerate reference content before committing:
You can edit the introduction, quickstart, lifecycle and contributing pages directly. Keep internal links root-relative, give code fences a language tag and preserve the distinction between non-binding estimates and reviewed quotes. See the lifecycle before changing transition behavior.

​
Keep the payment boundary explicit

You must preserve explicit client approval before checkout handoff, the provider’s merchant-of-record role and trusted processor confirmation before marking a deposit paid. Do not imply that reference bindings implement production authentication, checkout processing or deployment.

​
Join co-design

Use the co-design form to share your business requirements. Name, email, and industry (repo link and notes optional)