KONTYRA Wiki Style Guide

Article Structure

Every article in the KONTYRA Wiki follows a consistent structure. This makes articles predictable for readers and easier to maintain over time.

Required elements

• Title — Clear, specific, and noun-led. "What is KONTYRA?" not "An Introduction to KONTYRA"
• Subtitle — One or two sentences that summarize what the reader will learn. Written in full sentences.
• Metadata row — Category tag, publication date, and estimated read time
• Table of Contents — Required for articles over 600 words. Links to each H2 heading.
• Body — The article content, structured with H2 and H3 headings

Optional elements

• Callout boxes — For status updates, warnings, or important notices that break flow if inline
• Blockquotes — For direct quotes from KONTYRA team members or foundational statements
• Code blocks — For technical content, CLI examples, or architecture diagrams in ASCII
• Article navigation — Previous / next links at the bottom of sequential articles

Standard closing

Every article ends with a horizontal rule followed by one or two sentences linking to related articles. This keeps readers in the wiki rather than bouncing to a dead end.

Heading Format

The KONTYRA Wiki uses three heading levels within article bodies:

• H1 — Article title only. One per page. Never used inside the article body.
• H2 — Major sections. These appear in the Table of Contents. Written in title case. Example: What This Looks Like in Practice
• H3 — Subsections within an H2 section. Written in sentence case. Example: Feedback loops are engineered first

H4 and below should not be used in wiki articles. If content requires that level of nesting, it is a signal that the section should be split into a separate article or moved to formal documentation at docs.kontyra.name.ng.

Heading anchors

Every H2 heading should have an id attribute for deep linking. The ID should be a lowercase, hyphenated version of the heading text. Example: id="heading-format"

Writing Style

KONTYRA Wiki articles are written to be read by intelligent, time-pressed people who want substance, not performance. The following principles govern style:

Be direct

Lead with the point. Avoid preamble. "DevOS is KONTYRA's developer operating system" is better than "In this article, we will explore KONTYRA's flagship product, DevOS, which is a developer operating system."

Be specific

Vague language is a sign that thinking is incomplete. "DevOS makes software development better" says nothing. "DevOS maintains a continuous model of your software's behavior, updated in real time as code changes" says something.

Avoid hype

KONTYRA products are in development. Articles should be honest about status, limitations, and what is not yet known. Hype erodes trust and makes the wiki less useful over time.

Use "we" sparingly

Wiki articles are primarily third-person and informational, not first-person company communications. "We" is acceptable in philosophy and vision articles but should be avoided in product descriptions and technical documentation.

Read time

Estimate read time at 200 words per minute. Round up to the nearest minute. A 1,200-word article is a 6-minute read.

Citation Rules

KONTYRA Wiki articles should be citable and verifiable. The following citation principles apply:

Internal references

Link to other wiki articles by name using standard anchor links. Example: See What is KONTYRA? for background. Do not use bare URLs for internal links.

External references

External links should open in the same tab (the default). Do not use target="_blank" without a specific reason. When referencing external research, papers, or publications, include the author, title, and year in the text. Example: Smith et al. (2024) found that…

Statements of fact vs. opinion

Distinguish between factual claims and KONTYRA's perspective. "DevOS is in active development" is a fact. "The fragmentation of developer tooling is the core problem DevOS solves" is KONTYRA's assessment — and should be written as such.

Status claims

Any claim about a product's status (availability, roadmap position, capabilities) must be accurate at the time of writing and should include the article's publication date so readers can calibrate how current the information is.

Naming Conventions

File naming

Article files use lowercase, hyphenated names. No spaces, no underscores, no uppercase.

• Correct: what-is-kontyra.html
• Incorrect: What_Is_Kontyra.html, WhatIsKontyra.html

URL structure

• Articles: /articles/article-name.html
• Product pages: /products.html#product-name or /products/product-name.html
• Research: /research/paper-name.html
• Documentation: managed at docs.kontyra.name.ng

Product names

KONTYRA product names are always written exactly as follows:

• DevOS — not "devos", "Dev OS", or "Dev-OS"
• MatGuru — not "MatGURU" or "Matguru"
• EconCLI — not "Econ CLI" or "econcli"
• Trust API — two words, not "TrustAPI" or "trustapi"

Company name

KONTYRA is always written in full caps. Never "Kontyra" or "kontyra".

Article Categories

Every article must be tagged with exactly one primary category:

• Foundation — Articles about KONTYRA's history, mission, and core identity
• Vision — Articles about philosophy, long-term thinking, and strategic direction
• Product — Articles about specific KONTYRA products
• Research — Articles summarizing or presenting original KONTYRA research
• Architecture — Articles about system design and engineering architecture
• Reference — Style guides, glossaries, and reference documents (like this article)

What Belongs Here vs. docs.kontyra.name.ng

The KONTYRA Wiki and the formal documentation site serve different purposes and should not overlap:

When in doubt: if someone needs to build something, it belongs in docs. If someone needs to understand something, it belongs in the wiki.

---

Questions about these conventions can be raised in the KONTYRA internal channels. The style guide will be updated as new content types emerge and as the wiki grows. See the homepage for the latest articles and product information.