> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.orbitdev.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Pulsar Models
> Pulsar is the intended name for Orbit's model-development direction, covering the full model lifecycle from data preparation through evaluation and serving.
Pulsar is the intended name for Orbit's model-development direction. The objective is to understand and build model systems, not merely place a new label on an unrelated service. The scope of that work may evolve as resources, evaluation results, and engineering capacity become clearer.
*Illustrative scientific image. It does not represent a measured Pulsar model architecture or benchmark.*
## 6.1 Model-development lifecycle
A responsible model lifecycle includes several stages:
**Data selection and preparation.** Define data sources, permitted uses, quality criteria, privacy constraints, and filtering procedures. Keep a record of dataset versions and processing steps.
**Tokenization and representation.** Select and test the method used to convert input text or other modalities into model-ready representations. Tokenizer changes can affect compatibility and evaluation.
**Architecture and training.** Choose a model architecture and training objective that match the available hardware, data, and intended use. Record the configuration, random seeds where applicable, software versions, and resource use.
**Checkpointing and recovery.** Save model weights and training state in a controlled format. Test that checkpoints can be restored rather than assuming that a successful save means a usable checkpoint.
**Evaluation.** Test capabilities, failure modes, robustness, safety, and performance on held-out data. Avoid relying on a single benchmark or cherry-picked demonstration.
**Inference and serving.** Measure latency, throughput, memory use, stability, and cost under realistic workloads. Provide clear error handling and usage limits.
**Release and monitoring.** Document the model's intended use, known limitations, version, and evaluation results. Monitor failures and maintain a process for updates or withdrawal.
## 6.2 Model variants
If Pulsar develops into a family of models, each variant should have a defined role. Possible categories include:
* **Compact models:** lower resource requirements for local use or narrow tasks.
* **General assistant models:** broad language and reasoning support.
* **Coding-focused models:** assistance with programming tasks and repository context.
* **Multimodal models:** models that process more than text, if and when the relevant capabilities are implemented.
* **Research checkpoints:** experimental versions that are not intended for ordinary production use.
These are possible categories, not a statement that each variant currently exists. Names, sizes, modalities, and release commitments should be published only after they are verified.
## 6.3 Evaluation philosophy
A model should be evaluated against the job it is expected to perform. Relevant dimensions may include:
| Dimension | Example evaluation question |
| - | - |
| Instruction following | Does it respect explicit constraints? |
| Factuality | How often does it provide unsupported claims? |
| Reasoning | Can it solve defined tasks consistently? |
| Coding | Do generated changes compile and pass relevant tests? |
| Tool use | Does it choose and call tools correctly? |
| Robustness | Does performance degrade under confusing inputs? |
| Safety | Does it handle high-risk requests within policy? |
| Efficiency | What quality is achieved per unit of compute? |
| Reliability | Does the service remain stable under expected load? |
Evaluation reports should describe the test set, scoring method, sample size where relevant, known limitations, and comparison conditions. Numbers without methodology are decoration.
## 6.4 Training infrastructure
Training requires more than a GPU and a script. A practical research environment needs data validation, reproducible configurations, checkpoint recovery, experiment tracking, memory planning, and a way to compare runs.
Small local hardware can be useful for learning, tokenizer experiments, debugging, and modest training jobs. It is not a substitute for the compute, data quality, and engineering needed for frontier-scale training. A credible program should scale from small reproducible experiments instead of pretending hardware limits are a mindset problem.
## 6.5 OpenAI-compatible interfaces
Where useful, a Pulsar serving endpoint may support request and response formats compatible with established API conventions. Compatibility should be tested and documented rather than inferred from similar endpoint names. Differences in streaming, tool calling, errors, token accounting, and model behavior must be disclosed.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.