Systems and AI Stance

Category: frameworks Sources: founder-brain-dump-ai-systems-reframe-2026-08-16.md, founder-brain-dump-certification-ai-documentation-2026-08-18.md, ai-usage-notes-2026-08-18/00-Index.md, ai-usage-notes-2026-08-18/01-Route-Finder.md, ai-usage-notes-2026-08-18/02-Range-Review.md, ai-usage-notes-2026-08-18/03-Certification.md, ai-usage-notes-2026-08-18/04-Training.md, ai-usage-notes-2026-08-18/05-Technical-Ownership.md, MASTER-BUSINESS-PLAN.md (Trace Launch project, fetched 2026-08-23 — current service names, and §5–6 Internal Systems / AI Posture, which supersede the six-brain material below as current-state fact) Confidence: high Last Updated: 2026-08-23

Internal Systems (current, built or building)

Three systems sit behind the business. None is a public product.

1. Trace Core. The first build: a deterministic product-and-evidence register. No AI in v1. The single quiet system name — "Trace Brain" and "the Brand system" are dead names and are never used publicly.
2. The retainer configurator. Internal quoting tool for Embedded Support (see Offer Architecture §5), including the cost-of-hiring comparison in every quote.
3. The Cloudflare backend. Already exists and runs newsletters, article creation, email and an Anthropic API integration. The website is built to sit on it (Eleventy conversion at integration time). No new platform or CMS is ever proposed. A spend cap on its Anthropic API usage is applied at integration.

AI Posture

AI is a quiet capability, never a headline or a marketed feature.

• Internal working rule, never published: AI may surface patterns, cluster ideas and draft internal briefs. Glen writes, frames and signs everything public.
• Public statement: a signed three-paragraph AI policy (final text in approved-copy-drafts.md, a Trace Launch project file) lives on its own page, linked from the footer, About and relevant services. Deliberately not linked from the homepage — it is a trust page, not marketing.
• Core promises: AI never decides compliance, never produces or alters evidence, and nothing reaches a client Glen has not thought through himself.

The Systems Vision (not yet built — everything below this point is roadmap, not the current build)

Trace's longer-term systems direction is trained systems: six purpose-built "brains" (see systems/brains/) that would accelerate Glen's expert judgement on a defined task, each grounded in Trace's own knowledge, standards corpus, and delivery history rather than a general-purpose model given someone's files to loosely interpret. None of this exists yet. Trace Core, above, is the actual v1 build, and it carries no AI. Everything from here to the end of this article describes the vision this could grow into — useful as a design reference for whenever that work starts, not a description of what a client experiences today. Do not present any of it as live or imminent in public copy, a quote, or a sales conversation.

The Core Rule (for the vision above, if and when it's built)

Systems accelerate expert judgement. They do not replace it.

Cross-Service Principles

Four principles apply to every service, without exception:

• Human ownership is absolute. Glen signs everything that leaves Trace. A signature means he has examined the evidence and owns the content, the recommendation, or the position. There is no automated approval stamp.
• Systems accelerate and organise; they do not decide. They map, calculate, sequence, cross-reference, link, flag and draft. They never close the professional or commercial loop.
• Client data is never exposed between clients. One client's product data, documentation, commercial context or claims never reach another client's output, directly or indirectly.
• Learning improves future accuracy while keeping individual client information isolated. What compounds is pattern knowledge, not client material.

Every brain drafts, flags, surfaces, or prepares. Glen reviews every output, strengthens caveats where the system has been too confident, and owns the final decision, document, or position that reaches the client. No brain issues a document in Trace's name, invents a requirement or test result, decides an outcome on its own, or speaks for Trace without Glen's sign-off.

Learning and Confidentiality

The systems learn from delivered work. What is retained is tightly bounded.

Retained for learning:

• Anonymised, category-level patterns: typical constructions for a product category, average prices and lead times, common missing evidence, recurring failure modes, typical expiry interdependencies, frequent claim mismatches, common cross-reference opportunities, observed standards drift.
• Body and assessor behaviour: the requirements, comment themes, document-set preferences and restrictions associated with specific notified bodies, test houses and, where identifiable, individual assessors.
• Structural patterns: how documentation sets fail, how registers are best structured, which prioritisation signals prove effective.

Never carried forward into another client's work:

• Specific product data, bills of materials, technical files, certificates and test reports.
• Commercial data: pricing, volumes, strategic ranking, commercial context.
• Public and marketing claims belonging to that client.
• The delivered files themselves, which are the client's property to keep, edit, archive and reuse.

For training scenarios the standard is stricter still: source situations are stripped of origin before they enter the shared scenario pool, so no client appears in another client's material even indirectly. Only patterns that have actually occurred are eligible — nothing theoretical or invented.

The result is that the system gets more accurate with every completed project while each client's information stays isolated to that client.

Documentation is generated per certification body, not from a template

The Evidence & Documentation brain does not fill in a stock technical file. It builds the documentation set for the specific certification body, product and route in front of it, because the requirement genuinely differs by recipient:

• Two certification bodies want different documents and different structure.
• Two assessors inside the same body can want different things.
• Some bodies accept test reports only from their own organisation, which has to be checked before testing is booked.

The output files look conventional; what changes is layout, structure and what each set contains, shaped to what that recipient requires.

The feedback loop is the point. Every comment that comes back from an assessor is taken in, and the next set accounts for it. Comment volume on comparable submissions is expected to fall over time. This is the one place where Trace's systems compound.

Two consequences worth stating publicly. First, the choice of certification body stays open, instead of being decided by whichever one the brand's existing documentation happens to suit. Second, Glen signs the technical file, and the signature means he has checked it; the system drafts, it does not certify its own output.

Follow-up and status are automated too. Check-ins with test houses and certification bodies run on a schedule rather than by hand, and the weekly written status is drawn from live project data rather than composed manually.

Not said publicly (Glen's observation, held back deliberately): a delivered technical file is the client's to keep, edit and reuse, but that individual copy does not keep improving the way Trace's system does. It is true and it is a real asymmetry, but stated on a public page it reads as lock-in rather than as capability. See backlog.md if this is ever revisited.

Public naming: Trace Core, not six brains

Naming history: "Trace Brain" → "the Brand system" (Glen, 2026-08-17) → Trace Core, the master plan's final name (2026-08-23). Trace Brain and the Brand system are both dead names now.

The six brains above are vision, not architecture that exists. If and when any of it is built, it is never named individually and never called a brain on the public site — public copy refers to the single name Trace Core. A page describes what the system does for that service; it does not tell the reader there is a Route Finder brain or a Training Scenario brain.

Today, Trace Core is a deterministic register with no AI in it — there is nothing to describe on a public page beyond that, and no brain names to avoid using yet.

The Clarity Test

Before any public description of Systems or AI goes out, it must pass this test: could a reader interpret this as Trace throwing client files into a generalist AI tool, the way a generalist or a con artist would?

If a reader could reasonably read it that way, the wording has failed and must be rewritten. The differentiator is precision and restraint, not the presence of AI — anyone can point a generalist model at a document. What Trace has built is task-specific, conservative by design (prefers "flag uncertainty" over "assume"), and never left unsupervised.

Per-Service Systems Value (vision — not built)

Free Triage and Second Opinion, added to the service ladder after this article was last written, have no dedicated brain — Free Triage is a plain qualification call and Second Opinion is a direct human review. See Services for both.

Each brain's boundary in one line:

• Route Finder brain — accelerates the diagnostic; does not invent requirements or replace the decision.
• Evidence & Documentation brain — never invents test results or issues documents in Trace's name.
• Range Review brain — does not decide keep/fix/remove on its own.
• Issue Response brain — speeds the first structured response; does not speak for Trace without human sign-off.
• Embedded Support / Intelligence brain — does not own the client relationship or final advice.
• Training Scenario brain — accelerates scenario preparation; teaching and the relationship remain Glen's.

The Operating Model Per Service (vision — not built)

Route Finder

The Route Finder is the structured intake and route-mapping layer at the front of the Trace pathway.

Inputs. A client-completed intake covering product type or category, target markets, claimed class or performance level (or an explicit statement that none is claimed), and any documentation already held. Supporting material requested by the intake: product images and a bill of materials. Uploaded test reports, certificates and impact-protector certificates. Alongside these, the patterns the system already holds for that product category — typical constructions, average lead times, common missing evidence, historical price variance and risk patterns. The intake is deliberately light for the client; the mapping work sits with the system.

What the system does. Determines the protection claims being made or that should be made; maps the applicable standards and constructs the logical test sequence (mechanical tests such as tear and seam strength first, abrasion and others later, class determination early where no class is stated). Calculates a base price from the standard test set, then adjusts for the number of constructions present and other variance factors. Produces colour and finish estimates where relevant and generates the matching sample requirements. Builds an initial risk matrix from the test sequence, claimed class and evidence gaps. Reviews uploaded evidence starting with the most obvious problems — report age, whether the laboratory is on the accredited list, missing impact-protector certificates — and logs what is missing. Pre-populates a draft test-submission package from the intake data, in the variant the chosen test house requires. Estimates lead times from historical data for that product category.

What Glen owns. The mapped route, sequencing and any class or standard assumption the system has made. Pricing, risk weighting and the recommended route where commercial, technical or client-specific factors change them. The evidence-review findings and the missing-items list. Final approval of the route recommendation, sample requirements and draft submission package before anything reaches the client or transfers into a live project. Whether a risk flag or lead-time estimate is tempered or emphasised for that client.

What the client receives. A product-specific route map with the test sequence, applicable standards and any class determination still required; a pricing view with base price and variance adjustments; defined sample requirements; an initial risk matrix; a review of supplied evidence with obvious gaps flagged; a pre-populated draft submission package; estimated lead times; and a clean hand-off into Certification Management carrying the correct submission-form variant.

What it never decides. The final recommended route or the commercial offer put to the client. Whether a specific piece of existing evidence is acceptable for the intended certification path. The precise risk weighting or lead-time commitment given. Any interpretation carrying certification or contractual liability. Whether the client proceeds with testing, or which test house is used.

What it learns. Once a product completes its full journey, actual prices, lead times, issues encountered, risk patterns that materialised and construction-related variances feed back as reference data, improving base-price calculation, sequencing logic, risk matrices and lead-time estimates for that product category. Individual product detail, bills of materials and that client's commercial pricing stay the client's; only anonymised category-level patterns are retained.

Coverage. Intake-driven mapping, test sequencing, pricing and variance calculation, sample-requirement generation, evidence review, risk-matrix creation, the draft submission package and the Certification hand-off run on every Route Finder engagement. There is no non-system version. The depth of evidence review scales with what the client uploads; the core route-mapping and pricing logic always runs.

Range Review

The Range Review turns a range's documentation into a prioritised, evidence-linked, forward-looking view of the live range.

Inputs. The client's documentation set — technical files, certificates, test reports, Declarations of Conformity and related evidence — ported into a structured folder system. Product identifiers that let every document be linked to a live product. Certificate and test-report metadata: issue and expiry dates, standards referenced, claims made, notified body or test house. Public-facing claims where accessible: product pages, catalogues, marketplace listings, marketing statements. Optional commercial context (relative volume, strategic importance, sales ranking) enabling volume-weighted prioritisation. The markets each product is sold into, so multi-market consistency can be checked. Patterns already held from previous reviews.

The foundation step. Documentation is first linked to products and cleaned. Without that linkage nothing downstream is reliable.

What the system does. Links every document to its product and surfaces structural problems first — missing files, orphaned certificates, broken evidence chains. Detects orphan products that appear in the commercial range with no linked current certificate or technical file. Extracts and interlinks expiry dates and calculates downstream consequences, such as a certificate expiring in twelve months whose supporting test report has already lapsed, meaning retesting at renewal and elevated risk and cost. Applies a prioritisation matrix ranking products by what can safely remain, what needs immediate attention or further information, what is a candidate for removal or redesign, and what will generate the highest future cost. Elevates high-volume products carrying elevated risk where commercial data is supplied. Verifies certified claims against the technical file and test reports, and cross-checks them against current public statements. Records the public claims present at review time as a baseline so future reviews detect drift. Overlays standards gaps, identifying referenced standards superseded or amended since certification. Runs multi-market consistency checks where a product carries more than one mark. Flags products affected by known upcoming regulatory change. Generates a renewal schedule per retained product with a recommended start-of-submission window, typically six months ahead of the target date. Assesses whether Declarations of Conformity are publicly accessible, downloadable and correctly linked. Assembles all of this into a structured draft report.

What Glen owns. Confirmation or amendment of every product-to-document linkage and the cleaned foundation. Every prioritisation decision and the underlying risk and cost logic. Validation of claim-verification findings, standards-gap flags, multi-market results, orphan-product flags and horizon-scanning alerts. Approval or revision of the renewal schedule and recommended actions. Which insight layers are emphasised or tempered for that client. The signature on the final report.

What the client receives. A prioritised review mapping every product to an action category with supporting evidence and risk rationale; explicit orphan-product flags; interlinked expiry analysis showing what faces retesting or elevated cost at renewal; a renewal schedule with recommended submission lead times; claim verification against both the technical file and current public statements, plus the public-claim baseline; the standards-gap overlay; multi-market consistency findings; horizon-scanning flags; the public-accessibility assessment for Declarations of Conformity; and, where appropriate, a living digital inventory hand-back — a structured index of product to current certificate to key test reports to next action date that the client maintains as their single source of truth. A volume-weighted view is included where commercial data is supplied.

What it never decides. The final action decision for any product. Whether a claim discrepancy, standards gap or multi-market inconsistency is commercially acceptable or must be corrected. The commercial weighting of risk against business importance. Any interpretation carrying legal or certification liability. Whether an orphan product is removed or remediated — it surfaces the fact only. Sign-off of the report.

What it learns. How documentation sets fail, common expiry interdependencies, frequent claim mismatches, typical structures of badly maintained ranges, observed standards drift, multi-market inconsistencies, and which prioritisation signals work. That client's product data, certificates, commercial context and public claims stay theirs; only generalisable failure modes and structural patterns carry forward.

Coverage. The patterned analysis, prioritisation matrix, expiry interlinking, claim verification, orphan detection, standards-gap overlay, multi-market checks, horizon-scanning flags, marketing-claim baseline, draft-report generation and optional living inventory run on every Range Review. There is no non-system version. Depth of public-claim searching and volume weighting scale with what the client makes available; the core documentation-driven analysis always runs.

Certification Management

On the full route plus documentation model, the system is a high-precision drafting and learning engine.

Inputs. The product definition and technical data Trace assembles with the client — materials, construction, intended use, performance claims, existing test data, risk analysis. The chosen pathway: which notified body, certification body or test house, and the individual assessor once known. Historical feedback already held for that body, that assessor or that class of product: previous comments, required document sets, restrictions such as accepting only their own test reports. Live operational data for status and chase: submission dates, outstanding actions, responses received. New comments and clarification requests arriving during the project. Nothing starts from a blank template or a stock technical file.

What the system does. Generates a complete, bespoke documentation set tuned to the exact requirements of that body, test house and assessor for that pathway — layout, content emphasis, supporting evidence and document order all adjusted to what that organisation wants and has accepted before. Flags restrictions, compares submitted evidence against known expectations, and surfaces gaps and mismatches before submission. Applies learned patterns from previous projects with the same body or similar assessors so the first pass already anticipates common comment themes. Produces status updates and chase communications to the test house or certification body from live project state rather than manual writing. Ingests each new comment cycle so the next generation for that body or assessor class improves.

What Glen owns. He reviews every generated set in full, and rejects, corrects, re-sequences or rewrites anything that falls short of his professional standard or the file's precise requirements. He makes the final call on completeness, accuracy and readiness for submission or handover. He signs the technical file.

What the client receives. A complete technical file and documentation package already formatted and content-tuned to the specific body or test house in use, and the file is the client's property to edit, archive and reuse. Live status updates and automated follow-up that keep client and certification body current without manual chasing. Across successive projects on the same route, fewer comment cycles.

What it never decides. Final technical or commercial sign-off. Whether a piece of evidence is acceptable in that specific instance. Interpretation of ambiguous regulatory or assessor language carrying legal or certification risk. Any change to the client's product claims or risk assessment without human review. Whether a certification body's comment is accepted or challenged.

What it learns. Requirement patterns, comment themes, document-set preferences and restrictions tied to specific bodies, test houses and identifiable assessors. The client's product data and their final signed technical file stay theirs; what is retained is body and assessor behaviour and documentation expectations, not the client's product IP. The delivered file does not itself carry future knowledge — the system does.

Coverage. The system is used on every Certification Management project following the full route plus documentation model. Generation, checking, learning and the automated status and chase layers are core to the service, not optional.

Training

The interactive platform is the delivery model, not an enhancement to it. Every Training delivery runs on it, and Trace does not sell Training without the platform ready. There is no non-interactive or static version of the service.

Training material is built from real, observed situations rather than theory.

Inputs. Live situations and patterns from completed Trace projects across the whole chain: factory production issues, certification body, notified body and test-house interactions and comments, buying and commercial decision points, documentation knock-backs, control failures, evidence gaps and common misunderstandings. Glen's professional experience and reasoning applied to them. The client's own list of recurring issues where supplied ahead of a session, and product-level detail for their range so scenarios walk through the actual physical products. Anonymised patterns already held from prior projects and prior deliveries.

What the system does. Ingests project outcomes and interactions, filters them until the original source is untraceable, and converts them into structured scenarios. Maps those scenarios onto the relevant product set, so a motorcycle-focused session draws only patterns applying to that category across factory, certification, buying and documentation viewpoints. Surfaces expert reasoning points, the wrong terminology in common use and precisely why it is wrong, the underlying principles governing the correct approach, and the practical next action when the situation recurs. Keeps session structure consistent across clients while the content inside it stays product-specific and granular.

What Glen owns. Which patterns and experiences are suitable for conversion into scenarios, and how they are framed. The accuracy and professional soundness of the reasoning, of the explanation of why a term or approach is wrong, and of the links back to Trace principles. Approval of the final scenario set for each client delivery, keeping it true to real complexity while fully anonymised. Delivery of the sessions themselves, and how far a client's pre-submitted issues shift the scenario mix.

What it never does. Expose identifiable client data, project detail or source situation to another client — every scenario is reworked into a completely anonymous form before use. Present theoretical or invented problems; only patterns that have actually occurred are eligible. Decide the professional framing, the correct reading of a grey area, or the final teaching points. Replace live delivery with automated answers.

What it learns. Anonymised patterns of real-world problems: misunderstandings, evidence-based changes, control failures, documentation gaps, test-house and notified-body behaviours, factory issues. Source situations are stripped of origin before entering the shared knowledge base, so no client's data appears in another client's training even indirectly. The scenario pool grows richer and more precise, and stays grounded in current reality rather than static examples.

Coverage. The continuous learning loop from live projects feeds every training delivery. Session structure is standardised; the content inside it is always product-filtered and pattern-based.

Embedded Support

The retainer sets up a structured technical foundation quickly and then keeps it live.

Inputs. The client's existing product list, certificates, test reports, technical files and any current registers or folders. Certificate scopes, expiry dates and related metadata. Mechanical and material test reports that may be reusable across products. The preferred working rhythm — weekly or monthly reporting — and preferred communication channels. Optional volume or strategic ranking for prioritisation inside the register. Ongoing updates: new certificates, new test reports and client-supplied changes during the retainer. Category-level patterns already held: typical expiry behaviours, common missing cross-references, frequent documentation gaps.

What the system does. Builds and maintains a living product register carrying each product, its certificate scope, linked test reports and current status. Maps products against certificate expiry dates and generates a certificate calendar. Organises documentation into a clean, searchable structure. Builds cross-referencing so mechanical and material test reports link to every product they remain valid for, with a dedicated re-use register. Produces configurable expiry alerts, typically nine, six and three months ahead, pushed into the client's channel. Maintains a shared real-time task and status view so completed and open work is visible without waiting for the periodic report. Generates the agreed weekly or monthly report covering completed tasks, open tasks and a soft utilisation insight comparing capacity used against retainer allowance. Surfaces a filtered vigilance digest of market-surveillance findings, recalls and common failure modes relevant to the client's categories or standards. Provides a documentation-health overview across the register, and keeps a full change log and audit trail. Pre-populates a Route Finder or Certification intake when a certificate approaches expiry, so the renewal starts with clean data and no re-keying.

What Glen owns. Approval of the register structure, cross-reference rules and calendar settings. Interpretation of vigilance signals and documentation-health flags. The content and emphasis of each periodic report. Sign-off of any formal output leaving Trace — updated registers, calendars, hand-off packages into a renewal project. Adjustment of retainer scope and priorities as utilisation or client needs change.

What the client receives. A living product register with certificate scopes, linked evidence and current status; a certificate calendar with configurable lead-time alerts; organised documentation and a test-report re-use register; shared real-time task visibility; the agreed periodic report with utilisation insight and vigilance digest; a documentation-health overview and full change log; and a clean pre-populated hand-off into Route Finder or Certification at renewal.

What it never decides. Whether a certificate or test report is still valid for a given product or market. The professional interpretation of a market-surveillance finding or recall. Any change to the client's product claims or risk position. The final content of formal reports or renewal recommendations leaving Trace. Whether the retainer level moves up or down.

What it learns. Anonymised patterns of how registers are structured, common cross-reference opportunities, typical expiry behaviours, frequent documentation gaps, and which vigilance signals prove useful for given categories. The client's specific register, certificates and commercial data stay theirs; only category-level structural and behavioural patterns are retained. Each new engagement starts from a stronger template and registers stay cleaner with less manual correction.

Coverage. The living register, certificate calendar, documentation organisation, cross-referencing and re-use register, real-time task visibility, periodic reporting with utilisation insight, vigilance digest, documentation-health overview, change log and renewal hand-off run on every Embedded Support retainer. There is no non-system version. Depth of vigilance filtering and channel integration scale with the client's product set and tools; the core register and calendar capability is always delivered.

Related Articles

• Services
• Delivery Methodology
• Modern Compliance
• Voice Guide
• Values
• Positioning