Contributing to the Free eVTOL Corpus

Thank you for considering a contribution. Before you write an entry, please read this carefully — the contribution model here is unusual.

What you are doing when you contribute

You are writing a defensive publication, not a Wikipedia entry.

Every entry in this corpus is, at the moment of timestamped release, a public disclosure citable as 102 prior art against any patent with a later effective filing date. That is the corpus’s reason for existing and the reason it works.

This means contributions carry weight that ordinary catalog entries do not. Sloppy citations, fuzzy dates, or hand-wavy prior art notes weaken the commons for everyone. Tight, primary-sourced, element-by-element entries strengthen it.

CC0 dedication

By submitting a contribution you dedicate it to the public domain under CC0 1.0. The contribution must be your own work or already in the public domain. Do not copy text wholesale from copyrighted sources — paraphrase in your own words and cite the source.

What counts as a good entry

An entry is commons-grade (draft: false) when it satisfies all five criteria:

1. The disclosure citation resolves to a primary source

The disclosure_citation field must point at something a third party can actually retrieve and verify. Acceptable: a paper with a DOI, a patent number, a book with an ISBN, a public press release with a date, an arXiv identifier, an episode of a TV series with first-air-date, a type certificate (e.g., EHang EH216-S CAAC TC of 2023-10-13).

Not acceptable: “Wikipedia,” “company website” (without a specific page and date), “I read this somewhere,” secondhand summaries.

2. The first disclosure date is defensible

The first_disclosure_date must be the earliest verifiable public disclosure, not the earliest plausible date or the date you happened to learn about it.

If an aircraft was unveiled at AirVenture in July 2024 but the company issued a press release in March 2024, the March date is correct. If a sci-fi craft first appeared in a 1965 novel that was later adapted into a 1984 film, the 1965 novel is correct.

When in doubt, choose the earliest date you can cite to a primary source.

3. The prior art notes are element-by-element analysis

This is the field that does the most work. prior_art_notes should read as the kind of analysis a competent patent examiner or invalidity-contention attorney would write. It identifies specific subsystems disclosed and what claims those disclosures could anticipate.

Bad example:

This is an important air taxi.

Good example:

Discloses tilt-rotor architecture with cyclic-and-collective rotor control and a thrust-borne-to-wing-borne conversion corridor managed by triplex fly-by-wire. Bell XV-15 NASA technical reports document specific blade twist distributions, transition-corridor envelopes, and gimbal-bearing rotor-hub geometry. Anticipates tilt-rotor patent claims around conversion control allocation and gimbaled prop-rotor hubs filed after 1977.

If you cannot write the second kind, mark the entry draft: true and note in the notes field what work would be needed to clear the bar.

4. Sources are primary references

The sources array should list papers, patents, books, episodes, or official corporate disclosures. Aggregators (Wikipedia, secondary news coverage) are acceptable only as supplements, not as the primary citation.

5. Patented entries enumerate patents

If ip_status is patented, then ip_citations must list at least one actual patent number. “Patent filings exist” is not sufficient.

Submitting an entry below the quality bar

Mark the entry "draft": true and document in notes what work would be needed to clear the bar. Drafts are welcome — they make incremental progress visible without polluting the commons-grade entry pool.

A draft entry is still useful: it reserves the slug, captures what is known, and identifies the strengthening work needed. Many recent commercial eVTOL programs disclose only marketing material publicly; they will become commons-grade as type certificates, NTSB reports, or patent filings appear.

Practical workflow

1. Run python3 tools/validate.py corpus.jsonl --strict before submitting. This catches structural errors and quality bar failures.
2. Run python3 tools/index.py . to regenerate CORPUS_INDEX.md, lineage.json, and per-corpus mirrors.
3. Run python3 tools/cross_cuts.py to regenerate the prior art views.
4. Commit the regenerated artifacts alongside your entry — they are committed deliberately so browsing on GitHub shows the working state.
5. Open a pull request.

Choosing a good slug

The id field is a kebab-case slug used in lineage edges, cross-cuts, and citations. Pick one that disambiguates well.

• For commercial products: <company>-<product> (e.g., joby-s4, archer-midnight, ehang-eh216)
• For academic / military demonstrators: <institution>-<name> or canonical (e.g., bell-xv-15, nasa-gl-10, ltv-xc-142)
• For fictional craft: <franchise>-<name> or canonical (e.g., bladerunner-spinner, verne-albatross, jetsons-aerocar)
• For software/concepts: descriptive (e.g., ardupilot-quadplane, simplified-vehicle-operations)

Slugs are immutable once an entry is referenced by another entry’s lineage edges. Choose carefully.

Subsystem tagging

The disclosed_subsystems field uses the controlled vocabulary defined in SCHEMA.md. Tag every subsystem the entry discloses with enough specificity to be citeable. Do not invent new tags casually — propose them in a separate PR if needed, with a rationale.

Lineage edges

lineage_ancestors lists the ids of entries this entry descends from. lineage_descendants is filled in symmetrically by other entries pointing back, but you can pre-fill it where you know the descendants.

The indexer detects cycles and surfaces missing references as warnings. Both are diagnostic outputs, not errors — you can submit a PR that references entries not yet in the corpus and the warning becomes a to-do item for a later contributor.

Questions

Open an issue. Discussion of methodology, taxonomy gaps, and quality bar calibration is welcome.