Identify
- Tracevity page URL and system name
- Capability family or exact statement
- Version or date scope affected
Corrections
Make the evidence record better
Report an incorrect source, outdated version scope, unsupported interpretation, missing limitation, or publication error. Corrections are evaluated against current primary evidence and preserve revision history.
How to report
Open a bounded public report—never post a production trace.
Open a documentation correction or CLI bug in the verified Tracevity feedback repository. Include the affected page or command, exact statement or behavior, supporting primary-source locator, and the narrowest reproducible explanation. Never post credentials, private logs, customer data, source code, prompts, outputs, or confidential traces.
Sensitive security finding
Use private vulnerability reporting.
Do not open a public issue containing exploit details, credentials, private traces, or customer data. GitHub's private report flow keeps the disclosure out of the public issue tracker.
Useful report
Include enough context to reproduce the documentation review
Support
- Current primary-source URL
- Heading, anchor, field path, or other locator
- Short bounded excerpt or faithful summary
Explain
- What is inaccurate or incomplete
- Whether the source conflicts with another document
- The narrowest correction that resolves the issue
Review process
What happens next
| Stage | Tracevity action | Evidence state |
|---|---|---|
| Triage | Confirm scope, affected profile, and whether a primary source is available. | Candidate correction |
| Re-review | Compare the report with current primary documentation and existing evidence. | Documented, unknown, or conflicting |
| Decision | Accept, reject, or narrow the correction with a recorded review basis. | Explicit review outcome |
| Publication | Create a superseding profile revision and regenerate the public artifact. | Published revision only |
A submitted correction does not silently change a public profile. Material changes preserve the previous revision and its historical evidence context.
Before submitting
Check the claim boundary.
“Not documented” means the reviewed source did not establish the capability; it does not claim that runtime behavior is impossible. The methodology explains each posture.