How It All Fits Together
What this guide is
This is a tour of the CoreConduit platform — the actual computer sitting in Stillwater, Oklahoma, that runs the consulting practice. It's not a step-by-step tutorial. It's an overview of how the pieces fit together, why certain decisions were made, and what the platform actually does day-to-day.
One small, energy-efficient computer runs the entire platform. No cloud servers. No monthly hosting bills. No complex cluster of machines. Just a single device — about the size of a deck of cards — serving a real consulting business. It draws roughly the same power as an LED light bulb and boots in under 30 seconds.
The platform is organized into five layers. Each layer builds on the one below it — you can understand the system by walking up from the physical hardware to the tools people actually use.
The foundation is deliberately minimal. One computer, one storage device, one network connection. No clustering, no distributed filesystem, no complex orchestration. This isn't a compromise — it's a design choice. Every additional component is something else that can fail, something else to keep updated, something else that breaks at 2 AM.
Everything runs from fast internal storage — the SD card slot is only used for the initial setup. The system is modest but capable: 8GB of memory, plenty of fast storage, and a 64-bit operating system. It sips power at idle and only ramps up when doing heavier work like processing documents or running AI queries.
The platform uses two types of databases, each chosen for the right reason:
All background services use the operating system's built-in service manager. No containers, no extra layers. One command checks the health of everything at once. When something breaks, the logs are in one place and the fix is usually straightforward.
The AI layer has three components, all running alongside the website and databases on the same machine. This works because the system shares memory intelligently — AI models unload from memory when idle, freeing space for other tasks.
A collection of local AI models handles different tasks. The primary model does the heavy lifting — code generation, reasoning through problems, understanding documents. Smaller, specialized models handle lighter work: classifying requests, triaging tasks, generating quick suggestions. Models load on demand and release memory when not in use. Usually only one or two are active at a time.
When someone asks a question about consulting documents, the system doesn't guess — it searches through an index of everything stored locally and finds the relevant pieces. Those relevant chunks are used to ground the answer in real information. All of this happens on the local machine: the search index, the document processing, the answer generation. Nothing is sent to an external service.
An automation layer coordinates multi-step tasks across the AI models, document search, and external tools. It handles routing requests to the right model, chaining steps together, and connecting to outside services when needed. Currently being refined but already in daily use. Not exposed to the public internet — accessed only from the local network.
The web server does double duty: it serves the public website and routes traffic to behind-the-scenes services. It handles SSL encryption (the padlock in your browser), enforces security policies, caches assets for speed, and redirects old URLs when content has moved.
A web interface for working with the local AI stack — testing prompts, managing which models are loaded, and inspecting the document search index. Provides both a visual dashboard for humans and structured endpoints for other programs to use.
A custom inventory management application used daily for tracking hardware, consulting assets, and client equipment. Built on a traditional web stack that's been stable and reliable for years. It's a different technology from the newer Python-based tools, but it gets the job done and there's no reason to rewrite what works.
A lightweight service that handles contact form submissions — validates the information, sends notification emails, and logs everything. Managed by the same service manager as everything else on the system.
The site you're reading right now. Three sections (main landing page, Nonprofit Hub, TechLounge) served as straightforward HTML with shared design and behavior. Deployed from the local machine to production hosting using a custom tool that handles previews and can roll back if something goes wrong.
Microsoft 365 connects to the local platform so that nonprofit clients can use the tools they already know — like Microsoft Forms — while their data gets processed privately, locally. A form submission triggers a flow that securely delivers the data to the local machine for processing. This means familiar Microsoft tools on the front end, complete data privacy on the back end.
Full details in the CoreConduit M365 Integration guide.
Six supporting tools round out the platform, each solving a specific operational need:
The architecture isn't arbitrary. These principles are the "why" behind every decision:
Honest gaps in the current setup:
Why document all this?
The CoreConduit platform exists because Cory got tired of subscription fees and handing control to cloud providers. Every piece was built to solve a real problem — handle a contact form, search consulting documents, track hardware inventory, run AI without sending client data to outside services. This architecture guide exists so that other consultants, nonprofit tech staff, and self-hosting enthusiasts can see what a complete platform looks like when you build it yourself. Not as a recipe to copy — but as proof that it's possible.
How Microsoft 365 connects to the local platform — using the tools your team already knows while keeping your data private and under your control.
Local AI · Self-HostingThe AI foundation this platform runs on — running language models, document search, and assistants entirely on your own hardware.