LifeHub Information Architecture

# LifeHub Information Architecture

1. Purpose

This document defines how LifeHub is organized as a navigable system.

Its purpose is to ensure that LifeHub develops with a clear structure from top-level overview down to detailed records and actions.

The architecture should support:

• bird’s-eye visibility
• clean domain separation
• progressive drill-down
• modular expansion
• consistent navigation
• clarity between summary, management, and underlying data

2. Architectural Principle

LifeHub should be organized from broadest context to greatest detail.

A user should be able to move through the system in a logical sequence:

1. ecosystem-level awareness
2. domain-level awareness
3. entity or category awareness
4. operational detail
5. individual records and actions

This should reduce confusion and prevent unrelated information from being mixed together too early.

2A. Repository Boundary

The repository root is the technical container for LifeHub, not the operational workspace root.

• LifeHub/ is the operational workspace root.
• .git/, .github/, and .devcontainer/ belong to repository infrastructure, not the working hierarchy.
• Reference/ remains outside LifeHub/ as supporting material rather than active operational structure.

This separation keeps the working environment distinct from GitHub mechanics and reference storage without changing LifeHub's internal architecture.

3. Primary Domain Structure

At the highest meaningful navigation level, LifeHub is divided into five core domains:

1. Overview

The top-level ecosystem view.

Purpose:

• show the broad condition of the whole system
• surface major alerts
• summarize health, equity, progress, and status
• provide a starting point for drill-down

2. Business

The business domain.

Purpose:

• contain all business entities and business-related systems
• provide a business-level dashboard
• allow drill-down into individual ventures, entities, and business modules

3. Personal

The personal domain.

Purpose:

• contain personal finance, personal assets, liabilities, records, and life-management structures
• allow visibility into personal condition without blending it carelessly with business systems

4. Projects

The project domain.

Purpose:

• contain initiatives that are cross-domain, experimental, developmental, ambiguous, or not fully reducible to business or personal categories
• support tracking, planning, synthesis, and execution of initiatives in progress

5. Goals

The goals domain.

Purpose:

• contain overarching aims and directional objectives
• show progress toward those aims
• connect activity in the other domains to larger outcomes

These domains should remain distinct but interoperable.

4. Navigation Levels

LifeHub should generally be navigated through the following levels.

Level 1 — Main Menu / System Entry

The main starting point.

Purpose:

• present the major domains
• provide top-level orientation
• surface urgent notices where relevant
• provide the first branching point into the system

Typical destinations:

• Overview
• Business
• Personal
• Projects
• Goals

Level 2 — Domain Dashboards

The first major layer inside each domain.

Purpose:

• summarize the state of the selected domain
• show alerts, status, key metrics, and important navigation options
• make the domain understandable before entering detail

Examples:

• Overview dashboard
• Business dashboard
• Personal dashboard
• Projects dashboard
• Goals dashboard

Level 3 — Subdomain / Entity Views

The next drill-down layer.

Purpose:

• separate a domain into meaningful sections, entities, or categories
• provide visibility into the major components of that domain

Examples:

• Business → Boothly / Style Studio / Mongu Meal / other entities
• Personal → Accounts / Assets / Liabilities / Collections / obligations
• Projects → individual active projects
• Goals → strategic goal categories or milestones

Level 4 — Operational Views

The layer where day-to-day management becomes more visible.

Purpose:

• show actionable operational detail
• expose status, tasks, reporting, schedules, requests, notices, and health indicators
• help the user understand what is happening and what needs response

Examples:

• business entity dashboard
• project execution dashboard
• personal finance detail panel
• progress view for a specific goal

Level 5 — Records, Logs, Forms, and Actions

The deepest regular working layer.

Purpose:

• show underlying records
• allow entry, editing, review, and confirmation of detailed information
• support actual operational actions

Examples:

• report entries
• account records
• transaction logs
• task records
• request logs
• schedule entries
• notes
• forms
• source data tables

This level should support action without losing the context of the higher levels above it.

5. Relationship Between Levels

Each level should act as a contextual wrapper for the one below it.

This means:

• the main menu should orient the user before domain entry
• the domain dashboard should orient the user before entity or category entry
• the entity or subdomain view should orient the user before operational detail
• the operational view should orient the user before individual records and actions

The user should not feel abruptly dropped into detail without understanding where they are in the system.

6. Business Domain Architecture

The Business domain should generally follow this structure:

Business Domain

• overall business dashboard
• top-level business metrics
• business alerts and notices
• business schedule and obligations
• access to entities and business modules

Business Entities

Each business should be treated as a drill-down unit with its own view.

Examples:

• Boothly
• Style Studio
• Mongu Meal
• future ventures

Entity Dashboard Layer

Each entity dashboard may contain:

• health/status
• reporting status
• key metrics
• accounts or balances
• inventory or operational indicators
• schedule
• tasks
• requests
• alerts

Entity Detail Layer

Deeper views may expose:

• daily reports
• account-level details
• inventory/resource data
• operational logs
• staff or operator records
• detailed schedules or obligations

The business domain should support both comparison between entities and drill-down into a single entity.

7. Personal Domain Architecture

The Personal domain should generally follow this structure:

Personal Domain

• personal dashboard
• equity and debt overview
• urgent notices
• personal schedule
• major categories of personal resources and obligations

Major Personal Categories

Possible categories include:

• accounts
• liquid funds
• assets
• liabilities
• credit
• collections
• obligations
• records

Personal Detail Views

Each category may drill into:

• individual accounts
• assets by type
• debts and obligations
• collections by person or source
• supporting records
• historical changes

The personal domain should remain clear, private in logic, and distinct from business reporting unless intentional crossover is defined.

8. Projects Domain Architecture

The Projects domain should generally follow this structure:

Projects Domain

• active projects overview
• project health/status
• upcoming deadlines
• strategic or operational relevance
• urgent notices

Individual Project Views

Each project may include:

• summary
• current stage
• next actions
• dependencies
• outputs
• supporting notes or files
• related assets or specifications

Project Detail Layer

Possible detail areas:

• synthesis files
• working models
• generated assets
• specs
• implementation steps
• review notes

This domain should support projects that are:

• experimental
• developmental
• ambiguous
• cross-domain
• not yet formalized into an entity

9. Goals Domain Architecture

The Goals domain should generally follow this structure:

Goals Domain

• overview of major aims
• progress visibility
• strategic direction
• major blockers
• important milestones

Goal Categories or Tracks

Goals may be grouped by:

• domain
• timeframe
• strategic area
• stage of progress

Goal Detail Views

Each goal may include:

• definition
• current status
• milestones
• supporting projects
• linked business or personal relevance
• progress indicators
• outstanding blockers or tasks

The goals domain should serve as a directional layer, not merely a decorative one.

10. Overview Domain Architecture

The Overview domain is the highest system-level summary layer.

It should generally contain:

• ecosystem-wide health
• overall equity or major value indicators
• broad income/profit or movement indicators
• major alerts
• urgent notices
• high-level schedule items
• direct links into the major domains
• summary health of major business entities or other critical areas

The Overview domain should not try to contain every detail. Its role is to orient, summarize, and point.

11. Cross-Domain Design Patterns

Even though domains differ, the system should use shared patterns where appropriate.

Common patterns may include:

• health/status blocks
• urgent notices
• schedule sections
• task sections
• request sections
• metrics sections
• summary cards
• drill-down links
• alerts and watch indicators

This supports consistency and reduces mental friction.

12. Information Boundaries

LifeHub should preserve clean boundaries between:

• summary and detail
• overview and management
• business and personal
• project and entity
• goal and task
• dashboard and source record

These boundaries matter because they keep the system legible.

Cross-links should exist where useful, but boundaries should not collapse.

13. Expansion Rules

As LifeHub grows:

• new modules should fit into existing navigation levels where possible
• domain sprawl should be avoided
• one-off additions should not break overall coherence
• every new major area should have a clear parent context
• deeper layers should only be introduced when needed

Growth should happen through organized expansion, not accumulation of scattered views.

13A. Implementation Boundary

Implementation work should preserve the same structural boundaries as the rest of LifeHub.

• Root LifeHub/06_apps is for shared or cross-project implementations.
• Project-owned implementations belong in LifeHub/02_projects/<Project>/05_apps/.
• App-bearing projects should initialize 05_apps/ from LifeHub/03_systems/App_Development_Template/ rather than leaving it flat.
• 04_specs/ defines the intended system, business logic, flows, and acceptance criteria.
• 05_apps/ implements the system through planning, source, docs, and ops layers.
• 06_outputs/ stores shipped, reviewable, or exported results.
• Implementation should follow approved specs and project boundaries rather than bypassing them.

14. Architectural Summary

LifeHub should be structured as a drill-down system with five major domains and multiple navigation levels.

Its architecture should help the user move from:

• system awareness to
• domain understanding to
• entity/project/category visibility to
• operational clarity to
• record-level action

The information architecture should make LifeHub feel coherent, navigable, and useful at every level of depth.