Governance

All schema changes — new fields, new sections, new $defs, or structural modifications — follow the RFC (Request for Comments) process described here.

RFC Lifecycle

Proposal → Discussion → Refinement → Review → Decision → Accepted / Rejected

1. Proposal

Anyone may propose a schema extension by opening a GitHub issue using the RFC template. The proposal should include:

• Motivation — what problem does this solve?
• Use case — what contracts or workflows need this?
• Schema diff — the proposed changes to condicio.schema.json
• Example — a complete example document showing the new fields in use
• Backward compatibility — does this break existing documents?

2. Discussion (minimum 7 days)

The proposal is discussed openly on the issue thread. Participants should focus on:

• Does the proposal fit Condicio's scope (contract intelligence extraction)?
• Is the field broadly useful, or specific to one domain?
• Is the naming consistent with existing conventions?
• Could the same goal be achieved with existing fields?

3. Refinement

Based on feedback, the author may revise the proposal. Significant changes should be summarized in a comment on the issue.

4. Review

A designated maintainer (or the Docfide team for v0.x) performs final review:

• Schema validity is checked (npm test)
• New examples validate correctly
• Documentation is updated (field reference, usage guide)

5. Decision

• Accept — schema is updated, examples are added, changelog is recorded
• Reject — issue is closed with explanation
• Defer — marked for future major version

Versioning

Condicio follows Semantic Versioning for the schema specification:

• Major — breaking changes (removing fields, changing required fields)
• Minor — backward-compatible additions (new optional fields, new $defs)
• Patch — fixes, clarifications, documentation

Pre-v1.0, minor changes may include breaking changes with notice.

Schema identifiers currently point at the main branch. Until v1.0, validate against a tagged release and record the version in specVersion. Immutable, version-specific schema URIs are a prerequisite for v1.0.

Conformance and the Profile Registry

A document is validated against the conformance schema that its condicio value resolves to through schema/registry.json: the closed core schema (condicio-core.schema.json) or a registered profile. The base schema is abstract and is never used on its own.

• Level 1 (schema) — the document is valid against its conformance schema.
• Level 2 (integrity) — additionally, identifiers are unique and every clauseRef, obligationRefs/riskRefs entry and party id reference resolves; source-span offsets are ordered and within the text layer; fieldConfidence keys name real properties (rules R1–R6, implemented in both validators).

New profiles are proposed through the RFC process above. An accepted profile is added to the registry with a version, a maintainer, at least one reference example, and a status: draft, candidate, stable or deprecated. CI checks that every profile schema on disk is registered and that every example validates against the schema it is registered under.

Maintainers

During v0.x, the Docfide team acts as the sole maintainer, responsible for:

• Merging RFCs that have reached consensus
• Ensuring backward compatibility where practical
• Maintaining the validation pipeline and release process

Post-v1.0, maintainer roles will be formally defined with community representation.

Scope

Condicio is scoped to contract intelligence extraction data — what tools like CLM platforms, AI extraction engines, and obligation trackers output about a contract. The following are explicitly out of scope:

• Contract drafting or template languages (Accord Project covers this)
• Smart contract execution logic (Solidity, Rust, etc.)
• Document storage or management APIs
• Contract negotiation workflows

Extensions that push beyond this scope should be proposed as companion specifications rather than modifications to the core schema.

Sponsor

Condicio is developed and maintained by Tensflare, which builds the trust infrastructure for consequential AI. Every product Tensflare builds lives in the gap between what AI systems produce and the world that acts on those outputs:

• HalluCase — what went wrong in that gap?
• LegalVerify — is this citation real before it crosses into a courtroom?
• Condicio — can systems on either side of the gap speak the same data language?
• RATIO and DRIFT — is this precedent still true right now?

Legal was first because the consequences are documented, public, immediate, and escalating. Finance and healthcare follow — same consequence profile, different domain.

License

All RFCs and contributed schema changes are licensed under Apache 2.0.