Platform Intelligence
Brain Infrastructure & Architecture
Every Avalon feature routes through the Avalon Brain - a cognitive substrate that stores the stylist corpus, runs the vision.hair.transfer module, and connects intake to visualization. This document covers how the platform is wired, what the seven substrate layers do, and what Avalon owns at delivery.
01
How everything connects
Every Avalon component routes through the Brain. There are no direct node-to-node connections outside of it. This is not just an architecture pattern - it is what makes the corpus self-reinforcing. When a stylist contributes texture data, that data flows through the Brain before it reaches the visualization engine, which means every contribution sharpens every recommendation across the platform.
The Stylist Corpus is highlighted in gold because it is the moat. Every other component can be rebuilt. A well-structured, properly released corpus of textured hair types with real model releases cannot be replicated in months. It is the one asset a competitor cannot buy their way into.
Core platform
Stylist corpus (the moat)
Client-facing layers
AI inference
Phase 4+
02
Seven substrate layers
The Brain is not a single model. It is seven stacked layers, each with a distinct job. What makes the Avalon deployment a T3 tenant is that all seven layers are provisioned at full capacity, tuned to the hair domain, and running on Cliff's hardware - not shared cloud infrastructure.
L7
Safety Layer
consent gate + BIPA compliance
BIPA-compliant biometric consent verification before any image enters the pipeline. Data classification and guardrails run here before content reaches inference. Every session starts here.
L6
Context Compression
session compaction
Manages long consultation sessions. Prior preferences, past styles, and consultation history are compressed and reinjected at the start of each session so the model has full client context without hitting token limits.
L5
Memory Layer
client preference store
Persistent per-client memory. Preferred styles, hair health notes, stylist relationship history, and product sensitivities. This is what lets a returning client pick up where they left off without starting over.
L4
Inference Router
ArcRouter - vision.hair.transfer
Routes inference requests to the correct model. The vision.hair.transfer module lives here, alongside the feasibility ranker, the product recommendation model, and the stylist matching engine. Failover is automatic.
L3
Vector Store
semantic search index
Embeddings for every texture, style, and product in the corpus. Powers the style search experience - "find me something like this" - and the feasibility ranking that tells a client whether a style works for her hair type.
L2
Corpus Engine
texture library ingestion
Processes corpus shoot outputs. Every new stylist contribution - photos, metadata, model releases - runs through here to be chunked, tagged, and indexed. The quality gate that determines what enters the corpus.
L1
Knowledge Graph
Neo4j - hair taxonomy + stylist profiles
The entity-relationship core. Stylist profiles, style taxonomies, hair type classifications, product relationships, and client preferences all live here as graph nodes. This is what makes recommendations traversable and explainable.
03
The snapshot model
Avalon is a T3 Brain tenant. That means at delivery, Cliff receives a production snapshot of ArcGrid's live Brain, tuned to the hair domain and installed on his hardware. The snapshot captures everything: the corpus, the graph, the trained model weights, the routing configuration, and the memory substrate.
ArcGrid's Brain continues to compound from that point - new protocols, improved models, new corpus techniques. Avalon's Brain is the snapshot. Upgrades are Cliff's decision on Cliff's timeline. Avalon is never starting from scratch, even if years pass before the next upgrade.
You get what we run in production - installed on your hardware, owned permanently. As the platform improves, upgrades are your choice on your timeline. You are never starting from scratch.
04
What the T3 tier delivers
T3 is not a software license. It is a deployment of the full Brain stack - all seven layers - configured for the hair domain, installed on Cliff's infrastructure, and handed over as an owned asset. The distinction matters because it means data sovereignty, no ongoing vendor dependency for the core stack, and no per-seat or per-query fees to ArcGrid for the Brain itself.
Full stack deployment
All seven substrate layers installed on your hardware. Not a SaaS seat. Not a managed API. The whole stack runs in your environment under your control.
Data sovereignty
Client photos, consultation history, stylist contributions, and hair profiles never leave your infrastructure. BIPA compliance is enforced at L7 before any data enters the pipeline.
Production snapshot
Delivered as ArcGrid's live production Brain tuned to hair. Includes corpus, graph, model weights, and routing config. Upgrades optional, on your schedule, never forced.
Stylist corpus ownership
The corpus built under Avalon's contribution program is Avalon's asset. Not shared with ArcGrid, not used for training other tenants. Model releases and consent documentation travel with the data.
Upgrade optionality
When ArcGrid ships improvements to the Brain stack, Cliff decides whether to apply them and when. There is no automatic update that changes behavior in production. You run what you shipped until you choose otherwise.
No per-query fees
The Brain stack runs on your hardware at your cost. ArcGrid's fee is a one-time delivery and configuration fee, not an ongoing per-inference or per-seat charge for the core infrastructure.
The questions in Section 09 of the pitch deck about entity structure and data ownership are directly related to what you want to happen to the corpus and the Brain at exit. If Myavana is the acquirer, you want both assets clearly owned by the entity being acquired, not licensed back from ArcGrid. The structure here supports that. But if the structure is wrong going in, it is much harder to fix at the deal table. Worth reviewing before Phase 1 closes.
05
How the three delivery buckets work
Every Brain engagement works the same way. You bring three categories of material. Each becomes a different class of asset with a different ownership model. The class determines who can export it, modify it, and what happens to it if the engagement ends. For Avalon, the style library and aesthetic taxonomy are what make the Brain distinctly yours - no other T3 tenant will share them.
Bucket 1
Domain Corpus
Cliff brings the Avalon style library - names, categories, hair-type compatibility rules - and consented sample images for the vision.hair.transfer eval harness.
Class A module
The vision.hair.transfer module is built from your eval data and owned by ArcGrid as a platform module. Avalon gets a perpetual T3 license. This is the highest-value class for a Brain tenant.
Bucket 2
Business Rules + Brand Voice
Defined in a workshop - what a "match" means in the Avalon product, how the AI should speak to users, the session flow design, and aesthetic category definitions.
Class B tenant config
Routing rules, aesthetic ontology, prompt configuration, and session flow logic. Owned by Avalon. Exportable at any time under the T3 perpetual license.
Bucket 3
User Data
Individual user hair profiles and uploaded images generated at runtime per session. Biometric data under BIPA requires explicit consent at every capture point.
Class C
Always user-owned. BIPA consent gated at the session level. Deleted on unhook. Never used to improve the platform module without explicit Avalon authorization.
06
What Avalon brings specifically
The corpus here is visual and categorical, not textual. The style library defines the taxonomy. The sample images provide the raw material for the eval harness that determines whether the vision.hair.transfer module meets the quality bar. The session flow documentation tells us what the AI interaction needs to produce at each step.
Corpus - what to bring
Sample images for eval harness
Images used to build and validate the vision.hair.transfer module. Must include textured hair at sufficient volume and quality to pass the eval gate. Consent documentation required for every image.
Consent docs required
Style library - names, categories, compatibility rules
The full Avalon style taxonomy - every named style, the hair-type compatibility matrix, and the categories users browse. This is the Knowledge Graph's core entity set.
Class A module foundation
App user journey specification
What does a full session look like end to end? When does the user upload? When does the AI return results? What does the user do with the match? The flow determines what the module needs to produce.
Existing product documentation
Any spec sheets, technical documentation, or prior product design artifacts. Seeds the corpus with existing Avalon definitions rather than starting from scratch.
Rules + voice - workshop topics
What "match" means in the Avalon product
How confident does the system need to be before surfacing a recommendation? What is the threshold for a strong match versus a possible match?
Session flow design
How should the AI interaction feel? How many results per session? How does the system handle low-confidence or no-match states?
Brand voice for style recommendations
How does Avalon speak to users? The tone config determines how the AI communicates results, alternatives, and confidence levels. Set here, applied everywhere.
Aesthetic category definitions
The ontology layer above individual styles - what categories exist, how they're organized, and how the routing logic uses them to narrow results.
User data - generated at runtime
User hair profiles
Per-user hair type, preferences, and session history. Generated at runtime. Class C: user-owned, BIPA consent gated at capture.
BIPA consent at capture
Uploaded session images
User photos uploaded per session for matching. Class C: never retained beyond the session without explicit consent. Deleted on unhook.
Style preference signals
Likes, saves, and dismissals that personalize recommendations over time. User-generated at runtime. Feeds the recommendation layer without leaving the Avalon tenant.
07
Open items before architecture is finalized
BIPA biometric compliance for image data - counsel required (BL-R8 open)
Hair images collected from users for style matching are potentially biometric identifiers under BIPA (Illinois Biometric Information Privacy Act). BL-R8 is open and counsel is required before the platform handles user-uploaded images. The consent framework at L7 must be architected with BIPA compliance in mind - what must be disclosed, what consent form is required, how long images can be retained, and what the deletion protocol is on unhook. This is not optional. BIPA carries per-violation statutory damages.
Textured hair eval is the go/no-go gate
The vision.hair.transfer module is only viable if it performs well across a representative range of hair types - including textured, coily, and natural hair. The eval harness must include sufficient consented sample images of textured hair to validate this. If the eval fails this gate, the module design changes before build begins. Cliff needs to confirm the sample library includes adequate textured hair coverage before the eval harness is constructed.
Consent documentation for eval images
Every image in the eval harness needs documented consent - specifically authorizing use for AI model training, not just general app use. Broad app terms of service are not sufficient for BIPA. Cliff should confirm whether existing image sources (if any) carry appropriate consent, or whether new image collection with explicit AI training consent is required. The eval cannot begin without this documentation in place.
08
How we start
BL-R8 and the consent framework are the hard dependencies. The style library and workshop can begin in parallel with the counsel engagement. The eval harness - and therefore the go/no-go decision on the module - waits on consent-documented images. The T3 perpetual license structure is already agreed in principle; what's needed from Cliff is the corpus and the green light on compliance.
01
Counsel + BL-R8
BIPA framework confirmed. Consent language for image capture and training use drafted. BL-R8 closed.
02
Style library delivery
Full Avalon taxonomy delivered. Knowledge Graph entity schema designed from it. Workshop scheduled.
03
Eval harness + image review
Consented sample images reviewed for coverage - especially textured hair. Eval harness built. Go/no-go decision made.
04
Module build begins
Eval gate passed. vision.hair.transfer module architecture confirmed. Build begins against the T3 perpetual license.
09
Brain versioning: what it means for your product
ArcGrid ships new Brain versions when model weights improve (a new base model or a domain fine-tune), when corpus ingestion techniques advance, or when substrate layer protocols change. Any of these can produce a new numbered version. The question is what that means for you.
The short answer: nothing happens to your Brain unless you choose it. Your snapshot is installed on your hardware. ArcGrid shipping v2 does not touch your installation, does not change your model behavior, and does not require any action on your part. You are not on a subscription that automatically upgrades. You are on a perpetual license with optional upgrade windows. Each window is a deliberate decision with a testable outcome.
Stability: no surprise changes
Your product behavior does not change unexpectedly. The eval harness you passed at delivery is still the passing bar. No silent model updates, no behavior drift. If you shipped a product that works, it continues to work exactly as shipped until you decide otherwise.
The compounding gap: upgrade or fall behind
ArcGrid's Brain improves with every new tenant, every corpus contribution, every eval run. Your snapshot does not compound off those improvements unless you upgrade. Over 2-3 years without an upgrade, the gap between the platform Brain and your snapshot widens. Upgrade windows exist to close that gap on your timeline, not ArcGrid's.
The corpus travels with any upgrade
The ER style library, eval images, and taxonomy are model-agnostic data. They are not tied to a specific Brain version. An upgrade delivers new model weights and substrate protocols; your corpus loads into the new Brain exactly as it was. You do not rebuild it. You do not lose it.
When an upgrade is available: ArcGrid delivers a new snapshot candidate. Your team runs it through the textured hair eval harness. If it passes, it replaces the prior snapshot. If it fails the eval gate, you stay on the prior version. The decision is yours and the outcome is measurable before you commit.
10
Building the moat
The corpus is one defensible position. It is not the only one. The businesses that build lasting positions in AI-adjacent markets typically hold several overlapping assets - each one harder to replicate than the last. Below are the six positions available to Avalon and how each one compounds.
The consented dataset
Hair visualization models will keep improving. What will not be easily replicated is a library of consented, professionally sourced images of textured hair types (4A-4C) with documented style metadata. This is Class A: owned by ArcGrid as a platform module, exclusively licensed to Avalon under T3. No other tenant gets this corpus.
The style taxonomy and ontology
Class B, owned by Avalon. The ER-authored style library, compatibility matrix, and aesthetic ontology encoded in the Knowledge Graph are not generic. They represent Saige's professional expertise and ER's brand standards. A competitor can build a general hair app. They cannot copy the taxonomy built by the team that has been doing this professionally.
The eval harness as industry standard
The methodology for testing AI systems against textured hair is itself a proprietary asset. If Avalon publishes the eval framework as an industry standard, it becomes the authority on what "works" for textured hair. Competitors who want to prove their model works on 4A-4C coils need a benchmark. Avalon could own that benchmark.
The ER network and stylist relationships
ER stylists are early contributors to the corpus. Their professional networks, client relationships, and booking patterns become signals in the recommendation layer. This is a qualified supply-side relationship that cannot be bought. It has to be built over time, and it creates a trust signal no amount of engineering can replicate at launch.
The CIELAB and identity gates
The skin tone consistency gate (CIELAB delta) and the face embedding identity gate are not just quality checks - they are patentable quality standards. If Avalon defines and patents these gates, any competitor claiming "face preservation" is either meeting Avalon's published standard or not. That is a defensible position in marketing and in court.
White-label deployment and network effects
If the platform becomes the standard for textured hair AI, white-label licensing becomes a revenue and positioning moat. Each new deployment, with appropriate consent, adds corpus signals back to the platform. The network compounds across deployments, not just within one. ER is the charter customer and validation environment. Additional deployments are the compounding mechanism.
None of these positions are automatic. Each one is built by decisions made early: getting consent documentation right before the first image enters the pipeline, involving Saige in the taxonomy before the first style ships, running the eval harness before committing to a base model. The moat is not a feature. It is the accumulation of decisions that competitors will have to replicate from scratch if they want to compete on the same ground.