How LyraShield AI publishes security guidance
This policy explains how the LyraShield Team researches, reviews, illustrates, updates and corrects public security guidance. A polished article is not evidence that a security claim is true. The sources, technical review, stated scope and retained limitations carry that responsibility.
Last reviewed:
AI assistance
AI tools may help organize research, compare an article against its brief, prepare an early draft, check internal links or develop image concepts. They do not approve a source, establish a product fact, perform the final technical review or decide that an article is ready to publish.
Human accountability
The LyraShield Team remains accountable for every published claim. A reviewer checks the cited source, the current repository behavior behind product statements, safe wording, examples, limitations, links, metadata and the final release candidate. Organization authorship means the team owns corrections; it is not a claim that one unnamed person has tested every system described.
Primary sources
Material technical claims should use standards bodies, government guidance, official vulnerability taxonomies, RFCs, vendor documentation, security advisories or original research. Community discussion can reveal reader questions, but it does not establish prevalence, product performance or a security outcome. Editorial inferences are labeled as inferences and kept separate from what a source directly establishes.
Safe examples and automated-check limits
Examples use inert code, synthetic accounts, placeholder credentials and systems the tester owns or has permission to assess. We do not publish working exploits against named targets. Automated checks are described by the surface and evidence they actually cover. A clean result is never presented as proof that an application has no vulnerabilities.
Corrections and material updates
We correct factual, technical and product-boundary errors when they are found. A material correction receives a visible update date and an explanatory note when readers need that context. Stable URLs and stable heading anchors are preserved whenever possible so cited links continue to reach the intended guidance. Editorial cleanup that does not change the guidance does not receive a misleading material-update claim.
Pre-publication checklist
Before an article ships, the reviewer confirms each of the following. A failed item blocks publication; it is not a style preference.
- Product availability statements were checked against the current product, and "live" is separated from roadmap items with an explicit as-of date.
- Each material technical claim has a named source and a date; cross-study or cross-vendor comparisons stay inside what the sources actually establish.
- Examples use inert code, synthetic accounts or owned systems, never real customer data or third-party targets.
- Limitations and boundaries are stated next to the capability they bound, not only on a separate page.
- The visible body, frontmatter FAQ and any structured data describe the same facts, dates and evidence states.
- Material updates carry a truthful update date and, where readers need it, a correction note; cosmetic edits do not claim fresh review.
- Where a named technical reviewer checked the article, the byline records it; the absence of one is never implied away.
Image review
Blog artwork may be generated with Codex Imagegen, then cropped and compressed through a deterministic production pipeline. A person reviews the source, central crop, alternate text, derivative dimensions, file size and article fit before approval. Images remain text-free and cannot imply customers, certifications, live findings or security guarantees.
Prohibited claims
LyraShield AI does not claim "SOC 2 compliant," "certified," "guarantees security," "AI safety tested" (without a named framework) or "adversarial robustness proven." Each of those requires external attestation, a reproducible evaluation corpus, a defined threat model or a formal certificate that LyraShield has not yet obtained. The internal map of what each claim requires, what is honest today and the sequencing to get there lives in docs/whitepaper.md §9. Public copy must stay evidence-backed, scope-bounded and limitation-aware.