01
Theme Files
Liquid templates, snippets, layout files, page templates, theme stylesheets, and JavaScript that control the Thinkific experience.
Formationly Executive Operating System
FEOS Engineering Standards
The technical standards governing how FEOS pages, components, styles, scripts, Thinkific customizations, and future integrations should be designed, written, tested, documented, and maintained.
Architecture Library • Version 1.0 • July 2026
Purpose of the Engineering Standards
FEOS should be built consistently enough to grow without becoming fragile.
These standards establish a common technical approach for Formationly development. They are intended to reduce duplicate code, inconsistent styling, mobile defects, accidental breakage, undocumented changes, and dependency on individual developer memory.
The goal is not technical complexity. The goal is a stable, maintainable platform that can be understood and extended by future developers without losing the FEOS architecture or user experience.
Engineering Pillars
FEOS development should reflect six technical qualities.
01
Maintainable
Code should be understandable, organized, and safe to revise.
02
Reusable
Common interface patterns should become shared components.
03
Responsive
Every interface should work intentionally on desktop and mobile.
04
Accessible
Structure, contrast, labels, and interactions should support usability.
05
Traceable
Major changes should be committed, documented, and recoverable.
06
Architecture-Aligned
Technical implementation should support approved FEOS architecture.
Code Organization
Every implementation should have a clear home.
02
Page Blocks
Standalone HTML sections used inside Thinkific pages and documented as complete, labeled blocks rather than partial patch fragments.
03
Shared Components
Reusable navigation, cards, badges, progress elements, alerts, buttons, and panels shared across multiple FEOS workspaces.
04
Documentation
Architecture documents, technical specifications, sprint history, implementation notes, testing records, and release information.
Recommended Repository Structure
Files should be organized by purpose.
Formationly
├── docs
├── architecture
├── technical-specifications
├── sprint-history
└── release-notes
├── html-blocks
├── executive-headquarters
├── expansion-centers
├── conversation-centers
└── architecture-library
├── thinkific-theme
├── layouts
├── templates
├── snippets
├── stylesheets
└── scripts
├── assets
└── README.md
HTML Standards
HTML should provide meaningful, predictable structure.
Every standalone block should use a unique section ID that clearly identifies the feature or page.
Use semantic elements such as section, article, header, navigation, table, heading, paragraph, and list elements where appropriate.
Maintain one primary page heading and a logical heading hierarchy beneath it.
Avoid empty elements, unnecessary wrappers, duplicate IDs, and unsupported custom markup.
Links and buttons should use descriptive action language and valid destinations.
Complete blocks should be delivered in full when rebuilding a section. Do not rely on unclear patch fragments.
CSS Standards
Styling should remain scoped, reusable, and responsive.
SCOPING
Scope block styles beneath the unique section ID to reduce conflicts with Thinkific and other pages.
BOX SIZING
Apply border-box sizing within FEOS sections to improve layout predictability.
RESPONSIVE TYPE
Use clamp-based typography for major headings and avoid oversized fixed desktop values.
LAYOUT
Prefer CSS Grid and Flexbox over manual spacing, tables, or fixed positioning for page layout.
INLINE STYLES
Inline styles may support portable Thinkific blocks, but repeated production styles should move toward shared classes.
CONSISTENCY
Reuse approved FEOS colors, spacing, borders, radii, typography, and component patterns.
JavaScript Standards
JavaScript should be used deliberately and defensively.
Do not add JavaScript when HTML and CSS can provide the required experience.
Scripts should check that required elements exist before attempting to modify them.
Avoid global variables and functions that may conflict with Thinkific or other custom scripts.
Interactive components should support keyboard access, visible focus states, and appropriate accessibility attributes.
Errors should fail safely without preventing the rest of the page from loading.
Liquid & Thinkific Standards
Preserve native platform capability while improving the FEOS experience.
Identify whether functionality is native Thinkific, theme-controlled, or custom before modifying it.
Avoid removing native account, enrollment, commission, login, or support functionality unless an approved replacement exists.
Reusable Liquid markup should be placed in clearly named snippets rather than copied across multiple files.
Conditional logic should remain readable and should include sensible fallback behavior.
Theme changes should be tested in the development theme before production publication.
Naming Standards
Names should communicate purpose without requiring explanation.
FILES
Use clear, lowercase, hyphenated or platform-consistent file names.
SECTION IDS
Use unique descriptive IDs such as feos-executive-headquarters or kcrm-architecture.
CLASSES
Use meaningful reusable class names rather than appearance-only names.
COMPONENTS
Use approved terminology such as Mission Card, Progress Card, AI Guidance Panel, and Next Action Panel.
Responsive Engineering
Mobile behavior must be designed, not assumed.
Multi-column grids should stack into a logical reading order.
Fixed widths should be avoided unless an intentional scroll container is provided.
Buttons and links should have comfortable touch targets and adequate spacing.
Tables should use deliberate horizontal scrolling when they cannot be responsibly stacked.
Mobile screenshots should be reviewed before a page is considered complete.
Accessibility Engineering
Accessibility should be part of the build, not a later repair.
Use sufficient color contrast for text, buttons, status indicators, and navigation.
Provide meaningful alternative text for informative images.
Do not communicate status or meaning through color alone.
Preserve logical keyboard order and visible focus for interactive elements.
Use table headings, form labels, descriptive links, and semantic document structure.
Security & Data Protection
Custom development should not weaken platform security.
Never place passwords, private credentials, secret keys, or protected tokens inside page HTML or repository files.
Do not expose sensitive partner, contact, customer, or organizational data through client-side markup.
Validate external scripts, embeds, file hosts, and integrations before production use.
Respect FEOS permissions, assignments, and governance when displaying contextual information.
Minimize collection and exposure of personal information that is not required for the mission.
Use approved administrative processes for exports, deletion, reassignment, and sensitive record changes.
Performance Standards
Visual quality should not create unnecessary page weight.
Compress images before use and avoid loading oversized files into small display areas.
Avoid duplicate third-party scripts, libraries, fonts, and video players.
Use embedded media deliberately and avoid placing multiple auto-loading videos on one page.
Reuse shared styles instead of generating unnecessary repeated code whenever practical.
Test major pages on realistic mobile and desktop connections before release.
Technical Documentation
Code changes should leave behind enough information to be understood.
PURPOSE
What the file, component, or feature is designed to accomplish.
LOCATION
Where the implementation is stored and where it appears in Thinkific.
DEPENDENCIES
Theme files, scripts, snippets, resources, or settings required for operation.
VALIDATION
Desktop, mobile, browser, link, workflow, and production checks completed.
VERSION
The approved version, commit, sprint, or release associated with the change.
ROLLBACK
How the prior working version can be restored.
Testing Standards
A feature is not complete when the code is written.
01
Visual Review
Confirm layout, spacing, hierarchy, colors, and alignment.
02
Responsive Review
Test desktop, tablet, and mobile behavior.
03
Functional Review
Validate links, forms, buttons, navigation, embeds, and workflows.
04
Regression Review
Confirm the change did not break existing features.
05
Production Verification
Verify the published experience using an appropriate test account.
Engineering Definition of Done
Work is complete only when it is stable, verified, and preserved.
The implementation meets the approved architecture and technical specification.
Desktop and mobile views have been reviewed and corrected.
Links, buttons, workflows, embeds, and native Thinkific features function correctly.
Code has been placed in the appropriate repository location.
The change has been committed and synchronized through the approved Git workflow.
Documentation, sprint history, and rollback information have been updated.
Standards Governance
Engineering standards should evolve carefully.
New patterns should be evaluated against existing FEOS components before being approved.
Major technical changes should include rationale, impact, migration, testing, and rollback considerations.
Deprecated patterns should be documented and removed through controlled updates.
This document should be reviewed whenever FEOS introduces a new platform, framework, integration, or deployment method.
Strong engineering protects the mission from technical disorder.
The FEOS Engineering Standards ensure that Formationly can continue to grow with consistent code, reusable components, reliable testing, clear documentation, responsible governance, and a development foundation future contributors can trust.