Brain Name: Content Brain
Document Type: Active Reference Framework
Status: Active Reference Framework
Version: v1.0
Authority: HeadOffice
Applies To: Content Brain, Content Brain Site Content Intelligence Report Generator Specification, Content Brain Publishing Readiness Status Values Framework, Content Brain Source Depth And Evidence Label Framework, Content Brain Offer Evidence Requirements Framework, Content Brain Compliance Routing Needs Framework, Content Brain Human Approval Points Framework, future Content Brain field planning, future Content Brain build readiness planning, future specification candidates, future build ready technical specifications, future Content Brain UI planning, future Content Brain queue planning, future Content Brain dashboard planning, future Content Brain generator planning, future Content Brain AI Employee planning, and future M handoff preparation
Parent: Content Brain
Last Reviewed: 2026-06-08
Content Brain Future Fields To Define Later Framework
Purpose
The purpose of this page is to define how Content Brain should treat possible future fields before any technical build work begins.
This page exists because recent Content Brain planning pages have identified many useful future fields.
These fields may later support:
Site Content Intelligence Reports
Publishing Readiness checks
Source Depth labels
Offer Evidence reviews
Compliance Routing
Human Approval Points
Content Briefs
SEO Content Briefs
Affiliate Content Packs
Bridge Page Reviews
Landing Page Refresh Reviews
Future queues
Future dashboards
Future generators
Future AI Employees
Future Content Brain UI
Future Supabase structure
Future M implementation work
However, possible future fields are not approved database fields.
Possible future fields are not approved UI fields.
Possible future fields are not approved Supabase fields.
Possible future fields are not approved automation triggers.
Possible future fields are not approved M build instructions.
This page defines how to park, label, review, and later promote future fields without accidentally turning planning ideas into build work.
Current Status
Current Content Brain status:
Manual Workflow Only
Plugin UI Not Started
No Supabase Work Started
No Brain Room Routing Started
No Automation Started
No Queue Build Started
No Dashboard Build Started
No Generator Build Started
No AI Employee Build Started
No Cross Brain Routing Build Started
M’s Active Build Work Untouched
Current evidence stage:
Manual Workflow Evidence Stage
Current planning stage:
Build Readiness Planning Stage
Current page role:
Active Reference Framework
Current maturity status:
Workflow usable
Evidence backed
Manual ready
Affiliate support tested
Bridge page refresh tested
Landing page refresh tested
Publishing readiness status values created
Source depth labels created
Offer evidence requirements created
Compliance routing logic created
Human approval points created
Future fields now require parking discipline
Future database design not authorised
Future UI design not authorised
Future generator design not authorised
Future M handoff not authorised
This page is a manual reference framework only.
Why This Page Is Needed
Content Brain is now moving from manual workflow evidence into controlled future specification planning.
That means many useful future fields are being discovered.
Examples include:
Source Depth Label
Evidence Quality Label
Offer Evidence Status
Compliance Routing Required
Human Approval Required
Approval Scope
Recommended Next Operational Page
Site Voice Summary
Content Gap List
Refresh Opportunity List
Affiliate Support Gap List
Claim Risk Level
Disclosure Review Required
Search Intelligence Required
Research Brain Required
HeadOffice Review Required
These are useful planning fields.
But if they are treated too early as real build fields, Content Brain risks creating:
database bloat
UI bloat
unclear M instructions
premature Supabase schema
unstable dashboard logic
too many status fields
duplicate field names
conflicting field meanings
automation triggers before workflow maturity
technical build complexity before manual logic is stable
This framework prevents that.
Core Principle
A future field is only a candidate until HeadOffice promotes it into a build ready technical specification.
A field mentioned in a planning page is not automatically approved.
A field listed in a future specification candidate is not automatically approved.
A field included in a registry note is not automatically approved.
A field used in manual workflow language is not automatically approved as a database or UI field.
Future fields must first prove usefulness manually.
Then they can be consolidated.
Then they can be standardised.
Then they can be mapped.
Only after that can they be considered for technical build planning.
Future Field Status Categories
Use the following categories to classify possible future fields.
Manual Language Only
Meaning:
The term is useful for manual workflow discussion but is not yet a field candidate.
Use when:
the phrase helps the operator think
the phrase appears in a page section
the phrase is not repeated enough yet
the phrase does not need tracking
the phrase may change later
Example:
Reader trust concern
Possible angle mismatch
General content fit issue
Action:
Do not promote.
Keep as manual language.
Future Field Candidate
Meaning:
The field may be useful later but has not yet been standardised.
Use when:
the term appears repeatedly
the term supports decision making
the term may help future reports
the term may support future status tracking
the term may be useful in a queue or dashboard later
Example:
Source Depth Label
Offer Evidence Status
Compliance Routing Required
Action:
Park as a future field candidate.
Do not build yet.
Standardisation Needed
Meaning:
The field idea is useful but needs clearer naming, allowed values, or relationship to other fields.
Use when:
several versions of the same field exist
field wording is inconsistent
values are unclear
ownership is unclear
field meaning overlaps with another field
Example:
Claim Risk Level versus Compliance Risk Level
Human Approval Required versus HeadOffice Review Required
Action:
Do not build.
Consolidate later.
Manual Testing Required
Meaning:
The field should be tested manually before technical planning.
Use when:
the field seems useful
operators need to use it in real workflows
it is unclear whether it adds value
it might be too much admin
it might create friction
Example:
Reviewed Page Count
Approval Scope
Offer Context Suitable For Soft Content Only
Action:
Use manually in future tests.
Do not build yet.
Specification Candidate Field
Meaning:
The field is relevant to a future specification candidate, but still not technical.
Use when:
the field appears in a future specification candidate page
the field helps define future system behaviour
the field may later become a build field
Example:
Site Name
Site URL
Source Depth Label
Human Approval Owner
Action:
Keep in the future specification candidate.
Do not hand to M.
Build Ready Field Candidate
Meaning:
The field may be ready for technical specification planning, but only after HeadOffice approval.
Use when:
manual use has proven value
naming is stable
allowed values are clear
ownership is clear
downstream use is clear
field is not duplicated
field has a clear purpose
Example:
Source Depth Label after repeated manual use
Compliance Routing Required after repeated manual use
Action:
Prepare for build ready technical specification only if HeadOffice approves.
Approved Technical Field
Meaning:
The field has been approved inside a build ready technical specification.
Use only when:
HeadOffice has approved technical planning
M handoff scope is clear
the field has a defined name
the field has allowed values
the field has storage logic
the field has UI or output use if relevant
acceptance criteria exist
Action:
Only then may it be handed to M.
Content Brain is not at this stage yet.
Future Field Naming Rules
Future field names should be:
clear
plain English
short enough to use
specific
non duplicated
workflow relevant
easy to map later
compatible with manual output
compatible with future technical specification
Future field names should not be:
vague
overlapping
too long
too clever
too technical too early
implementation specific
database specific before build approval
UI specific before UI approval
automation specific before automation approval
Avoid vague field names such as:
Status
Score
Risk
Approved
Ready
Type
Notes
Use specific field names such as:
Publishing Readiness Status
Source Depth Label
Evidence Quality Label
Offer Evidence Status
Compliance Routing Required
Human Approval Required
Approval Scope
Recommended Next Operational Page
Claim Risk Category
Future Field Value Rules
Future field values should be controlled before build planning.
A field should not become build ready until its values are clear.
Example:
Field:
Source Depth Label
Possible values:
Surface Review
Basic Site Review
Multi Page Site Review
Full Supplied Page Review
Source Material Review
Offer Page Review
VSL Claim Review
User Supplied Context
Manual Workflow Evidence
Verified External Research
Search Intelligence Required
Research Required
Compliance Review Required
Unknown Evidence Depth
A field without clear values should stay in:
Standardisation Needed
or
Manual Testing Required
Future Field Ownership Rules
Every serious future field should eventually have an owner.
Possible owners include:
Content Brain
HeadOffice
Research Brain
Search Intelligence Brain
Affiliate Brain
Compliance Brain
Data Brain
Ads Brain
Conversion Brain
M only after build approval
Examples:
Source Depth Label
Owner:
Content Brain
Evidence Quality Label
Owner:
Research Brain if evidence quality is technical or factual
Content Brain if used for manual content review only
Compliance Routing Required
Owner:
Content Brain can flag
Compliance Brain owns interpretation
Offer Evidence Status
Owner:
Content Brain can flag
Affiliate Brain owns offer logic
Human Approval Required
Owner:
Content Brain can flag
HeadOffice owns final authority
Field ownership prevents Content Brain from taking authority it should not own.
Future Field Promotion Path
Future fields should move through this path.
Stage 1:
Manual Language Only
Stage 2:
Future Field Candidate
Stage 3:
Standardisation Needed
Stage 4:
Manual Testing Required
Stage 5:
Specification Candidate Field
Stage 6:
Build Ready Field Candidate
Stage 7:
Approved Technical Field
Fields should not skip from Stage 1 to Stage 7.
A field mentioned in a planning page must not jump directly into Supabase, UI, or automation.
Required Checks Before Field Promotion
Before a future field is promoted, ask:
Does this field solve a real workflow problem?
Has it appeared repeatedly?
Is the field name clear?
Are the possible values clear?
Does it duplicate another field?
Who owns the field?
Who uses the field?
What decision does it support?
Does it reduce friction or add friction?
Does it support manual workflow?
Does it support future build readiness?
Could it create confusion?
Could it create technical bloat?
Could it create dashboard bloat?
Could it create UI bloat?
Could it create M build confusion?
Is it needed now or later?
If these answers are unclear, do not promote the field.
Current Future Field Candidate List
The following fields are currently future candidates only.
They are not approved technical fields.
Site Intelligence Fields
Possible future fields:
Site Name
Site URL
Site Purpose
Primary Audience
Business Model
Main Offer
Current Content Inventory
Reviewed Page Count
Reviewed URLs
Site Voice Summary
Tone Notes
Primary Topic Clusters
Existing Content Assets
Content Gap List
Internal Linking Opportunities
Refresh Opportunities
Repurposing Opportunities
Duplicate Content Warnings
Thin Content Warnings
Trust Signals
Trust Gaps
Affiliate Support Gaps
SEO Structure Notes
Reader Journey Notes
Site Specific Content Instructions
Status:
Future Field Candidate
Action:
Use manually where helpful.
Do not build yet.
Publishing Readiness Fields
Possible future fields:
Publishing Readiness Status
Draft Needed
Brief Ready
Needs Revision
Needs Site Intelligence
Needs Source Review
Needs Offer Evidence
Needs Compliance Review
Needs Search Validation
Needs Internal Linking Review
Needs Refresh Instead
Needs Repurposing Review
Duplicate Risk
Thin Content Risk
Parked Pending Clarity
Ready For HeadOffice Review
Ready For Publishing Review
Approved For Next Manual Step
Do Not Use
Status Severity Level
Status:
Future Field Candidate
Action:
Use as manual status language.
Do not build yet.
Source Depth And Evidence Fields
Possible future fields:
Source Depth Label
Evidence Quality Label
Evidence Risk Level
Evidence Review Notes
Source Review Required
Research Brain Required
Search Intelligence Required
Compliance Review Required
Unknown Evidence Depth
Unsupported Evidence
Conflicting Evidence
Status:
Future Field Candidate
Action:
Use manually when evidence matters.
Do not build yet.
Offer Evidence Fields
Possible future fields:
Offer Name
Vendor Name
Affiliate Network
Offer URL
Sales Page URL
VSL URL
Primary Promise
Primary Mechanism
Offer Evidence Status
Offer Claims Need Review
Offer Proof Weak
Offer Context Suitable For Soft Content Only
Offer Not Ready For Content
Offer Evidence Escalation Required
Proof Evidence Status
Disclosure Required
VSL Claim Review Required
Affiliate Brain Review Required
Status:
Future Field Candidate
Action:
Use manually for affiliate content workflows.
Do not build yet.
Compliance Routing Fields
Possible future fields:
Compliance Routing Required
Compliance Risk Level
Claim Risk Category
Disclosure Review Required
Needs Claim Softening
Needs Evidence Before Compliance
Do Not Use Until Reviewed
VSL Claim Risk
Ad To Page Match Risk
Urgency Risk
Scarcity Risk
Comparison Claim Risk
Testimonial Risk
Misleading Curiosity Risk
HeadOffice Review Required
Status:
Future Field Candidate
Action:
Use manually for compliance-sensitive content.
Do not build yet.
Human Approval Fields
Possible future fields:
Human Approval Required
Approval Owner
Approval Scope
Approval Status
Approval Date
Approved For Manual Planning
Approved For Drafting
Approved For Revision
Approved For Review
Approved For Publishing Review
Approved For Public Use
Approved For Campaign Use
Approved For Future Specification Planning
Approved For Build Ready Specification Planning
Approved For M Handoff
Do Not Approve
Status:
Future Field Candidate
Action:
Use manually for approval clarity.
Do not build yet.
Routing And Next Step Fields
Possible future fields:
Recommended Next Operational Page
Recommended Next Brain
Recommended Next Action
HeadOffice Review Required
Research Brain Required
Search Intelligence Required
Affiliate Brain Required
Compliance Brain Required
Data Brain Required
Ads Brain Required
Conversion Brain Required
Parked Pending Clarity
Status:
Future Field Candidate
Action:
Use manually for routing clarity.
Do not build yet.
Build Readiness Fields
Possible future fields:
Build Readiness Status
Manual Evidence Present
Manual Testing Required
Specification Candidate Status
Build Ready Specification Required
M Handoff Required
M Handoff Approved
Technical Build Approved
Plugin UI Impact
Supabase Impact
Brain Room Routing Impact
Automation Impact
Queue Impact
Dashboard Impact
Generator Impact
AI Employee Impact
Cross Brain Routing Impact
Status:
Future Field Candidate
Action:
Use manually for build readiness discipline.
Do not build yet.
Fields That Must Not Be Built Yet
Do not build any of the following yet:
database fields
Supabase fields
UI fields
dashboard fields
queue fields
automation triggers
AI Employee routing fields
M handoff fields
plugin settings
API payload fields
status automation fields
approval workflow fields
These may be useful later.
They are not ready now.
Future Field Parking Rule
When a new possible field appears, park it instead of building it.
Use this format:
Future Field Candidate:
Field Name:
Source Page:
Possible Purpose:
Possible Owner:
Manual Use Case:
Known Values:
Unknowns:
Build Status:
Do Not Build Yet
This keeps the idea without creating technical bloat.
Future Field Consolidation Rule
At a later stage, Content Brain should consolidate future fields.
The consolidation pass should check:
duplicate fields
overlapping fields
unclear names
unclear owners
unclear values
fields that are only manual language
fields that should be retired
fields that should be merged
fields that should be promoted
fields that need more testing
fields that may support future technical specification
Do not do this consolidation during active page creation unless HeadOffice chooses that as the work block.
Field Bloat Prevention Rule
A field should not exist just because it can exist.
A field should exist only if it supports a real decision.
Avoid creating fields for:
nice to know information
rare edge cases
unclear workflows
vanity tracking
duplicated status
excess admin
premature automation
unclear ownership
unclear future use
If a field does not improve decisions, do not build it.
Manual First Field Rule
Before a field becomes technical, it should be used manually.
Manual use should show whether the field:
helps the operator
reduces confusion
improves decisions
improves routing
improves approval clarity
improves evidence handling
improves publishing readiness
improves future specification planning
creates too much friction
duplicates another field
If manual use is not helpful, do not build the field.
Relationship To Site Content Intelligence Report Generator Specification
The Site Content Intelligence Report Generator Specification lists many possible future fields.
This page controls how those fields should be treated.
The fields in that specification are not build approved.
They should remain future candidates until manual testing and HeadOffice approval support promotion.
Relationship To Publishing Readiness Status Values Framework
Publishing Readiness Status Values may later become future fields.
For now, they are manual status language.
This page prevents those statuses from becoming premature UI or database fields.
Relationship To Source Depth And Evidence Label Framework
Source Depth labels may later become future fields.
For now, they are manual evidence labels.
This page prevents evidence labels from becoming premature technical fields.
Relationship To Offer Evidence Requirements Framework
Offer Evidence fields may later support affiliate content workflows.
For now, they are manual review categories and possible future candidates.
This page prevents affiliate evidence logic from becoming premature database design.
Relationship To Compliance Routing Needs Framework
Compliance routing labels may later support future workflow fields.
For now, they are manual routing language.
This page prevents compliance logic from becoming false automation or premature workflow triggers.
Relationship To Human Approval Points Framework
Human approval labels may later support approval fields.
For now, they are manual authority language.
This page prevents approval language from becoming automatic approval logic.
Relationship To Future Registry Updates
The Content Brain Page Registry should not list every possible future field.
The registry should track pages and structure.
Future fields should be recorded in this framework or in future specification candidate pages until a build ready technical specification is approved.
Relationship To M Handoff
This page is not an M handoff pack.
Do not give this page to M as implementation instructions.
M should not build from this page.
Future fields should only reach M after:
manual use proves value
fields are consolidated
field names are stable
allowed values are clear
owners are clear
technical purpose is clear
HeadOffice approves a build ready technical specification
Until then, all fields remain planning candidates.
Drift Protection
This framework prevents:
planning fields becoming technical fields too early
future fields becoming database fields by accident
manual status language becoming UI logic too early
approval labels becoming automation triggers
compliance labels becoming automated clearance
offer evidence notes becoming database bloat
source depth labels being overbuilt too early
field duplication
field naming drift
dashboard bloat
queue bloat
Supabase schema bloat
M receiving premature field instructions
Content Brain turning into a complex admin system before workflows are stable
future specification candidates being treated as implementation approval
Recommended Next Step
Use this framework to park future fields during Content Brain planning.
Do not build any fields yet.
Do not create database schema.
Do not create Supabase fields.
Do not create UI field lists.
Do not create dashboard fields.
Do not create automation triggers.
Do not create M handoff instructions.
Recommended immediate use:
When future pages mention fields, label them as future candidates only.
Use them manually where helpful.
Consolidate later before build ready technical specification work.
Registry update:
Deferred until end of day batch update.
Pending registry entry:
Content Brain Future Fields To Define Later Framework
Status:
Active Reference Framework
Version:
v1.0
Parent:
Content Brain
Expected page count impact:
Previous expected page count:
47 pages
New expected page count:
48 pages
Change Impact Declaration
Pages Created:
Content Brain Future Fields To Define Later Framework
Pages Updated:
None immediately
Pages Renamed:
None
Pages Deleted:
None
Pages Deprecated:
None
Registries Requiring Update:
Content Brain Page Registry at end of day batch update
Canon Version Update Required:
No
Architecture Version Update Required:
No
Manual Workflow Test Log Update Required:
No
Manual Workflow Synthesis Report Update Required:
No
Build Readiness Shortlist Update Required:
No
Plugin UI Impact:
None
Supabase Impact:
None
Brain Room Routing Impact:
None
Automation Impact:
None
Queue Impact:
None
Dashboard Impact:
None
Generator Build Impact:
None
AI Employee Impact:
None
Cross Brain Routing Impact:
None
M Active Build Impact:
None
Page Count Impact:
Previous expected page count:
47 pages
New expected page count:
48 pages
Registry update timing:
Deferred until end of day batch update
Change Log
Version: v1.0
Date: 2026-06-08
Author: HeadOffice
Change:
Created Content Brain Future Fields To Define Later Framework as an Active Reference Framework.
Defined how Content Brain should treat possible future fields before technical build work begins.
Added future field status categories, naming rules, value rules, ownership rules, promotion path, required checks before promotion, current future field candidate list, fields that must not be built yet, future field parking rule, future field consolidation rule, field bloat prevention rule, manual first field rule, relationships to Site Content Intelligence Report Generator Specification, Publishing Readiness Status Values Framework, Source Depth And Evidence Label Framework, Offer Evidence Requirements Framework, Compliance Routing Needs Framework, Human Approval Points Framework, future registry updates, M handoff, drift protection, and recommended next step.
Confirmed possible future fields are not approved database fields, UI fields, Supabase fields, automation triggers, or M build instructions.
Confirmed this page does not authorise plugin UI, Supabase, Brain Room routing, automation, queues, dashboards, generators, AI Employees, cross brain routing, or M implementation handoff.
End Of Day Save Point Template
Page list checked:
Yes / No
Content Brain Site Content Intelligence Report Generator Specification created:
Yes / No
Content Brain Publishing Readiness Status Values Framework created:
Yes / No
Content Brain Source Depth And Evidence Label Framework created:
Yes / No
Content Brain Offer Evidence Requirements Framework created:
Yes / No
Content Brain Compliance Routing Needs Framework created:
Yes / No
Content Brain Human Approval Points Framework created:
Yes / No
Content Brain Future Fields To Define Later Framework created:
Yes / No
Content Brain Page Registry updated today:
Yes / No
Registry update deferred:
Yes / No
Pages created:
Content Brain Site Content Intelligence Report Generator Specification
Content Brain Publishing Readiness Status Values Framework
Content Brain Source Depth And Evidence Label Framework
Content Brain Offer Evidence Requirements Framework
Content Brain Compliance Routing Needs Framework
Content Brain Human Approval Points Framework
Content Brain Future Fields To Define Later Framework
Pages updated:
None / Content Brain Page Registry if updated at closeout
Pages renamed:
None
Pages deleted:
None
Current expected page count:
48 pages / other
No plugin UI started:
Yes / No
No Supabase work started:
Yes / No
No Brain Room routing started:
Yes / No
No automation started:
Yes / No
No queue work started:
Yes / No
No dashboard work started:
Yes / No
No generator build started:
Yes / No
No AI Employee work started:
Yes / No
No cross brain routing started:
Yes / No
M’s active work untouched:
Yes / No
Target save point:
Content Brain — Future Fields To Define Later Framework Created / Registry Update Deferred / Build Readiness Planning Stage / Manual Workflow Only / Plugin UI Not Started
Final Rule
Future fields are planning candidates only until HeadOffice approves otherwise.
Do not build fields because they appear in a planning page.
Do not treat future fields as database fields.
Do not treat future fields as UI fields.
Do not treat future fields as Supabase fields.
Do not treat future fields as automation triggers.
Do not hand future fields to M until they are part of a build ready technical specification.
Use future fields manually first.
Consolidate later.
Build only after clear approval.
These rules are manual operating language only.
They are not build approval.
END CONTENT BRAIN FUTURE FIELDS TO DEFINE LATER FRAMEWORK v1.0