FDE BenchmarkPublic document reader
Available in sourcev0.1 · live public draft · official release pending

Canonical source view. This renders the bundled repository document as readable HTML. Source metadata remains in the repository, and relative document links remain inside this reader.

Contributing

Status: v0.1 Public Draft contribution policy

The LockedIn FDE Benchmark welcomes rigorous review from practitioners, customers, researchers, measurement specialists, accessibility experts, security professionals, and implementers.

Contribution does not imply endorsement, partnership, governance membership, or influence over an individual result.

1. Before contributing

Read:

Check LIVE_VS_PLANNED.md so a proposal does not assume a planned feature is operational.

2. Useful contribution types

  • Construct, domain, capability, or rubric critique.
  • Evidence and verification model improvements.
  • Synthetic public cases and invalid/edge-case fixtures.
  • Accessibility and accommodation analysis.
  • Threat models, integrity tests, and privacy reviews.
  • Scoring, uncertainty, and calibration research.
  • Schema and reference-implementation fixes.
  • Standards mappings with authoritative sources and licensing notes.
  • Documentation, translations, and usability improvements.
  • Domain-pack proposals that preserve the vendor-neutral core.

3. Never submit publicly

Do not place any of the following in an issue, discussion, pull request, fixture, commit, or public RFC:

  • real candidate, employee, customer, patient, or reference data;
  • private repositories, code, architecture, credentials, or deployment records;
  • secrets, tokens, keys, identity documents, or personal contact information;
  • copyrighted or confidential material without permission;
  • suspected hidden official cases or evaluator prompts;
  • vulnerability details that could enable exploitation;
  • allegations about an identifiable person.

Public examples must be conspicuously synthetic and must not be lightly disguised real cases.

4. Choose the smallest path

Use a focused issue for a typo, clarification, test failure, or non-normative correction.

Use an RFC for:

  • a construct, ontology, rubric, scoring, verification, or result-class change;
  • a new domain pack or controlled-case approach;
  • a normative schema change;
  • a change with privacy, security, employment, accessibility, or fairness impact;
  • a governance or charter change.

Before drafting a large RFC, open a concise problem statement so maintainers can identify overlap, dependencies, or controlled information that should not be discussed publicly.

5. RFC content

An RFC should include:

  1. Summary and problem statement.
  2. Intended population and use.
  3. Proposed normative behavior.
  4. Evidence and authoritative sources.
  5. Alternatives, including no change.
  6. Measurement and calibration plan.
  7. Security, privacy, integrity, accessibility, and fairness effects.
  8. Versioning, migration, and compatibility impact.
  9. Conflicts of interest and relevant affiliations.
  10. Implementation, test, and rollback plan.
  11. Open questions and known limitations.

A compelling RFC can still be deferred when evidence, operational capacity, or a release gate is missing.

6. Quality requirements

Contributions should:

  • distinguish normative requirements from informative rationale;
  • use stable identifiers and released terminology;
  • avoid unsupported claims, superlatives, and partner implications;
  • cite authoritative, current sources with version and access date;
  • explain what is adopted, extended, rejected, or novel when mapping another framework;
  • add or update tests for machine-readable behavior;
  • include valid and invalid synthetic fixtures where schemas change;
  • preserve deterministic output and append-only history where applicable;
  • update the benchmark card, status register, roadmap, or changelog when behavior changes;
  • use inclusive, plain language and accessible structure.

Generated or AI-assisted content is allowed only when the contributor verifies it, has rights to submit it, and accepts responsibility for its accuracy and licensing. Do not send repository content or reports to an external model without authorization.

7. Review process

Review follows the public process in GOVERNANCE.md: proposal, public review, applicable technical and measurement review, conflict check, recorded decision, implementation, tests, and release.

Maintainers may request smaller scope, additional evidence, an accessibility or security review, or a new version boundary. A merged change is not official benchmark behavior until it appears in a released manifest.

Reviewers must disclose conflicts and recuse where required. Sponsors and employers receive no expedited normative approval.

8. Contribution rights

The intended licensing model is Apache-2.0 for reference code and schemas and CC BY 4.0 for specification and documentation, subject to legal approval.

Operative license files are published: reference software, schemas, fixtures, scripts, and the public site are licensed under the Apache License 2.0 (LICENSE); specification, policy, ontology, and research content under CC BY 4.0 (LICENSE-CONTENT.md); attribution requirements are in NOTICE. Trademarks are excluded from both grants.

Contributor attestation uses the Developer Certificate of Origin 1.1 (https://developercertificate.org/). Every commit in an external contribution must carry a Signed-off-by: Name <email> trailer (git commit -s), which certifies that you have the right to submit the work under the applicable license and that the contribution contains no private, customer, candidate, or credential material. Commits without a sign-off are not merged. The project does not use a separate contributor license agreement.

By contributing, you agree that your contribution is licensed under the license that applies to the artifact type you changed, and that the project may relicense content between the two published licenses when a file changes category (for example, prose that becomes a fixture).

Trademark rights are separate; see TRADEMARK_POLICY.md.

9. Security, conduct, and appeals

10. Current participation limit

License files and Developer Certificate of Origin attestation are in place. The project must still publish operational private security and conduct-reporting channels before opening managed public contribution. Until those gates are met, this guide documents the intended process rather than promising review service levels.