-
Notifications
You must be signed in to change notification settings - Fork 0
Contributing and Feedback
Meridian Verity Group edited this page Jul 19, 2026
·
1 revision
| Feedback type | Route |
|---|---|
| Synthetic negative vector or missing DENY case | Open a structured issue |
| Field-model or terminology ambiguity | Open a structured issue |
authorization_ref or signature-coverage interoperability question |
Open a structured issue |
| Reproducibility/documentation problem | Open a public issue using synthetic/public information |
| Security-sensitive vulnerability | Report privately |
| Internet-Draft or standards-process discussion | Use the applicable IETF venue and policies |
| Licensing, patent, production, or commercial rights | Handle separately in writing with the applicable rights holder |
Do not include vulnerability details in a public issue.
A useful report includes:
- release tag and commit;
- operating system, architecture, Python, and pip versions;
- exact commands;
- a minimal synthetic input or public vector;
- expected and actual decision/result;
- denial reason or stage when relevant;
- artifact checksum when reviewing a release ZIP; and
- confirmation that no sensitive or unauthorized data is included.
Do not submit:
- customer, cardholder, regulated, or personal data;
- production logs or credentials;
- API keys, signing material, access tokens, or secrets;
- non-public processor, wallet, issuer, or network details;
- proprietary implementation mappings;
- confidential legal, patent, licensing, or claim-chart material;
- private commercial strategy; or
- third-party material you are not authorized to contribute.
Pull requests may be declined unless separate contribution terms are approved. Before proposing code:
- open a public-safe issue describing the change;
- confirm whether the maintainer is willing to review a code contribution under acceptable terms;
- keep the change narrowly scoped;
- add or update deterministic positive and negative tests;
- run strict tests, vectors, reviewer packet, manifest, and release gates as applicable;
- update boundary and version documentation when semantics change; and
- avoid changing licensing, patent, standards-status, or production-claim language without explicit maintainer review.
Repository activity is governed by the evaluation-only terms unless separately agreed in writing. IETF venue activity is governed by applicable IETF processes and policies.
The most valuable contributions falsify assumptions: a field omitted from canonicalization, an ambiguous representation, an unexpected ALLOW, a replay race, stale-state behavior, an independent digest mismatch, a signature-coverage gap, or a reproducibility failure in a clean environment.