Editorial & AI Use Policy

1. Editorial purpose

Articles on dulmina.com are intended to make cybersecurity, information security, AI security and practical technology topics useful, understandable and applicable. The aim is not to publish material merely to increase page count or repeat information already available elsewhere.

Where possible, an article should move beyond definitions and explain the problem, relevant theory, practical application, controls, limitations and the reasoning behind important decisions.

2. Source priorities

The editorial process is designed to prefer authoritative and primary sources for factual claims. Depending on the topic, these may include:

• standards bodies and official government guidance;
• NIST, OWASP, CISA, ENISA and Sri Lanka CERT;
• official product and framework documentation;
• original research papers, advisories and vulnerability records;
• reputable technical organisations and vendor security documentation; and
• credible secondary sources where they add context and are clearly distinguished from primary evidence.

Search results, summaries, social posts and AI-generated text are not treated as sufficient evidence for an important factual claim on their own.

3. AI-assisted work

AI tools may assist with parts of the publishing workflow, such as research discovery, outlining, drafting, editing, summarisation, code review, metadata, or generation of original visual concepts.

AI assistance does not replace source verification. The editorial process is designed so important claims are checked against authoritative material before publication, and uncertain claims are removed, qualified or clearly identified rather than presented as fact.

4. Accuracy and reliability

Articles should avoid invented statistics, unsupported quotations, fabricated incidents, fake scan output, fake screenshots, invented vulnerabilities or simulated evidence presented as real.

Version-specific claims should identify the relevant version or date where that context matters. When a topic changes rapidly, readers are encouraged to check the linked official source for the newest guidance.

5. Practical examples and demonstrations

Technical examples are intended to demonstrate reasoning and responsible application of security concepts. Security demonstrations should be safe, educational and appropriate for authorised environments.

Examples should not imply that a control is universally sufficient. Where relevant, limitations, assumptions, threat models and alternative controls should be explained.

6. Diagrams, images and visual evidence

Visual material should add meaning rather than decorate a page without purpose. Original diagrams may be used to explain architectures, trust boundaries, data flows, attack paths, security controls or decision processes.

Diagrams are intended to be technically consistent with the accompanying explanation. If an external image, chart or other third-party visual is used, the goal is to verify that its use is permitted and provide appropriate source and licence attribution where required.

Generated or reconstructed visuals should not be presented as photographs, screenshots, packet captures, scans or experimental evidence from a real event unless they genuinely are such evidence.

7. Writing style

Articles are intended to use clear, natural English with a useful balance between explanation, examples, diagrams, tables and lists. Technical depth should come from reasoning and application, not unnecessary complexity or exaggerated claims of expertise.

8. Independence and disclosures

A mention of a company, tool, framework, product or service does not automatically indicate sponsorship, endorsement or affiliation.

If an article is sponsored, paid for, materially influenced by a commercial relationship, or contains an affiliate arrangement, that relationship should be disclosed clearly on the relevant content.

9. Corrections and updates

Security and AI guidance can change. Articles may be updated when an important factual issue, broken reference, major version change or meaningful new development is identified.

If you believe an article contains an error, please send the article URL, the specific issue and, where possible, a reliable supporting source to x@dulmina.com.

10. Reader responsibility

Published material is educational and informational. Readers should assess advice in the context of their own systems, laws, permissions, threat models and operational requirements. See the Disclaimer for additional limitations.