Personal brand style guide.

Calm authority. Visible proof.

Frederick Nwokobia is presented as an experienced AI systems architect who understands the work behind the technology. The brand connects technical depth, commercial judgment, security discipline and hands-on delivery.

First person. Plainspoken. Specific.

Write like an experienced architect explaining a consequential decision to an intelligent stakeholder. Lead with the reader's problem or the system outcome. Keep technical terms only when they add precision.

Dark editorial canvas. One controlled accent.

All production color is applied through CSS custom properties. Ochre signals action, emphasis and engineering notation. It is not decoration. There are no gradients, glows or ornamental shadows.

Editorial presence. Engineering precision.

The font system carries most of the brand character. All fonts are self-hosted. Do not add a font CDN or introduce another type family.

Rules create order. Space creates confidence.

Pages use a 1140px maximum content width with fluid gutters. Sections breathe vertically. One-pixel rules, not floating boxes or effects, separate ideas.

Reuse the system. Do not decorate around it.

Visible labels. Low friction.

Forms use the shared input components, clear labels, precise hints and one obvious submission action. Placeholder text supplements a label; it never replaces one.

Show the work. Preserve the context.

• Portraits: merge into the page background through the established feathered treatment. Never place the portrait inside a visible frame.
• Products and systems: use real screenshots, diagrams or video frames that help the visitor understand what exists.
• Aspect ratio: paired media uses a consistent 16:9 frame and object-fit: contain when cropping would remove information.
• Illustration: diagrams must communicate a real relationship. Connectors meet their elements; labels stay inside their boundaries.
• Performance: prefer AVIF with a practical fallback, explicit dimensions and lazy loading below the fold.

Clarity is part of the architecture.

One argument. Real evidence. A useful next step.

Every essay should help a decision-maker understand a consequential systems question. The article is not a search-engine container or a product announcement. It begins with a clear position, earns that position through experience or inspectable evidence, and leaves the reader with something practical to consider or do.

Choose the editorial thread

Build the argument

1. Opening tension: begin with the decision, contradiction or operational problem—not a broad definition of AI.
2. Why it matters: connect the technical issue to cost, control, risk, delivery or the experience of the people doing the work.
3. Frederick's perspective: add relevant first-hand experience only when it genuinely supports the point.
4. Working model: explain the architecture, sequence, boundary or decision framework in plain language.
5. Evidence: use verified product behavior, cited primary sources, real screenshots or clearly identified examples. Never manufacture a result.
6. Practical close: give the reader one question, test or next action. A restrained invitation may follow.

A typical essay reads in 6–12 minutes, but the argument determines the length. Paragraphs should usually stay between one and four sentences. Use H2 headings to mark changes in the argument and H3 headings only when a section genuinely needs subdivision.

Create the source file

The editable source lives at content/<slug>.md. The slug is lowercase, descriptive and hyphenated. Frontmatter must contain every field below; the image path uses the same slug.

• Title: human and specific; avoid keyword lists, generic promises and title case applied mechanically.
• Excerpt: one or two sentences that work independently in the blog index and social preview. Do not simply repeat the headline.
• Date: publication date in ISO YYYY-MM-DD format.
• Read time: calculate from the final copy and round to a useful whole-minute estimate.
• Category: a plain-language label consistent with the four editorial threads.

Produce the public article

Create or regenerate blog/<slug>.html from the Markdown source using an existing article as the template. The repository does not currently include a committed generator command, so do not assume that changing Markdown alone updates the public page.

Editorial QA before publication

1. Verify every name, date, product fact, statistic, quotation and link against a primary source where possible.
2. Remove confidential infrastructure details, client-identifying facts, credentials, internal addresses and security-sensitive implementation detail.
3. Confirm that the headline, excerpt, metadata, card copy and article make the same promise.
4. Read the opening, every heading and the final paragraph as a standalone scan. They should still reveal the argument.
5. Check the rendered article at mobile and desktop widths, including tables, code, lists, images and long headings.
6. Verify the clean URL, blog-index card, social image, structured data and all internal and external links.

Every graphic must explain something.

The visual language is an editorial technical document: dark, structured, restrained and precise. Graphics support comprehension or provide credible proof. They are never abstract decoration added because a section feels empty.

Composition and safe areas

• Keep critical subjects, labels, connector endpoints and any essential text at least 8% inside every edge.
• Establish one dominant idea. Supporting elements should create an obvious reading order rather than compete for attention.
• Use a structural grid. Align boxes, headings and baselines; keep consistent internal padding and equal gaps between equivalent elements.
• Never let text touch, cross or visually crowd a border. Shorten the copy or increase the container before reducing legibility.
• Do not place a full article headline inside the cover by default—the page and social card already provide it.

Typography inside graphics

Diagrams and process graphics

Screenshots, video frames and evidence

• Use real interfaces or outputs when they strengthen credibility. Remove secrets, client data, private addresses, account identifiers and irrelevant browser chrome.
• Crop around the evidence while preserving enough context to understand what is being shown.
• Annotations use the approved accent, consistent line weight and precise endpoints. Do not cover the evidence being discussed.
• Video thumbnails must represent the actual film. Do not create a dramatic image that promises content the video does not contain.
• Every image receives concise alt text describing its informational purpose, not a list of visual details.

Graphic QA gate

1. Inspect the source at 100% for clipping, overflow, accidental seams and misaligned connectors.
2. Inspect it at its smallest real display size. The hierarchy and central idea must remain clear.
3. Test the 16:9 asset in the article hero and blog-index crop.
4. Test the social asset at 1200 × 630 and within a mobile preview.
5. Confirm fonts, colors, radius, line weights and spacing match this site—not the visual language of another property.
6. Reject the asset if any label touches a border, any connector floats, or any element overlaps unintentionally.

Make the change. Verify the whole system.

1. Reuse the shared header, footer, components and stylesheet.
2. Give every page a unique title, description, canonical URL and social metadata.
3. Use clean internal URLs without .html.
4. When shared CSS changes, bump its cache version on every page.
5. Test desktop and mobile layouts, keyboard access, form behavior and broken links.
6. Do not publish infrastructure detail, credentials, fabricated proof or unverified claims.
7. Commit, push, deploy with the safe helper and verify the live routes.