I. Operating Philosophy: Precision Without Entanglement
Lukul is designed around the realities of serious coaching: a plan is not the same as a completed session, a moved training day is not the same as rewritten programming, and a dashboard is not the source record. The system separates these responsibilities so each surface can stay precise without flattening the coaching process into one generic tracker.
[ CLEAR ROLES ]
Planning intent, schedule context, execution history, nutrition and cardio context, advisory insight, dashboards, and exports are treated as distinct responsibilities within one coaching product.
[ RECORDS BEFORE VIEWS ]
Dashboards and analytics are derived views. They help people understand the work without being confused for the source records they summarize.
II. The Prescription / Execution Divide
Planned work defines coaching intent. Logged work captures what actually happened. Lukul keeps those lanes deliberately separate so historical records remain stable and coaches can compare prescription to reality without losing either side of the story.
[ AUTHORED INTENT ]
Planning surfaces express what the coach intends for a block, week, day, or session. That intent remains readable as a plan, even when real life later changes the order or timing of the work.
[ PERFORMED REALITY ]
Execution history records the completed session, actual inputs, notes, adjustments, and final state. It is not treated as a temporary echo of the plan.
III. The Schedule Layer
Real clients move days. Travel, fatigue, missed sessions, and ordinary life all disrupt a clean calendar. Lukul treats movement as part of the schedule layer, not as an accidental rewrite of coaching intent.
[ SCHEDULE CONTEXT ]
Moving a session is handled as scheduling context. The product can reflect what changed without pretending the original plan was authored that way.
[ PLAN PRESERVATION ]
This distinction helps coaches understand the authored program, the lived calendar, and the eventual execution history as related but different records.
IV. The Training Runtime
The training experience is designed for mobile, in-session use: fast enough for the gym floor, clear enough to compare planned and actual work, and deliberate where the user is committing important records.
[ FAST INPUT ]
Logging supports the practical shape of a session: planned work, actual performance, rest, notes, changes, and session state. The interface favors short interactions while training is happening.
[ INTENTIONAL CONFIRMATION ]
Lukul uses low friction where speed matters and deliberate friction where finalization matters. Important commits should feel intentional, not accidental.
Mobile-first logging | Planned vs actual clarity | Session notes and rest context
Fast entry during work | Deliberate confirmation at completion
V. Context Sovereignty
Coach workflows require context clarity. Lukul separates the acting user from the client context being viewed or managed, reducing the risk of cross-client contamination and keeping sensitive actions anchored to the correct relationship.
[ ACTING USER ]
The product distinguishes who is taking an action from whose coaching context is currently being viewed. Coach, client, and self-managed flows are kept legible.
[ CLIENT CONTEXT ]
Direct access, account flows, and sensitive actions are treated as context-aware operations. The public overview stops at principles and does not disclose private access internals.
VI. The Advisory Layer
Advisory intelligence helps summarize and interpret coaching context. It is assistive by design: it can support review, pattern recognition, and decision preparation, but it does not replace source records or the coach's judgment.
[ CONTEXTUAL SUPPORT ]
Advisory output can help surface patterns across training, nutrition, cardio, and adherence context while staying tied to the records and inputs available to the product.
[ RECORDS REMAIN RECORDS ]
Plans, execution history, nutrition and cardio logs, account data, and coach-client context remain the operational records. Advisory text is interpretation, not the canonical source.
Interpret context | Summarize signals | Support decisions
Does not replace source records, coach judgment, or user-entered history
VII. Controlled Data Movement
Import, export, account, and data flows are handled as controlled operations. Lukul treats data movement as part of the product's trust model, not as a casual dump or an invisible overwrite.
[ STRUCTURED ENTRY ]
Incoming information is brought in through intentional flows. It should not silently become an operational record unless that operation is designed for the role it is taking.
[ PORTABLE CLARITY ]
Exports are shaped for review, handoff, and operational clarity so coaches and clients can move information without losing the difference between source records and derived views.
VIII. Designed for Continuity
The architecture is intentionally modular in the product sense: new coaching surfaces can be added without erasing the distinction between intent, movement, execution, and interpretation. This gives Lukul room to grow while keeping the user-facing experience coherent.
[ LONG-TERM FIT ]
Planning, scheduling, logging, dashboards, nutrition, cardio, advisory intelligence, and data portability can deepen over time without collapsing into a single undifferentiated workflow.
[ OVERVIEW ONLY ]
This page describes architectural principles for a public audience. It intentionally avoids private implementation details, internal data structures, and proprietary analytical logic.