Contributing To Ardur

Ardur is an engineering-first open source project. Contributions should make the runtime, verifier, deployment posture, or framework support clearer and more trustworthy.

Before you open a pull request

1. Make sure the change fits the public product surface.
2. Update docs when behavior or support boundaries change.
3. Keep claims aligned with the proof registry and verifier outputs.
4. Avoid introducing internal-only language, session mechanics, or private planning material into the public surface.

Contribution priorities

We especially welcome contributions that improve:

• public docs and positioning clarity
• verifier and artifact quality
• runtime governance correctness
• framework adapters with honest support boundaries
• documentation clarity
• deployment and self-hosting guidance
• security hardening that stays proofable

Proof and honesty rules

• Do not call a capability proven unless the verifier and public artifacts back that claim.
• If a surface is design-only or foundation-scope, label it explicitly.
• Do not land docs that market a capability more strongly than the evidence allows.

No specific LLM model names in public surfaces

Public-facing artifacts in this repository must not name specific LLM products or model identifiers. This applies to docs, READMEs, comments, docstrings, commit messages, PR descriptions, recorded media metadata, and any test fixture or default-parameter literal that would surface a model id when read.

The rule exists for two reasons. First, model identifiers churn fast and hard-coded names age the public surface visibly within months. Second, benchmarks and adapters that name a specific model imply we recommend or endorse it; we don’t, and the protocol is meant to be model-agnostic.

In practice:

• Use generic phrasing: “a frontier LLM provider”, “an open-weight local model”, “the LLM under test”, “a major model family”.
• For configurable defaults, source the model id from an environment variable (e.g. ANTHROPIC_MODEL, OPENAI_MODEL) or require the caller to pass it explicitly. Don’t ship a hard-coded literal.
• For attribution of review findings, use opaque codes (e.g. “external-review-G F6”, “external review round 2”) rather than naming the reviewing tool.
• For framework-name references, frameworks (LangChain, AutoGen, etc.) are fine — they’re libraries, not LLM models. Vendor names without a model identifier (Anthropic, OpenAI, Google) are acceptable when the context is “API provider” rather than “specific model”.

The CI secret-scan workflow includes a model-name gate that blocks PRs containing common model-id patterns. If you have a legitimate need to name a model in a private context (e.g. an internal benchmark log that lives in a gitignored path), keep that material out of tracked files entirely.

Current public repo note

This repo is opening in phases. Until the curated runtime code lands here, many contributions will be docs, media, packaging, or launch-surface changes rather than direct runtime edits. When code-bearing surfaces arrive, local check guidance should be updated to match the real public commands.

Pull request expectations

• Keep changes scoped and reviewable.
• Explain user-facing behavior changes clearly.
• Mention any security, compatibility, or proof-boundary impact.
• Link to the relevant verifier, artifacts, or limitation note when a claim is affected.

Security reports

For active vulnerabilities, use the process in SECURITY.md instead of opening a public issue.