Audit Mathematical Vocabulary

Classify before proposing work

Assign each finding one primary class:

• operation: the reusable mathematical postcondition is absent;
• representation: the mathematical value cannot be expressed canonically;
• interoperability: existing producers and consumers use incompatible values;
• discovery: the operation exists but natural search does not surface it;
• contract: the operation exists but its public semantics or evidence are insufficient;
• scale/backend: the operation exists with the needed postcondition, but a coarse admission proxy, expanded representation, algorithm regime, or bounded implementation is the limiting factor;
• reasoning: the needed vocabulary exists and the remaining failure is strategy selection or mathematical reasoning; or
• no gap: the investigated path is already supported or does not justify a product change.

Before opening anything, search local reports and live issues and pull requests of every state for the mathematical family, operation IDs, and root mechanism. Treat an owned finding as ownership evidence, not a new issue. External issue, comment, or pull-request mutations still require explicit authorization.

A new gap is ready to file only when it has a stable mathematical postcondition, a plausible bounded exact implementation, useful composition with canonical values, concrete evidence beyond a single trace or backend API, and no existing owner. Lead the issue with the user or mathematical need, keep confirmed facts separate from hypotheses, and leave admission or implementation details open unless the evidence settles them.

When external issue creation is authorized, make the issue implementable rather than merely descriptive. Include the smallest discriminating exact fixture, the defining invariant or an independent oracle, the relevant degenerate or adversarial case, the preflight quantities that bound work and exact output, and explicit non-goals. For a repair, also state the existing owner and the smallest producer-consumer or public-contract regression. Do not invent a backend prescription when the evidence establishes only the postcondition.

Do not file a new operation solely because an existing operation rejects a large input. First determine whether predicted work, intermediate growth, and exact output remain small; whether a sparse, factored, modular, symbolic, or implicit representation avoids expansion; and whether a maintained backend or different exact algorithm materially widens the envelope. If so, record a scale/backend or admission gap against the existing postcondition.

Report the result

Report the slice and revision, evidence coverage, classified findings, ownership, and meaningful proof gaps. A valid audit may end with no gap. Propose another slice only when continued exploration is relevant to the request.

Persist a report when requested or needed for an ongoing audit campaign. Keep revision, slice, outcome, and ownership identifiable so later audits can check coverage; do not maintain a separate database for a few reports.