ProBizSystems Brand Guide

How to use this with a coding agent: point it at this Brand Guide and the live stylesheet. The CSS is the single source of truth for exact values; this page explains intent, components, and rules. New pages should reuse the existing classes below. Do not invent parallel styles.

Contents

1. Brand & personality

ProBizSystems is a founder-led AI practice built on 30 years of security and systems engineering. The brand is calm, precise, and credible: the opposite of hype. Think "the security architect's spec sheet," not "growth-hacking agency." Dark, technical, confident; never loud or salesy.

• Tagline: Secure AI systems, built around how you work.
• Core belief: technology should serve people; trust is earned through transparency; start small, think big.
• Aesthetic: deep navy canvas, a single violet→cyan accent gradient used sparingly, generous spacing, sharp typography.

2. Voice & tone

Do	Don't
Speak plainly and concretely. Short, confident sentences.	Buzzword stacks ("synergistic AI-powered solutions").
Be honest about limits: "sometimes the answer is 'not yet.'"	Overpromise, or imply a large team / long track record.
Lead with the customer's problem and time, not features.	Fear-marketing ("your competitors are crushing you").
Tie claims to the reader's own baseline and measurement.	Invented percentages presented as our results.
Use "we" as a founder-led practice; cite real credentials.	"Our team of experts" implying scale we don't have.

One accent word per heading gets the gradient (see typography). Everything else stays calm.

3. Content rules (read first)

These are hard rules. A build-time check (qa.py) fails the site if they're broken.

• No fabricated content. No invented testimonials, client names, case studies, logos, or statistics. There is no published phone number. Contact is the chat widget + info@probizsystems.com.
• No invented metrics. If you cite a number, frame it as an industry-typical range ("commonly reported," "in practice") and tie it to the reader's own baseline. Never present it as our measured track record.
• Verify before publishing names, credentials, and product facts. When unsure, leave it out and flag it.
• Founder-led framing. Attribute the practice to its real expertise; blog posts are bylined "ProBizSystems Team."
• Customer-facing only. Never publish internal pricing playbooks, financials, or client-acquisition tactics.

4. Color tokens

All color lives in CSS custom properties on :root in styles.css. Use the variables. Never hardcode hex. Values are OKLCH.

The gradient is the brand's signature. Use it only for: one word inside a heading (.grad-text), primary buttons, and the rare glow/orb. Overusing it cheapens it.

5. Typography

Style	Font and weight	Size and use
Display / H1	Sora 700	clamp(2.4rem, 5.5vw, 3.6rem). One page title only.
Section / H2	Sora 700	clamp(1.8rem, 3.6vw, 2.5rem). Primary section statements.
Card / H3	Sora 600	1.25rem. Card and subsection titles.
Body	DM Sans 400	1.0625rem / 1.65. Default paragraph and list copy.
Lead	DM Sans 400	1.15rem in --muted. One concise framing paragraph.
Kicker	Fira Code 500	0.8rem, uppercase with tracking. Section category only.
Tag / meta	Fira Code 400-500	0.72-0.85rem. Categories, dates, labels, and evidence metadata.
Button	Sora 600	0.95rem. Short, verb-led action labels.

Headings are tight (letter-spacing -0.015em) and balanced. Give one, and only one, meaningful phrase per major heading the gradient. Use sentence case, not title case, for editorial headings. Body text stays regular weight; use bold sparingly for a term or warning, never for whole blocks of explanatory copy.

<h2>AI That Understands <span class="grad-text">How You Work</span></h2>

6. Layout & spacing

.container	Max-width 1120px, auto-centered, 1.5rem side padding. Wrap every section's content in one.
.section	Vertical rhythm (clamp 4-6.5rem block padding). Every content block is a <section class="section">.
.section-alt	Add to alternate a section onto the slightly lighter --bg-alt with top/bottom hairlines. Alternate for contrast.
--radius	0.75rem: the standard corner radius for cards, inputs, images.

7. Buttons

<a class="btn btn-primary" href="...">Primary action</a>
<a class="btn btn-ghost" href="...">Secondary action</a>

One primary button per view. .btn-primary carries the gradient; .btn-ghost is the outlined secondary. Buttons are pill-shaped and lift slightly on hover.

8. Section structure

Most sections open with a .section-head: a mono .kicker, an h2 with one gradient word, and a .lede intro.

<section class="section">
  <div class="container">
    <div class="section-head">
      <span class="kicker">Our Approach</span>
      <h2>Why Work <span class="grad-text">With Us</span></h2>
      <p class="lede">A short intro in plain language.</p>
    </div>
    <!-- content -->
  </div>
</section>

9. Cards & grids

.grid auto-fits cards (min 15.5rem). Use .grid.grid-3 (min 18rem) when you have 5 or 8 items, so the last row doesn't orphan. A linkable card is <a class="card">; it lifts on hover.

<div class="grid grid-3">
  <div class="card">
    <span class="icon">◈</span>
    <h3>Card title</h3>
    <p>Supporting copy.</p>
  </div>
  <a class="card" href="...">
    <span class="tag">Tag</span>
    <h3>Linkable card</h3>
    <p>Supporting copy.</p>
    <span class="card-link">Learn more →</span>
  </a>
</div>

Icons are inline SVGs inside .icon, with a 24x24 viewBox, fill="none" stroke="currentColor" stroke-width="1.6", round caps/joins. No icon font, no sprite; copy an existing icon from index.html as the template.

Motion. /assets/site.js (loaded on every page) provides scroll reveals, the cursor-aware card glow, the scroll progress bar, and nav scrollspy. Reveals are opt-out safe: they gate on html.anim, set only when JS runs and prefers-reduced-motion is off, so content is never hidden otherwise. New elements matching .section-head, .card, .step, .cta-banner, .split > * animate automatically; don't add bespoke animation, and never animate misleading data (illustrative UI demos must be labeled as illustrations).

10. Other components

Kicker: a mono uppercase label with a leading dash:

Tag chip: small category pill:

FAQ: native <details> accordions, no JS:

<div class="faq">
  <details><summary>A question?</summary><p>The answer.</p></details>
</div>

CTA banner: gradient-bordered closing call to action:

Split: 50/50 text + image (.split, stacks under 880px). Steps: numbered process cards (.steps > .step, auto-numbered 01-0N). Partners strip: mono pills (.partners > span). Verified proof rail: .proof-section with a .proof-strip of .proof-item facts. Only use public, independently supportable credentials or product evidence.

11. Blog article design language

Blog posts should read like a security-minded builder explaining a practical decision. Start with the business tension, establish the operating or architectural principle, show how a team would apply it, name the tradeoffs, and close with a useful next step. Lead with proof and consequences before implementation detail.

Use	Avoid
Concrete titles that name the decision or problem.	Clickbait, vague trend pieces, or hype-led headlines.
Short paragraphs, descriptive H2s, examples, checklists, and tradeoffs.	Walls of text, repetitive summaries, and generic listicles.
Measured confidence and specific business risks.	Guarantees, fear marketing, or universal claims.
Capability categories and public-safe product names.	Internal infrastructure products, topology, versions, or counts.
ProBizSystems Team as the byline.	Invented authors, customers, quotations, or results.

Articles render inside .prose at a maximum width of 44rem. The generated page hero supplies the H1, so markdown begins with the article body and uses H2 and H3 headings. Links must explain their destination. Use blockquotes only for short, sourced material or a clearly identified principle, not for decorative pull quotes.

Use the established categories: AI Strategy, Guide, or Automation. Excerpts should be one or two calm sentences that state the practical value without repeating the title.

---
title: "Clear, Specific Article Title"
slug: clear-specific-article-title
date: Jul 14, 2026
readTime: 8 min read
category: ai-strategy
categoryLabel: AI Strategy
excerpt: "A concise explanation of the practical value."
image: blog-clear-specific-article-title.webp
featured: false
author: ProBizSystems Team
authorRole: ProBizSystems
---

12. Blog cover design language

Blog covers form one coherent editorial series. They are dark technical illustrations, not stock photography and not screenshots used as decoration.

• Canvas: 16:9, normally 1600×900 or larger.
• Palette: deep navy or near-black with controlled violet and cyan light.
• Subject: 3D or isometric systems, dashboards, network paths, security layers, model routes, recovery, or workspace modules.
• Lighting: crisp cinematic contrast, deep shadows, and one clear focal structure.
• Never include: embedded text, logos, watermarks, people, robot mascots, stock-office scenes, or generic photography.
• Delivery: local WebP with an optimized AVIF derivative. Do not add remote image dependencies.

13. Coding-agent workflow

1. Read the repository instructions first. Use AGENTS.md, DESIGN-SYSTEM.md, and the local probizsystems-site skill when the repository is available.
2. Edit the source of truth. Homepage and shared chrome live in site/index.html; services, articles, and content pages live under content/. Never publish the internal content/services/ records.
3. Reuse existing classes. Do not introduce a framework, remote font, stock-image dependency, or parallel component system.
4. Protect OpSec and honesty. Do not invent proof or expose internal products, versions, hostnames, topology, or infrastructure counts.
5. Build and verify. Run .venv/bin/python build.py, then .venv/bin/python qa.py. Both must pass before packaging or deployment.
6. Inspect the result. Check desktop and mobile layouts, keyboard focus, meaningful alt text, internal links, and any new image or media asset.

14. Building and publishing

1. Content pages (blog post, service, legal) are markdown in content/ and rendered by build.py. Add the file, run the generator, and a styled page with the right <head>, nav, footer, and JSON-LD is produced. Standard service pages use the focused prose layout; a priority service may use the full-width feature layout when it is built entirely from the established section, card, step, proof, FAQ, and CTA components. Internal links never include .html.
2. The homepage (site/index.html) is hand-maintained. Shared chrome (nav, footer) is extracted from it at build time, so edit chrome there once.
3. Every page needs a unique title, meta description, canonical, Open Graph tags, and the right JSON-LD (Organization on home, BlogPosting on posts, Service on services).
4. Reuse the classes above. If you need a new visual, add it to styles.css and bump the ?v= version on the stylesheet link. don't inline one-off styles or pull in a framework.
5. Run the checks. The build is only done when qa.py passes all eight gates, including link integrity, metadata, sitemap, honesty, public artifact hygiene, and reproducibility.

← Back to the site