A curated look at the products, systems and experiences we shape — from strategy and design through engineering, launch and long-term refinement.
Current stage: PTE learning product direction
A dedicated PTE learning experience for Speaking, Writing, Reading and Listening — with exam-style practice, mock tests, targeted AI feedback and clear next steps for improvement.
Explore the story
Current stage: Research and engineering foundation
A language-model project exploring the foundations of training, evaluation and more capable AI for real-world applications.
Explore the story
Current stage: Personal product concept and system blueprint
A personal command center designed to orbit around the person — connecting day planning, tasks, calendar, finance, habits, journaling and the bigger rhythm of months and years.
Explore the story
Learning. Intelligence. Everyday life.
Each product explores a different way technology can make the world more capable.
A dedicated PTE preparation environment built around the student’s real loop: understand the task, practise it, receive specific feedback, recognise the pattern behind a mistake and choose the next useful exercise.
Preparation resources can become fragmented across notes, sample questions, score screenshots and generic advice. A student may practise repeatedly without being able to tell which skill is limiting performance, whether a response matched the task and what to do differently next time. The product needs to connect instruction and practice without implying that AI feedback is an official PTE score.
PTE Academic candidates with different starting abilities, target scores, schedules and confidence levels. The system should help a new learner understand task demands while also giving a returning learner a faster route to weak-area practice and progress review.
After each attempt, a student should understand what happened, what can be improved, why it matters and which next practice step is worth taking.
The current direction is a focused PTE course with its own learning assistant. Any automated score or feedback must be clearly identified as guidance or an estimate unless an authoritative scoring source is explicitly available; student data and recordings require deliberate privacy, retention and consent design.
Students need more than a large bank of questions. They need the relationship between a task, the response they produced, the criteria that matter and a specific next action. The design starts with that feedback loop and gives practice a clear purpose instead of treating every exercise as an isolated activity.
Some learners are learning task formats for the first time; others know the structure but need targeted improvement, greater consistency or better time management. The experience should let a learner set a target and see a useful next step, while keeping explanations readable and allowing deeper guidance when requested. No single study schedule or skill diagnosis should be imposed on every student.
These are connected parts of the product direction; each should be specified and validated before being described as production-ready.
The build sequence is designed to test the learning logic early, then extend it task by task.
An evolving language-model initiative focused on the foundations that make experimentation repeatable: tokenization, corpus preparation, model configuration, training, checkpoints, evaluation and careful iteration.
A language model is not built by architecture code alone. Training results depend on data quality, tokenizer behaviour, configuration, resource constraints, checkpoint integrity, evaluation and reproducibility. Without a dependable loop, it is difficult to distinguish a genuine model improvement from a data, code or measurement problem.
The primary users are the builders and researchers developing, training and evaluating the model and its supporting tools. Future application developers may consume model capabilities later, but access patterns and product claims should follow measured behaviour rather than assume a capability exists before it is tested.
Every experiment should be reproducible enough to explain what was changed, what was measured, what improved or regressed and whether a checkpoint is safe to keep.
This case study describes an evolving R&D foundation, not a claim that the model matches mature commercial systems. Model size, training progress, benchmark results and capabilities should be published only with run-specific evidence and clear evaluation methodology.
Training can consume scarce compute for a long time, making hidden failures costly. Data, tokenizer, sequence length, architecture, optimizer, schedule and checkpoint state must agree. A good engineering foundation makes configuration explicit, saves recoverable state, logs useful metrics and makes a run understandable after interruption.
The model lifecycle begins before the first training step. Corpus quality, duplication, document boundaries, token distribution and dataset splits affect what the model learns. Tokenization and block preparation need validation, while training metrics and checkpoint metadata help connect observed behaviour to a specific run.
These components form a chain; an issue upstream can look like a model problem downstream, so each layer needs independent checks.
Each phase produces traceable evidence that helps make the next training decision defensible.
Orbit is a personal operating space for days, months and years—connecting tasks, calendar, finance, goals, habits and journal in a single place that revolves around the person rather than making the person orbit separate apps.
Everyday life is often split across tools: one for money, another for tasks, another for notes, another for appointments and another for reflection. This fragmentation creates repeated entry, disconnected context and a weak relationship between what someone planned, what they did and how the month or year is unfolding.
People who manage several responsibilities and want a coherent view of personal time, priorities, finances and reflection without being forced into an overly complex productivity methodology. The product should accommodate different routines, levels of detail and changing life circumstances.
A person should be able to open Orbit and understand today, choose the next meaningful action, see the commitments around it and connect daily choices to their broader month and year.
Orbit is a product direction, not a claim that all integrations or tracking features are live. Finance connectivity, reminders, device sync, storage and privacy guarantees must be scoped and tested before they are presented as deployed capabilities.
A calendar can show time without explaining priority; a task list can show work without showing the day around it; a finance tool can track transactions without connecting them to goals or reflection. Orbit starts from the person’s need to move between these views without losing the larger picture or repeatedly rebuilding context.
Orbit should be flexible enough to reflect how someone actually organises life, while providing a dependable shared structure. It should not force every person into a rigid productivity method. The home view brings today’s commitments and next actions forward, while deeper views let the user plan across weeks, months and years when that horizon is useful.
The product becomes useful when each area contributes to the whole without turning the home screen into a wall of widgets.
The project should validate the daily core loop before layering on every life-management feature.
