David Duncan's Personal Blog - Technology

A Molokai Palette for the Gum Pelican Theme

2026-05-30T09:30:00-05:00

This blog has been running on Pelican’s default notmyidea theme for a long time. It works, but the look is dated and there was no way to take real control of layout or navigation without forking the theme. I wanted three things: a real templated theme (so I can change structure later), a layout that actually surfaces a sidebar, and a color scheme I’d enjoy looking at. Molokai has been my editor palette for years, so that was the destination.

The result is what you’re looking at now: the gum theme from getpelican/pelican-themes, with two small upstream fixes and a Molokai overlay applied as a CUSTOM_CSS_FILES layer. No theme fork required.

Why gum

Gum is one of the older community themes in getpelican/pelican-themes. It uses the (now-archived) Gumby Framework for its 12-column grid, and it ships with jQuery 1.9.1 + Modernizr 2.6.2, so it is showing its age. What it has going for it is honest structure: a base.html, real Jinja2 templates for index, article, page, archives, tags, categories, and a sidebar — all in plain HTML you can read in an afternoon. That makes it a good starting point for someone who plans to edit the templates themselves rather than treat the theme as a closed box.

The sidebar wasn’t showing

The first thing I noticed after switching was that gum’s sidebar didn’t render beside the content. It rendered, just not where you’d expect. The cause turned out to be a simple math mistake in the upstream templates:

<!-- theme-gum/templates/index.html -->
<div class="row">
    <div class="eleven columns">      <!-- 11 -->
        ... article list ...
    </div>
    {% include 'sidebar.html' %}      <!-- includes a "three columns" div -->
</div>

The sidebar is a three columns div. 11 + 3 = 14, which overflows Gumby’s 12-column grid, so the sidebar wraps below the content instead of sitting next to it. The fix is to make the content area nine columns so 9 + 3 = 12 fits cleanly. The same fix applies to article.html.

After that the sidebar shows up exactly where it was always meant to — categories, social links, the lot.

Code highlighting: regenerate `pygment.css` with `.highlight` scoping

Pelican’s markdown extension wraps code blocks in a .highlight div. Gum’s bundled pygment.css uses no parent class prefix, which means its rules apply to any .c, .k, .s token on the page — not just inside code blocks. That’s the kind of scoping bug that explodes in subtle ways once you write inline markdown that happens to contain those class names.

The fix is one shell command. Pygments ships with a built-in monokai style — the canonical syntax-highlighting form of Molokai:

pygmentize -S monokai -f html -a .highlight > theme-gum/static/pygment.css

The -a .highlight flag prefixes every rule with .highlight, so the colors only apply inside actual code blocks. Drop-in replacement.

The site palette: a CUSTOM_CSS_FILES overlay

For the rest of the site I didn’t want to edit gum’s style.css or gumby.css directly. Editing the theme’s own CSS means every future change is a merge conflict with upstream, and it muddies what’s structural vs. what’s cosmetic. Gum exposes a much cleaner hook: the CUSTOM_CSS_FILES setting. Any path listed there is loaded after the theme’s own CSS, so the last definition wins.

The strategy:

Keep gumby.css, style.css, and pygment.css exactly as gum ships them (modulo the .highlight regeneration above).
Drop one new file — molokai.css — into theme-gum/static/.
Tell pelicanconf.py to load it via CUSTOM_CSS_FILES.

# pelicanconf.py
THEME = 'theme-gum'
PLUGIN_PATHS = ['plugins']

CUSTOM_CSS_FILES = ['theme/molokai.css']

The file lives at theme-gum/static/molokai.css, which Pelican copies to output/theme/molokai.css — hence the relative path theme/molokai.css in the setting.

The overlay itself

The full Molokai palette goes in as CSS custom properties, then a small set of selectors maps them to gum’s actual structure:

:root {
  --molokai-bg:        #272822;
  --molokai-bg-soft:   #3e3d32;
  --molokai-bg-deep:   #1b1d1e;
  --molokai-fg:        #f8f8f2;
  --molokai-comment:   #75715e;
  --molokai-red:       #f92672;
  --molokai-orange:    #fd971f;
  --molokai-yellow:    #e6db74;
  --molokai-green:     #a6e22e;
  --molokai-cyan:      #66d9ef;
  --molokai-purple:    #ae81ff;
}

html, body {
  background-color: var(--molokai-bg);
  color: var(--molokai-fg);
}

#banner h1 a            { color: var(--molokai-cyan); }
#banner h1 a strong     { color: var(--molokai-orange); font-weight: normal; }

#navigation             { background-color: var(--molokai-bg-deep); }
#navigation ul li a     { color: var(--molokai-fg); }
#navigation ul li a:hover,
#navigation ul li.active a { color: var(--molokai-green); }

a                       { color: var(--molokai-cyan); }
a:hover                 { color: var(--molokai-green); }

.entry-title,
.entry-title a          { color: var(--molokai-cyan); }
.entry-title a:hover    { color: var(--molokai-green); }

.three.columns h4       { color: var(--molokai-red); }
.three.columns ul li a  { color: var(--molokai-cyan); }

.btn, .btn.primary      { background-color: var(--molokai-cyan) !important;
                          color: var(--molokai-bg) !important; }
.btn:hover              { background-color: var(--molokai-green) !important; }

.tag-row .label,
.label.danger           { background-color: var(--molokai-orange) !important;
                          color: var(--molokai-bg) !important; }

code                    { background-color: var(--molokai-bg-soft);
                          color: var(--molokai-orange); }

.highlight              { background-color: var(--molokai-bg-deep) !important;
                          border: 1px solid var(--molokai-bg-soft); }

blockquote              { border-left: 3px solid var(--molokai-purple);
                          background-color: var(--molokai-bg-soft); }

table th                { background-color: var(--molokai-bg-soft);
                          color: var(--molokai-yellow); }

::selection             { background: var(--molokai-yellow);
                          color: var(--molokai-bg); }

footer#credits          { background-color: var(--molokai-bg-deep);
                          color: var(--molokai-comment); }

A handful of !important flags survive in there because gum’s gumby.css sets a few colors at high specificity on .btn variants and label classes. Those are the friction points; everything else flows from the palette variables.

What it costs

I want to be honest about the tradeoffs. Gum is old enough that it carries some weight you’d think twice about on a green-field theme:

jQuery 1.9.1 (2013) and Modernizr 2.6.2 (2013) are loaded on every page. The site doesn’t actually need them.
Gumby Framework is archived. The 12-column grid still works; I just can’t lean on the upstream for fixes.
The bundled icon font (Entypo) is mostly unused.

For a personal blog with six articles, none of that matters yet. If I later want a leaner JS footprint, I’ll strip those scripts out of base.html as a separate change — but the Molokai work doesn’t depend on it.

Making it reusable

The molokai.css file in this post is a drop-in for anyone running the gum theme. Copy it into theme-gum/static/molokai.css, set CUSTOM_CSS_FILES = ['theme/molokai.css'] in your pelicanconf.py, and you’re done. The two upstream fixes (the column-grid math and the regenerated pygment.css) are independent of the palette and worth applying even if you’d rather pick a different color scheme.

The full bundle — gum templates with the column fix, the regenerated pygment.css, and molokai.css — is published as a standalone theme repo at gitlab.com/rubackedup-com/pelican-theme-gum-molokai. MIT licensed, same as upstream gum. Clone it as your theme-gum/ and you’re done in two lines of config.

What’s next on this blog

This is the first commit on a longer theme-refresh branch. Next on the list:

Untrack output/ and __pycache__/ (legacy committed build artifacts)
Drop gum’s empty Pages heading in the sidebar when there are no pages
Add OpenGraph and Twitter Card meta to base.html so link previews stop looking awful
Decide whether to strip the jQuery/Gumby JS payload

None of those block the Molokai work, which is what I cared about most.

falcon-stats: A Trading Discipline System Built on PAI

2026-04-27T18:00:00-05:00

falcon-stats: A Trading Discipline System Built on PAI

I have been day trading for about 13 months. In that time I have taken 1,254 round-trips across 187 different stocks. And until two weeks ago, I had no idea what my actual numbers looked like.

Now I do. I built a system to tell me, and the answer was uncomfortable: I am running a negative expectancy of -0.79R per trade on average, despite winning 51% of my trading days.

Here is the thing — that is not a stock-picking problem. I win more days than I lose. The problem is behavioral: my average red day is 2.5 times the size of my average green day. I size up when I should size down. I grind 24 round-trips on AMD when I should take one clean setup and walk away.

I am a winning trader with a losing habit. And now I have the data to prove it.

What falcon-stats Does

falcon-stats is a Python package that turns your DAS Trader exports and broker statements into honest, unflinching self-assessment. It is built on Daniel Miessler‘s PAI (Personal AI Infrastructure) framework, and it uses TELOS — the life operating system from PAI — to connect your trading performance to your personal goals, challenges, and strategies.

Here is what it does:

Ingests your trades. It reads DAS Trader CSV exports and Cobra Trading broker Excel statements, groups individual executions into round-trips (handling scaling in, partial fills, and multiple positions per symbol per day), and computes R-multiples from your planned stops.

Calculates your real numbers. Win rate, expectancy, profit factor, max drawdown, R-multiple distribution, and streak tracking. Not from a sample of your best days — from every trade you have ever taken.

Scores your discipline. Each trading day gets a discipline score from 1 to 10 based on trade count, R-asymmetry (are your winners bigger than your losers?), and process adherence. Green means you traded well (7 or higher). Red means you did not. The color has nothing to do with whether you made money.

Identifies your patterns. Which tickers are you trading the most? Which ones are costing you money despite high win rates? My data showed that AMD — a stock I win 69% of the time — has a deeply negative R-expectancy because the 31% I lose are five times bigger than the 69% I win. AMD is now banned from my live account until I prove edge in simulation.

Runs statistical covariance. Before I trade any stock, I pull 90 days of daily price data from Polygon and calculate the z-score — how far the current price is from its 20-day mean in standard deviations. Stocks in normal range get my Fashionably Late long setups. Stocks at statistical extremes get Offsides short setups. The math tells me which direction to trade instead of my gut.

Estimates costs. A trade cost calculator uses my actual Cobra broker fee data from 847 executions to estimate commissions, ECN fees, SEC fees, and breakeven move for any planned trade. Spoiler: fees are negligible relative to the R-multiple on most trades. The problem is not costs. It is behavior.

The Architecture

DynamoDB is the source of truth for all trading data. Not Notion. Not a spreadsheet. DynamoDB.

I learned this the hard way when I accidentally deleted my Notion databases. If your source of truth is a SaaS product you do not control, you do not have a source of truth. Now Notion is a rebuildable view — if it disappears, I recreate it from DynamoDB in minutes.

DAS CSV --> falcon-stats --> DynamoDB (source of truth)
                                |
                                +-> Notion (rebuildable view)
                                +-> Slack (discipline posts)
                                +-> Substrate (historical CSV)

The system is designed with extension points. If you use Interactive Brokers instead of Cobra, you write one parser class. If you prefer PostgreSQL over DynamoDB, you implement one database interface. Notion, Obsidian, plain markdown — swap the publisher. The core engine does not care where the data comes from or where it goes.

How PAI and TELOS Make This Work

falcon-stats is not just a statistics engine. It is integrated into a complete Personal AI Infrastructure that includes:

Morning Game Plans. Every trading day at 4:30 AM, an automated agent scans pre-market gappers, calculates z-scores, filters for my account size, and publishes a watchlist to Notion and Slack with specific Fashionably Late and Offsides Reversal entry scenarios. I wake up to a game plan I did not have to build manually.

Daily Reviews. After each session, I ingest my trades and get a discipline-graded report card. Did I follow the game plan? Did I honor stops? Did I trade outside my restriction list? The system knows my active behavioral challenges (revenge trading, inverse sizing) and checks for them.

Weekly Readiness Reviews. Every Sunday evening, the system pulls previous week earnings results, coming week catalysts, YouTube intel from my trusted channels, Substrate macro data, and my personal trading statistics. It publishes a strategic prep document with chart walkthrough narratives that I can record as video content.

TELOS Integration. My trading goals, challenges, strategies, and lessons learned are all tracked in TELOS — PAI’s life operating system. When I discover that my top 5 losing tickers account for 79% of my total losses, that lesson gets captured in TELOS and referenced in every future game plan. The system learns because I learn.

The Philosophy: P&L Over Price Action

I was trading 24 round-trips on AMD in a single session with a 64% win rate and still losing money. My AI partner said something that changed my thinking: “You are watching the price action instead of managing your P&L. Focus on the R-multiple you are capturing, not the number of trades you are taking.”

One trade at 2R is worth more than twenty trades at 0.1R. The math is simple:

One trade per day targeting 2R with a 50% win rate = +0.5R expected value per trade
That flips the expectancy from -0.79R to +0.5R per trade
Over 20 trading days per month, the R-curve goes from declining to compounding

The entire system — the covariance analysis, the discipline scoring, the restriction list, the one-trade commitment — exists to enforce this insight. Order flow first, then price action, but always manage to the P&L. Fewer trades, better R-multiples.

Who This Is For

This is specifically built for DAS Trader and Cobra Trading customers who are willing to store their data in DynamoDB. That is a narrow audience. But the architecture is modular — with a little work, you can adapt it to Interactive Brokers, TWS Gateway, or any broker that exports trade data. You can swap DynamoDB for Google BigTable, PostgreSQL, or SQLite.

More broadly, this is for anyone in Daniel’s PAI community who wants to see how TELOS and PAI can be applied to a performance discipline. The pattern works for trading, but it works for anything that requires deliberate practice and honest self-assessment.

If you want to share your progress with a mentor, a coach, or a prospective employer, this system produces the documentation automatically. The discipline scores, the statistical analysis, the data-backed strategy evolution — it is all there, updated daily, backed by real data.

Getting Started

The repository is at github.com/davdunc/falcon-stats. The README has setup instructions for DAS Trader + Cobra + AWS.

If you are using PAI, the Trading skill templates are designed to drop into your ~/.claude/skills/ directory. Customize the playbook setups, add your own YouTube channels, set your account size constraints, and the system adapts to your trading.

Acknowledgments

This system would not exist without Daniel Miessler‘s PAI framework. The Algorithm, the skill system, TELOS, the memory architecture — Daniel designed all of it and open-sourced it generously. I forked it and rebuilt it for my own mission, and now I am sharing what I built on top of it.

Thanks also to James Diamont for the coaching that helped me see the patterns in my trading before the data confirmed them. And to the SMB Capital team, whose PlayBook methodology and Fashionably Late / Offsides scalp frameworks gave me the specific setups to build a systematic approach around.

The numbers are not where I want them yet. But for the first time, I can see exactly what needs to change, I have the tools to measure whether it is working, and I have an AI partner that remembers everything and never lets me pretend the data says something it does not.

David Duncan is a momentum trader, Fedora Cloud SIG contributor, and builder of AI-assisted trading infrastructure at davidduncan.org. The falcon-stats source code is available at github.com/davdunc/falcon-stats.

Building a Bookmap-Style CVD Indicator with Claude Code and Python

2026-04-18T07:00:00-05:00

Building a Bookmap-Style CVD Indicator with Claude Code and Python

I had a conversation recently with prahko from SMB Capital about building order flow visualization tools. He built a Cumulative Volume Delta (CVD) widget using the IBKR TWS Gateway, and it got me thinking: why am I paying for Bookmap when I could build exactly the indicator I need, tuned to my trading style, using tools I already have?

What CVD Actually Is

Cumulative Volume Delta is one of the clearest windows into market microstructure. The concept is simple: for every trade that executes, classify it as buying pressure (executed at the ask) or selling pressure (executed at the bid). Accumulate the difference over time.

CVD = cumulative_sum(buy_volume - sell_volume)

When CVD trends up, aggressive buyers are in control. When it trends down, sellers are dominant. The divergences between CVD and price are where the real edge lives — price making new highs while CVD makes lower highs signals exhaustion. That is the kind of systematic, quantifiable signal that appeals to me as a trader moving toward algorithmic execution.

The Data Pipeline

I already have the pieces. My Falcon trading platform includes a headless Interactive Brokers gateway, and the IBKR TWS API provides tick-by-tick trade data with aggressor side classification. The architecture would be:

IBKR TWS Gateway
    |
    v
Python (ib_async) — reqTickByTickData("AllLast")
    |  classify: executed at ask = buy, at bid = sell
    |  compute: CVD = cumsum(buy_vol - sell_vol)
    v
FastAPI + WebSocket (/ws/cvd)
    |
    v
Browser widget (compact, embeddable)

The Python layer handles the computation. A lightweight WebSocket endpoint pushes updates to a browser-based chart. The question is what to render with.

Choosing a Visualization Library

I researched several options for rendering compact, real-time financial charts. Here is what I found.

D3.js — Maximum Flexibility, Maximum Effort

D3 is the Swiss army knife of data visualization. You can build literally anything. The problem is you have to build literally everything. For a single-purpose CVD widget, D3 is the wrong tool — its learning curve and manual update management are not justified when purpose-built financial charting libraries exist. The d3fc financial components library helps, but it is still fundamentally a general-purpose framework.

Verdict: Skip for this use case.

Lightweight Charts (TradingView) — The Sweet Spot

TradingView open-sourced their charting library under Apache 2.0. It is purpose-built for compact financial chart embeds at under 50KB gzipped. The API is familiar to anyone who has used TradingView, and it includes a Custom Series plugin API that supports building a CVD renderer with custom Canvas drawing.

The update() method handles real-time data pushes efficiently, and the look and feel is professional out of the box. For a CVD line chart alongside price, this is the natural choice.

Verdict: Production widget. Best balance of capability, size, and polish.

Plotly and Dash — Python-Native Prototyping

Dash lets you build the entire visualization in Python without touching JavaScript. Use dcc.Graph with dcc.Interval for periodic refresh. This is the fastest path to validating the indicator logic and data pipeline from IBKR.

The limitation is performance — Dash callbacks add latency, and Plotly.js weighs about 3MB. It will not handle sub-second updates smoothly. But for proving the concept in an afternoon, nothing is faster.

Verdict: Prototype only. Validate the math, then move to Lightweight Charts.

uPlot — Raw Performance

At 45KB, uPlot is the smallest and fastest open-source charting option. It handles 60fps streaming at 10 percent CPU. If Lightweight Charts cannot keep up with 1000+ ticks per second rendering, uPlot is the fallback. The tradeoff is a more utilitarian look and sparser documentation.

Verdict: Performance fallback if needed.

SciChart.js — Enterprise Grade

SciChart uses WebGL and WebAssembly to render 40 million data points per second. This is what you would use if building a full Bookmap-style Level 2 heatmap alongside CVD. For just a CVD line, it is overkill — and the commercial license starts at $500 per year.

Verdict: Only if building the full heatmap.

What Makes Bookmap Special

Bookmap itself is a Java and OpenGL application rendering at 40 FPS. Its technical moat is not the CVD indicator — that is a simple cumulative sum. The moat is the full Level 2 order book heatmap with historical replay, which requires ingesting and rendering millions of price-level updates per second. Color intensity maps to limit order depth: red and orange for high liquidity, blue and green for low.

For a standalone CVD widget, I do not need anywhere near that complexity. A cumulative line chart with divergence markers against price is sufficient to capture the signal I am looking for.

Where Claude Fits In

This is the kind of project where having an AI development partner changes the economics. Claude Code is effective at iterating on Lightweight Charts plugins because the API surface is small enough to fit in context, the Custom Series interface is a well-defined contract, and you can test changes by refreshing a single HTML file.

The pattern I have been using: describe the visual I want, let Claude generate the plugin class and HTML harness, then iterate on rendering details. The feedback loop is minutes, not hours. For a systematic trader who wants custom indicators without becoming a full-time frontend developer, this is the right approach.

Next Steps

Prototype — Python CVD computation from IBKR tick data using Plotly and Dash. Validate the math against known CVD implementations.
Widget — Lightweight Charts Custom Series plugin for the CVD line. Compact, embeddable, real-time via WebSocket.
Integration — Wire into the Falcon platform alongside the morning game plan pipeline and trading log.

The goal is not to rebuild Bookmap. It is to build the specific order flow indicator I need, own the data pipeline end to end, and have a tool that evolves with my trading — because I built it.

David Duncan is a momentum trader, Fedora Cloud SIG contributor, and builder of AI-assisted trading infrastructure at davidduncan.org.

PAI Framework: How I Rebuilt a Personal AI Infrastructure for Trading and Cloud Work

2026-04-16T16:30:00-05:00

PAI Framework: How I Rebuilt a Personal AI Infrastructure for Trading and Cloud Work

A few months ago I discovered PAI — Personal AI Infrastructure — an open-source framework built by Daniel that turns Claude Code into a persistent, skill-based AI system. I forked it and have been rebuilding it around my own mission ever since.

My fork: github.com/davdunc/pai-framework

What Drew Me to PAI

I was already using Claude Code daily, but every conversation started from scratch. No memory of what I was working on, what I had tried before, or what I had learned. PAI solved that with an architecture I immediately respected:

The Algorithm — A structured 7-phase execution framework (Observe, Think, Plan, Build, Execute, Verify, Learn) that produces verifiable outcomes. Every task generates Ideal State Criteria and tracks progress. This alone changed how I approach complex work.
Skills — Modular capability packages with workflows and routing logic.
Hooks — Lifecycle event handlers that fire on tool use, session events, and context management.
Memory — A persistent file-based system that carries context across conversations.
TELOS — A life operating system for goals, projects, and challenges that personalizes every interaction.

Daniel open-sourced all of this. I am grateful for the work and the generosity of sharing it.

How I Made It Mine

The original PAI had skills for OSINT investigations, security pentesting, visual content creation, and podcast editing. None of that is my work. I stripped it down and rebuilt around three pillars:

Systematic Trading (Primary Mission) I am working toward consistent profitability as a momentum day trader, with a goal of transitioning to fully systematic, algorithmic execution. PAI now powers my morning game plans, market research, trade review, and discipline tracking. I am building a platform called Falcon that bridges DAS Trader with Python automation — and PAI is becoming the intelligence layer.

Fedora Cloud SIG (Community Work) I contribute to Fedora Cloud images and bootable containers. PAI helps me manage community coordination, technical documentation, and release preparation.

The Bridge Between Them Falcon validates cloud-native infrastructure patterns (Podman, Quadlets, bootable containers) while simultaneously generating trading income. The infrastructure work proves the OS patterns. The trading funds the time for community work.

What the Fork Looks Like

I audited every component against my actual needs:

Kept: Trading, Research, Thinking (FirstPrinciples, Council debates), TELOS, Agents, Economic Metrics, and core utilities
Archived: 10 skills and sub-skills that served someone else s mission
Added: PreCompact hooks for context preservation, Elicitation hooks for MCP automation, mandatory prerequisite checks in the Algorithm
Building next: FedoraCloud skill, Falcon platform skill, DAS Trader CMD API integration

The result is a leaner system that routes more accurately to what I actually do.

What I Have Learned

The most valuable thing about PAI is not the code — it is the philosophy. The idea that your AI assistant should know who you are, what you are working toward, and what you have learned from past mistakes. My PAI knows my trading rules, my risk tolerance, my behavioral patterns I am trying to fix, and my long-term goals. That context makes every interaction more useful than starting from zero.

I am also learning that the best tools for a systematic trader are not the same as the best tools for a discretionary one. My PAI is evolving toward quantitative approaches — backtested setups, algorithmic execution, math-grounded decisions. That is the trader I want to become, and having an AI partner that remembers that aspiration helps me stay on track.

Try It Yourself

If you use Claude Code and want persistent context:

Check out Daniel s original work or my fork
Copy the framework to ~/.claude/
Create your own PAI/USER/ directory with your goals and projects
Start a conversation — the mode system kicks in automatically

The framework is a starting point. The value comes from making it yours.

David Duncan is a momentum trader, Fedora Cloud SIG contributor, and builder of AI-assisted infrastructure at davidduncan.org.

Introducing The Consilium: A Personal AI Advisory System

2025-08-06T12:00:00-05:00

Introducing The Consilium: A Personal AI Advisory System

Update: GitLab CI/CD pipeline now configured for automated deployments with IAM roles! 🚀

I’m embarking on what might be my most interesting personal project yet: building “The Consilium” - a multi-agent AI advisory system that acts as my personal council of specialists. Think of it as having a team of AI advisors, each expert in different aspects of life management.

Why “The Consilium”?

The name comes from the Latin term for an advisory council - historically used by Roman emperors for their trusted advisors. It perfectly captures what I’m building: a council of AI agents, each specialized in different domains of personal life.

The Agent Council

My planned specialists include:

Financial Advisor: Insurance policies, housing decisions, investment tracking
Location Intelligence: Neighborhood data, local services, property values
Travel Coordinator: Flight tracking, travel planning, loyalty program optimization
Environmental Monitor: Weather patterns, seasonal planning, local conditions
Health & Wellness: Appointment scheduling, health metrics, preventive care reminders
Master Coordinator: Routes queries between agents and synthesizes comprehensive responses

Technical Philosophy: Frugal over Fast

This isn’t about bleeding-edge performance or enterprise-scale infrastructure. It’s about building cost-effective, privacy-first personal AI infrastructure:

Key Design Principles

Local Model Serving: Using ramalama on Fedora instances for cost control
AWS us-east-2: Keeping costs low by avoiding premium regions
Red Hat Ansible: Infrastructure as code for reproducibility and documentation
Spot Instances: Targeting 60-90% cost savings over on-demand pricing
Privacy-First: All processing happens on my own AWS infrastructure

Estimated Costs

Phase 1 (Single Instance): $15-30/month
Phase 2 (Full Council): $50-80/month with Spot instances
Data & Storage: $5-10/month for logs and model caching

The Architecture Vision

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Financial     │    │    Location     │    │     Travel      │
│    Advisor      │    │  Intelligence   │    │  Coordinator    │
│                 │    │                 │    │                 │
│  ramalama +     │    │  ramalama +     │    │  ramalama +     │
│  Llama 3.2 3B   │    │  Llama 3.2 3B   │    │  Llama 3.2 3B   │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌─────────────────┐
                    │     Master      │
                    │  Coordinator    │
                    │                 │
                    │  Query Router   │
                    │  & Synthesizer  │
                    └─────────────────┘

Why Build This?

Personal AI infrastructure is becoming more accessible, but most examples focus on enterprise use cases or expensive cloud AI services. I want to demonstrate how individuals can build sophisticated, cost-effective AI systems for personal use while maintaining complete privacy and control.

There’s also something poetic about documenting the building of an AI system that will eventually help manage the very blog posts documenting its creation.

The Journey Ahead

I’ll be documenting this entire build process here - the successes, failures, cost optimizations, and lessons learned. This is as much about the learning journey as the destination.

Planned Blog Series

Setting Up the Foundation - AWS infrastructure with Ansible
Deploying ramalama - Local model serving on Fedora instances
Building the First Agent - Financial advisor implementation
Agent Communication - Inter-agent protocols and coordination
Cost Optimization Deep Dive - Keeping it frugal with Spot instances
Security and Privacy - Protecting personal data in the cloud
Lessons Learned - What worked, what didn’t, what I’d do differently

Getting Started

The project is already underway with a proper directory structure, Ansible playbooks, and deployment guides. Everything is designed to be reproducible and well-documented.

If you’re interested in following along or building something similar, the entire project will be documented with infrastructure-as-code principles. While I won’t be open-sourcing the personal configuration details, the architectural patterns and deployment strategies will be fully shared.

What’s Next?

Next up: Setting up the foundational AWS infrastructure in us-east-2 and getting our first ramalama instance running. The Consilium’s first advisor is about to come online.

Follow along as I build The Consilium - proving that personal AI infrastructure can be both sophisticated and affordable.

David Duncan's Personal Blog - Technology

A Molokai Palette for the Gum Pelican Theme

Why gum

The sidebar wasn’t showing

Code highlighting: regenerate pygment.css with .highlight scoping

The site palette: a CUSTOM_CSS_FILES overlay

The overlay itself

What it costs

Making it reusable

What’s next on this blog

falcon-stats: A Trading Discipline System Built on PAI

falcon-stats: A Trading Discipline System Built on PAI

What falcon-stats Does

The Architecture

How PAI and TELOS Make This Work

The Philosophy: P&L Over Price Action

Who This Is For

Getting Started

Acknowledgments

Building a Bookmap-Style CVD Indicator with Claude Code and Python

Building a Bookmap-Style CVD Indicator with Claude Code and Python

What CVD Actually Is

The Data Pipeline

Choosing a Visualization Library

D3.js — Maximum Flexibility, Maximum Effort

Lightweight Charts (TradingView) — The Sweet Spot

Plotly and Dash — Python-Native Prototyping

uPlot — Raw Performance

SciChart.js — Enterprise Grade

What Makes Bookmap Special

Where Claude Fits In

Next Steps

PAI Framework: How I Rebuilt a Personal AI Infrastructure for Trading and Cloud Work

PAI Framework: How I Rebuilt a Personal AI Infrastructure for Trading and Cloud Work

What Drew Me to PAI

How I Made It Mine

What the Fork Looks Like

What I Have Learned

Try It Yourself

Introducing The Consilium: A Personal AI Advisory System

Introducing The Consilium: A Personal AI Advisory System

Why “The Consilium”?

The Agent Council

Technical Philosophy: Frugal over Fast

Key Design Principles

Estimated Costs

The Architecture Vision

Why Build This?

The Journey Ahead

Planned Blog Series

Getting Started

What’s Next?

Code highlighting: regenerate `pygment.css` with `.highlight` scoping