North Star Labs
North Star Engine
An operational system for opportunity discovery, machine-readability auditing and multi-model strategic analysis — built on the principle that software must prove its own output.
What it is
North Star Engine is working software. It runs on real infrastructure, against live websites and live markets, and it produces artifacts that can be opened and checked.
It is not a wrapper around a chat interface. It is a command centre with three layers: an execution engine that runs research and audit tasks, a memory layer that keeps every result as a permanent searchable record, and a governance layer whose only job is to determine whether the engine’s output is actually true.
That third layer is the part most AI systems do not have, and it is the reason this one exists.
The problem it was built for
Two shifts are happening at the same time, and most businesses are exposed to both.
The first is discovery
For twenty-five years, being found meant ranking in a list of blue links. That is ending. People increasingly ask an AI assistant a question and act on the single answer it gives. The assistant does not browse; it reads. If a business is not legible to a machine — no structured data, no semantic markup, no machine-readable summary of what it sells — it is not absent from page two. It is absent from the answer.
This is measurable, and North Star Engine measures it. In a survey of eleven hospitality businesses in Nicosia conducted with the system’s auditing module, two had an llms.txt file — the emerging convention for telling an AI assistant what a site contains. Nine did not. Scores across the thirteen technical checks ranged from 33 to 83 out of 100, and the weakest results clustered among established mid-tier independents: businesses with real revenue, real reputations, and no representation in the channel their customers are shifting to.
Nicosia hospitality sites with an llms.txt file
That gap is not a marketing problem. It is an infrastructure problem, and it is invisible to the businesses that have it.
The second is verification
As AI systems take on research and analysis, the constraint stops being whether they can produce an answer. They always produce an answer. The constraint becomes whether anyone can tell if the answer is true.
This is the harder problem, and it is where North Star Engine is differentiated.
The engineering thesis
Systems built on language models fail in a specific and dangerous way: they fail while rendering correctly.
A conventional system fails loudly. A process crashes, a request times out, an error appears in a log. You know something is wrong because something looks wrong.
It returns a fluent, well-formatted, entirely plausible document that is wrong. It reports a page as successfully read when the page returned a 404 and the text captured was the site’s own error navigation. It scores a website 100 out of 100 because the scoring arithmetic overflowed and was silently clamped. It presents five expert opinions where four were truncated mid-sentence, before the recommendation, at a fixed character limit nobody remembered setting. It files an API rate-limit notice under the heading of a strategic verdict, commits the file cleanly, and lights a status panel green.
Every one of those is a real failure found in this system and fixed. None of them raised an error. All of them produced output that looked correct.
The engineering response is a set of rules that now govern every component.
A request that returns is not a request that succeeded. Check the status code, the content type, and a minimum size — not merely that a response arrived.
A file with the right headings and populated sections can still be two-thirds missing. Check the shape of the content: identical lengths across independent sources, endings mid-word, size ratios between runs.
An edit that matches nothing exits cleanly. A pattern that finds nothing removes nothing and writes a valid file. Check the artifact, not the exit code.
Every check is validated against a real page whose correct answer is known independently — and validated in both directions, confirming that it still passes what it should pass. A fix verified only against the case that was broken is not verified.
These rules are not documentation. They are the reason the system’s findings can be relied on, and they are enforced at every step: no change is made without a byte-verified backup, no result is accepted without an artifact that can be opened, and nothing is recorded as complete until it has been demonstrated on screen.
Architecture
The system runs locally. Core operation does not depend on any external platform, and no proprietary data leaves the machine unless a task explicitly requires it.
The execution layer is a Python service exposing a fixed set of permitted operations. It listens only on the local loopback interface — never on a network — and every capability it offers is explicitly allow-listed. It orchestrates research tasks, web extraction, document generation and audits, and it enforces per-task timeouts so a stalled job fails cleanly rather than blocking the system.
The extraction layer reads live web pages through a locally hosted engine. This replaced a metered commercial service: extraction is now unlimited, free at the margin, and private. It carries its own guard — a page is only reported as read if the HTTP status is valid and the content is not a disguised error page.
The model layer is deliberately multi-vendor. Different tasks route to different models by cost and capability: frontier models for verification-critical work where a fabricated fact has real consequences, cheaper and free-tier models for bulk gathering. No single vendor is a dependency, and the routing is explicit rather than incidental.
The memory layer is a single structured vault. Every audit, hunt, briefing and analysis is written to it as a timestamped, tagged document. There is one memory spine, and every component reads from and writes to it, which is what allows work done months apart to compound rather than dissipate.
The governance layer is a panel of five independent models. Each is given the same question and the same factual brief on the system’s real state, and each answers without seeing the others. A synthesis step then produces a single verdict identifying genuine agreement, genuine disagreement, and one recommendation — and it is required to name the model behind every argument it cites, so bias is visible on the page rather than removed invisibly. It is explicitly permitted to return “no consensus.”
That last provision matters more than it appears. A system forced to produce a confident verdict from partial input generates the most dangerous artifact available to it: maximally certain, minimally grounded. The panel is designed to abstain.
The governance layer works.
What it does
Opportunity discovery
Given a free-text brief — a market, a sector, a type of counterparty — the system searches, reads real pages, and returns structured findings with a verified contact path and a cited source for every claim. It is governed by an explicit evidence standard: no asserted weakness without a source that proves it, no inferred conclusion from a company’s size or age or location, and an honest statement of how deep the search actually went.
This standard exists because the early version failed it. An initial run identified genuine companies and then invented their deficiencies, describing firms with modern working websites as having none. That failure is the origin of the entire verification discipline described above. Subsequent runs, cross-examined claim by claim against independent sources, held up completely.
Machine-readability auditing
A thirteen-point technical audit of any public website, measuring how legible it is to an AI assistant: structured data, semantic markup, canonical addressing, machine-readable summaries, social and metadata completeness. Output is a scored report naming each specific failure.
The audit is honest about its own limits. It reads server-delivered HTML and does not execute JavaScript, which means on some modern frameworks it audits the delivered document rather than the fully rendered page. That caveat travels with every report the system produces, because an audit that overstates its own reach is worse than no audit.
Strategic analysis
The five-model panel, applied to a real decision with real system state attached, producing an attributed verdict. Grounding matters: given a stale brief, the panel argued for work already completed. Given accurate current state, the same five models unanimously identified the highest-value remaining item. The value is not in the models. It is in what they are given.
Automated intelligence
Scheduled operation with a date-guarded trigger, so a task that misses its window because the machine was asleep runs at the next opportunity rather than being lost silently. Results are written to the vault. Nothing that spends money, sends a message or publishes anything runs without explicit human authorisation — a hard architectural rule, not a configuration setting.
What it cannot do yet
Stating this precisely is part of the method.
The machine-readability audit does not execute JavaScript, so on client-rendered sites it evaluates the delivered document. The soft-error-page detector recognises English and French page titles; other languages are not yet covered, which matters for multi-jurisdiction research. The model panel relies partly on shared free-tier capacity that saturates unpredictably, so it is designed around three to four reliable voices rather than five. Scheduled operation is bounded by the availability of the host machine.
Each of these is known, measured and bounded. None is inferred from an absence of complaints.
Direction
Three lines of development are in progress.
Machine-readability as a service. The audit measures a gap that is real, large, and currently invisible to the businesses that have it — evidenced by a local sample in which nine of eleven established businesses had no machine-readable representation at all. The audit is the diagnostic; the remediation is the work.
Verified discovery at volume. The opportunity engine’s constraint is not finding candidates. It is proving that what it found is true. The verification architecture is the asset, and it is what makes findings usable rather than merely plausible.
Compounding institutional memory. A single structured vault that every component reads and writes, so that an audit conducted today informs a search conducted next quarter. Most AI tooling forgets everything between sessions. This does not.
North Star Labs Ltd
North Star Labs Ltd is being established in Nicosia, Cyprus.
The system described on this page is operational. Its components run against live targets, its outputs are stored as inspectable artifacts, and its history — including every fault found and the evidence that closed it — is recorded in full.
That record is the point. A system that cannot show its working cannot be trusted with a decision that matters.
Contact: contact@nstarlabs.com