Editorial policy

How Penaxtra Writes Technical Content

Public commitment for blog, docs, and research authors.

Buyers and auditors rely on the Penaxtra blog and documentation to make decisions. This page is the public commitment behind that content: how we author, source, review, update, and correct it.

How Penaxtra writes technical content

Every public article is written by a named Penaxtra team (engineering, security research, or compliance engineering). Content is reviewed by at least one technical reviewer outside the original team before publication. We do not publish anonymous content, and we do not publish content written end-to-end by an LLM. AI tools are used for editing assistance and outline generation; the final draft is human-authored.

Source policy

  • Primary sources first. Framework references link to the official primary source (OWASP, NIST, ISO, MITRE, EUR-Lex) rather than to a third-party summary.
  • Product claims trace to code. Any feature claim on a blog post or docs page maps to a shipped subsystem; if it does not, the article labels the feature "planned" or "on the roadmap" explicitly.
  • No competitor names in marketing copy. Categorical comparisons reference approaches (manual pentest, single-judge scanner, guardrail-only gateway, compliance spreadsheet, CNAPP-bundled AI module) rather than vendor brands.
  • No customer names without consent. Use cases and deployment scenarios are illustrative until a customer signs an explicit publication consent.

Review policy

  • Every article goes through two reviews before publication: a technical accuracy review and an editorial review.
  • Articles touching compliance frameworks additionally require sign-off from the compliance engineering team.
  • Security-claim articles require sign-off from the security research team.
  • Reviewer names are recorded in the internal git history; not all reviewer identities are published externally.

Update policy

  • Each article carries a visible Last reviewed date.
  • Compliance framework articles are re-reviewed at least every 12 months or when the upstream framework publishes a material change.
  • Methodology pages are re-reviewed quarterly.
  • When an article is updated, the change shows in the article footer; substantive changes ship as a new dateModified in the JSON-LD.

Security-claim policy

  • Performance claims (latency, throughput, cost) carry a link to the public methodology page that defines how the figure is measured.
  • Compliance claims (control mapping, framework coverage) link to the framework page and the primary source.
  • Privacy claims (prompt egress, redaction, retention) link to the privacy methodology page.
  • If a claim cannot be substantiated with a public link, it does not ship on a marketing page.

Correction process

If you find a factual error, broken link, or outdated claim, email [email protected] . Corrections are made inline with a visible note in the article footer; substantive corrections additionally bump the article's dateModified field.

Contact

  • Corrections and editorial feedback: [email protected]
  • Security disclosure: see the RFC 9116 security.txt
  • Privacy: [email protected]

Related

Last reviewed: 2026-06-15. Reviewed by: Editorial. Next review: 2026-12-15.