๐Ÿ“– Qalarc Blog โ€” Publish Protocol

Last updated: April 2026 ยท This is the internal guide for writing, reviewing, and publishing all blog posts.

The Publish Workflow

Step 1

Draft (readiness 0โ€“40%)

The post exists in the data store with source files referenced. Either raw notes exist, or sub-agents have been briefed. No polish yet.

  • Check that source files are referenced in posts-data.js
  • Identify any credentials or sensitive info in source files before reading
  • Flag which claims need citation
Step 2

Write Both Versions (readiness 40โ€“70%)

Every post exists in two versions: Technical (for developers, researchers, engineers) and Plain English (for anyone curious, no background assumed).

  • Technical: include real numbers, code snippets, architecture decisions, citations
  • Layman: use analogies, no jargon, explain why it matters to a non-expert
  • Both versions must be honest โ€” no overselling, no hiding limitations
  • Both versions must link to each other via the version toggle
Step 3

Reference Vetting (required before readiness > 70%)

Every factual claim must be traceable. See the Vetting section below.

  • All academic claims cite author, year, venue
  • All accuracy/performance numbers verified against source data
  • Limitations stated explicitly alongside achievements
  • No claims made about future plans as if they are current reality
Step 4

Self-Review Using This System (readiness 70โ€“90%)

Use the vote/comment system on this blog to review your own posts before marking them published.

  • Read the post as if you'd never worked on the project
  • Use "๐Ÿ” Fact Check" comment type for claims you're unsure about
  • Use "๐Ÿ”ง Needs Fix" for structural issues
  • Use "โ“ Question" for things that need follow-up before publish
  • Only vote ๐Ÿ‘ Approve when all Fact Check and Needs Fix comments are resolved
Step 5

Answer Pending Questions (required for publish)

Each post in posts-data.js has a pendingQuestions array. Every item must be resolved before the post can go from needs-review to published.

  • Update pendingQuestions to [] when all resolved
  • Change status to 'published' in posts-data.js
  • Update readiness to reflect actual state
Step 6 โ€” Future

Push to qalarc.com

When a post is approved (status: published, ๐Ÿ‘ voted, no open pending questions), it's ready for the live site. The online system will be built separately and will consume this same posts-data.js structure.

Reference Vetting Rules

Academic Claims

  • Format: Author et al., Year, Venue โ€” e.g. "Karkkainen & Joo, WACV 2021"
  • Include dataset license where applicable (CC BY 4.0, MIT, etc.)
  • If citing a benchmark number, specify which split (train/val/test) and which metric
  • If reproducing a result, state exactly what hardware/config you used

Performance Numbers

  • Always include the baseline/comparison: "71% vs 14% random baseline vs 72.2% academic SOTA"
  • Always state the conditions: hardware, dataset split, lighting, distance, etc.
  • If a number is theoretical or estimated, say so explicitly
  • Never round numbers up. Round down or state exact.

Sensitive Research (e.g. 4chan analysis)

  • State the research question clearly upfront
  • Describe data collection methodology and any ethical review
  • Do not publish aggregate statistics that could identify individuals
  • Frame findings with appropriate academic caution
  • Get a second read before publishing anything in this category

Standard Questions โ€” Every Post Must Answer

The 7 Questions

  • 1. What is this? One sentence. No jargon in the layman version.
  • 2. Why does it exist? What problem was being solved? What was the motivation?
  • 3. What makes it distinctive? What is genuinely novel or unusual about the approach?
  • 4. Does it actually work? What are the real numbers? What doesn't work yet?
  • 5. What are the limitations? Be honest. Readers trust posts that acknowledge limitations.
  • 6. What does this connect to? How does it link to other projects? What's the broader context?
  • 7. What's next? What's the current status and what would make this better?

Category Guide

AI Vision

Projects involving computer vision, face tracking, gesture recognition, or camera-based analysis. Includes demographic analysis, biomarker detection, gesture engines, and the smart glasses project.

Hardware

Physical builds, reverse engineering, RF/SDR work, wearables. Robot hand, HackRF, Colmi ring.

AI Systems

Operating systems, orchestration, memory architectures, voice interfaces. QalarcOS, gmux, mempalace, voice control, AI orchestrator.

Health & Biomarkers

Camera-based health measurement, rPPG, wearable integrations, health analytics platforms.

Games & Experiments

Interactive experiments, gesture-controlled games, creative coding. Castle Defense, gesture control effects.

Data & Research

Scraping, analysis, quantitative research. Requires extra ethical care before publishing.

Retrospectives

Hackathon write-ups, project post-mortems, lessons learned.

Technical vs Plain English โ€” The Difference

Technical Version

  • Target reader: developer, researcher, engineer who wants the real implementation details
  • Include: architecture decisions, code snippets, benchmark numbers, paper citations, model sizes, latency measurements
  • Explain trade-offs in technical terms: "INT8 quantisation reduces model size by 8x at a cost of 1.2% accuracy"
  • Link to: GitHub repos, papers, datasets

Plain English Version

  • Target reader: curious non-technical person, journalist, potential collaborator, investor
  • No acronyms without explanation. No assumed knowledge.
  • Use analogies: "The model is smaller than most photo files on your phone"
  • Still honest about limitations โ€” don't oversell for the lay audience
  • Focus on: why it exists, what it does, why it's interesting, what the limitations are
  • Shorter: aim for 60โ€“70% of the word count of the technical version

Going Online โ€” Future Steps

When a post is ready to publish live:

  • Status in posts-data.js must be 'published'
  • Vote must be ๐Ÿ‘ (approved)
  • All pendingQuestions must be resolved (empty array)
  • readiness must be โ‰ฅ 85
  • Both technical and layman versions must exist
  • All credentials/secrets verified as NOT present in the post content

The online publish system will:

  • Read from the same posts-data.js
  • Deploy to qalarc.com/blog via Cloudflare Pages
  • Include sitemap.xml and robots.txt for search indexing
  • Support og:image and structured data for social sharing
  • Link back to project pages on qalarc.ai
  • Comments will migrate to a server-side solution (TBD: Cloudflare D1 or Giscus)