Two-Domain Brand Architecture: SimplyCodes (Hand) ↔ Product.ai (Brain) Surface Inheritance

Why we want this done

This project derives from Brand Kernel A-3 (Two domains permanently — SEO physics not branding preference), Brand Kernel A-4 (Installable surfaces converge under utility physics — the Hand × Brain separation inverts), Brand Kernel "Brand Transition Timeline" schema (the 24-month migration plan), Brand Kernel A-7 (Adversarial Conditions Forge Transferable Capabilities — SimplyCodes's 17-year forge IS the Product.ai story, not collateral), Product.ai Enterprise Kernel A-11 (The Brand Singularity Requires Three Layers — Brain × Voice × Hand), SimplyCodes Kernel (the cash engine that funds the transition; revenue-fortress pillar), and Brand-Distribution Outcome brand-entity (the recognized entity outcome explicitly requires Product.ai to inherit SimplyCodes's SEO authority and traffic without diluting either domain). The architecture is the operational layer between kernel and execution. Without it, the brand transition is theoretical; with it, every surface knows what to inherit, what to keep separate, what to migrate, when, and why.

Scope

Surfaces: productai-web, simplycodes-web, productai-extension (Q3 2026 launch), productai-mcp, aios. The candidate will need 1:1s with: Michael (CEO-sovereign brand calls and the Brand Transition Timeline), Phil Larson or engineering lead on the SimplyCodes web/extension (operational substrate — what's technically migratable when), Dakota Nunley (brand-distribution measurer), and the SimplyCodes product owner (current state of the Hand surface). The architecture depends on but does not own: the SimplyCodes Kernel (revenue-fortress substrate, not redoable), the Truth Graph publishing strategy (Product.ai Kernel A-8 Gravity Well Doctrine, separate project), the SC extension migration (engineering project — the architecture provides the brand spec the engineering migration ships against, not the migration itself).

What success looks like

A working Two-Domain Brand Architecture specifying: (1) the complete surface inventory of all surfaces touching either brand (web, MLPs, extension, mobile app, MCP, partnerships, recruiting, AIOS dashboard, llms.txt, JSON-LD schema, Knowledge Panel feeds, chat-agent response patterns, conference materials, etc.), (2) the transition rule for each surface — what it inherits from SimplyCodes, what it keeps separate, what migrates and when (aligned to Brand Kernel Brand Transition Timeline phases), (3) the avatar separation rules — when does the Hand × Brain visual code (Bioluminescent Intelligence cold light teal/indigo for Brain vs Contextual Density vibrant for Hand) hold, when does it collapse (installable surfaces), when does it hybridize (transitional surfaces during the 18-month migration), (4) the agent-readable disambiguation layer (sameAs schema, Wikidata entity disambiguation, llms.txt brand declaration, MCP brand surface that distinguishes Product.ai-as-Truth-Layer from SimplyCodes-as-Hand for AI agents querying), (5) the decision tree the team uses for any new surface or co-brand call. Form is candidate's choice. The decision tree must be executable — a team member with no founder access uses it on a fresh co-brand call and arrives at a defensible answer.

References

Constraints

• Tooling: Claude Code / Co-work + AIOS. May require Wayback Machine + SEO tooling access for surface inventory; clarify Day 1.
• IP: Trial scope. No aios-methods access. Not required.
• Time: 2 weeks. Day 1 onsite, Days 2-N remote, optional Day 13-14 onsite for surface-inventory walkthrough with engineering.
• The architecture MUST honor the constitutional kernel axioms (A-3 two domains permanently; A-4 installable convergence). Proposing to merge the domains or fully separate the installables is a Sample Reject — those calls are kernel-locked.
• The migration MUST ship the extension brand spec ahead of the Q3 2026 extension launch. Sequencing is load-bearing.

```

---

##