How We Build CareLogic

The gate: no ship without green

CareLogic does not ship unless the gate stamps the commit. The gate is self-hosted, containerised, and carries no external billing dependency, because the critical path of a quality product should not depend on a third-party SaaS staying up. The deploy script refuses to provision unless the gate's stamp matches the current commit. A squash cannot sneak a non-gated commit through.

Every step exists to make the discipline enforceable, not merely honoured until it slips.

What the full gate runs, in order:

1. Dependency vulnerability audit. A package-scanning tool checks installed packages against the PyPI/OSV advisory database. Known-unfixable advisories can be accepted explicitly and documented; everything else is a hard stop.

2. Full migration chain on real Postgres. The migration tool runs the complete migration history on a fresh real Postgres container, as a non-superuser owner role that mirrors production. This exercises permission-revocation statements and append-only triggers that the schema auto-create shortcut does not install, bugs that a SQLite test database hides entirely.

3. Full test suite on Postgres. The entire unit and integration battery runs on the containerised Postgres instance, not SQLite. This catches database-dialect divergences that would otherwise reach production silently.

4. Postgres enforcement smoke. A dedicated check confirms the database's security constraints and audit-trail protections are actually in force after migration, not just assumed.

5. Live HTTP smoke. The running app container is probed: the health endpoint must return 200; the API documentation endpoint must be disabled; an unauthenticated request to an admin route must return a 401.

6. Render smoke (real PDF). A render-capable image is built and used to render one of each report type: Final Report, Pulse, Roll-up, to an actual PDF file. The gate asserts the correct rendering path (Paged.js), not the Chromium path that drops running headers and produces white gaps. The toolchain is the same one that runs in production.

7. Browser end-to-end suite. Browser journeys (Playwright) run against a live server spawned by the test suite itself. Actual assertion failures fail the gate on first occurrence.

8. Deploy stamp. On full-gate success, the gate writes a stamp. The deploy script checks this stamp before provisioning. The stamp, not a flag, is the authority.

The always-on safety floor.

The gate distinguishes between a contained Python-only change and a risky one. A contained change runs an impact-selected subset of the suite via the change-impact gate. Regardless of scope, five checks always run and cannot be skipped by change-impact selection:

A stylesheet or template change additionally triggers the visual layer: component and visual conformance (a structural check of design-system classes) and the browser end-to-end suite. When the change touches an asset the PDF reports actually render from, a shared design token, a font, or a report template, it also triggers the render smoke, because only rendering a real PDF catches a report-layout regression.

Change-impact gating.

The change-impact gate (used between full runs for fast, safe iteration) determines automatically whether a change is safe for change-impact selection or must escalate to the full suite. Changes to core data-layer files escalate unconditionally. Changes to web or API routes always add the end-to-end suite. A template or stylesheet change adds visual conformance, and adds the PDF render smoke only when it touches an asset the reports render from. Out-of-scope changes (migrations, dependencies, configuration) automatically escalate to the full gate.

What one day of adversarial review added.

In July 2026 we ran six independent review lenses against the live product, the way we would for a client, and shipped every fix the same day. Three of the outcomes say more about the system than the findings did:

• The deploy machinery refused a broken web-server configuration on production deploy day. Visitors saw nothing; the rejection became a permanent lane in the gate by evening.
• Restore is rehearsed, not assumed: every night an encrypted copy of the production database restores into a clean container and the row counts are verified against the source. A backup that has never been restored is a hypothesis.
• Every test now has a lane that runs it. A census found suites that no pipeline executed; they either joined a lane or failed loudly. A test nobody runs emits confidence and guards nothing.

The reviewer merits a note of its own. We pointed the same AI tooling that helps build CareLogic (Claude Code on Anthropic's Fable 5, the strongest model available for this kind of work at the time of the review) at the codebase, with a brief to challenge it adversarially and surface everything wrong. It found real defects at the seams, which shipped as fixes the same day, and it reported the core sound: dependencies real, secrets absent, the privacy floor strong, the scoring engine exact. A review that finds nothing has told you nothing. One that finds real seams and still calls the core solid has earned the verdict.

The self-assessment: composite 91/100, published with the yellows

We run CareLogic's own diagnostic on CareLogic, through the live scoring engine, against our honest answers. The result is published here, version and date stamped, including the items that are not green.

Current result (current engine, June 2026; assessed 2026-06-07; score recalculated against current engine prior to publication):

The progression is the honest part.

The first time we ran it, CareLogic scored 48/100, with three criticals. That was a faithful result of answering the instrument with incomplete inputs: the instrument cannot know what it was not told. When a senior brought the context that changes the honest read (quality ownership is distributed through a documented governance model, multi-reviewer PR process, and our decisions log rather than concentrated in one person; the development tooling runs pre-launch against backed-up data and never touches live customer data; a consultant reads every generated report verbatim before it is delivered), the corrected read was 77/100, zero criticals. The correction was not a reconsideration of the organization; the instrument now had the information it needed.

The score then moved only when real work was done:

• Writing our AI use policy and our AI governance spec did not move Processes. Documented intent is not a working control.
• The evaluation harness lifted Processes but left it one point under the green line by design, because the harness cannot bless its own golden set.
• Processes crossed green only after a consultant reviewed and approved a real engagement as a golden, the thing only a human can do.

Every yellow we flag on ourselves maps to a service SQALogic sells: systematic AI evaluation and regression testing, AI governance formalization, continuity and knowledge resilience. We found those gaps by taking our own diagnostic honestly.

The recursive find.

A quality tool's strongest credential is finding its own defects first.

Running the diagnostic on its own instrument and then auditing the answers surfaced a real configuration defect before launch: the AI-bias critical ("AI features ship without bias testing") was wired to the latency question rather than the bias question. A latency bottleneck would have silently triggered an AI-bias urgent finding; an organization with genuine absence of bias testing would have fired nothing. The self-audit caught it and we fixed it before launch. The audit of associations confirmed every other mapping was correct.

AI governance

CareLogic uses AI in two places. The boundary between them is structural, not a directive.

The diagnostic scoring engine is deterministic. Scores are computed by a pure-functional engine against defined criteria. The client-facing grade cannot hallucinate, drift between runs, or vary with a model version. This is the only possible outcome of how the engine is written. An LLM is never involved in scoring.

Synthesis is generative, bounded, and human-reviewed. The 1:1 interview transcript and final-report generation use an LLM running locally on the consultant's machine. There is no AI-model API key on the production server, so it physically cannot call an external model. Generation is impossible server-side. This is an enforcement mechanism, not a policy aspiration.

The generation layer is governed by several controls:

• Verification by traceability. Every quote in a generated report must trace to the source transcript using normalized verbatim matching (whitespace- and case-insensitive); an attribution the model cannot ground fails a gate before the report is assembled. The consultant review is the backstop for any non-verbatim paraphrasing.
• Completeness gates. The report assembly checks that all required sections are present and that key source material is reflected.
• Human gate. The consultant reads every final report verbatim before delivery. This is a required process step, documented in our AI use policy, that the consultant attestation record captures.
• Per-report provenance. Every final report records the model identifier and prompt version used to produce it. The prompt version is server-stamped and pinned; a silent model version bump could go undetected without the consultant's attestation, which is why the attestation record is required. The consultant retains the source transcript required for full reproduction.
• Residency. The 1:1 transcript never touches the server. For engagements requiring Canadian data residency, the consultant runs generation through a client-preferred provider; the attestation record captures provider, model, and region. Adapter build-out is done per-engagement. CareLogic does not lock engagements to a single provider.
• Vendor review. Before adopting a provider or model for client-facing generation, data residency and retention terms are confirmed and the decision is recorded. The review repeats on any provider or model version change.

Our AI use policy and AI governance spec were committed before this page was written. The controls they describe were in force before the documents named them.

Current engine, June 2026 · Assessed: 2026-06-07 · Score recalculated against current engine prior to publication.