> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://triton.pharos.ai/core-concepts.md).

# Core Concepts

The mental model behind Pharos Triton — how the static logger, builder, templates, buffering, and transactions fit together before you write any logging code.

Before we get into batch jobs, LWC, Flows, and the finer points of taxonomy, it's worth spending a few minutes on the mental model. Triton is small on purpose — once these five ideas click, everything else in the docs is just a variation on them.

Here's the whole framework in one breath: **you describe a log with a builder, you hand that builder to `Triton`, and `Triton` keeps the running state of your transaction — the buffer, the transaction id, your template — statically, for the life of the Apex transaction.** That's it. The rest is detail.

## The five ideas

| Concept                     | One-liner                                                                                      | Read next                                                                         |
| --------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| **The static API**          | You call `Triton` directly — `Triton.info(...)`, `Triton.error(...)` — no instances to manage. | [The Static Logging API](/core-concepts/static-logging-api.md)                    |
| **The builder & templates** | A fluent `TritonBuilder` describes one log; a template stamps shared fields onto all of them.  | [The Builder & Templates](/core-concepts/builder-and-templates.md)                |
| **Log levels**              | Levels rank severity and let you tune verbosity per environment without touching code.         | [Log Levels](/core-concepts/log-levels.md)                                        |
| **Buffering & flushing**    | Logs queue in memory and publish in bulk, so you don't burn platform-event allocations.        | [Buffering, Flushing & Deferred Publishing](/core-concepts/buffering-flushing.md) |
| **Enums**                   | `Category`, `Type`, and `Area` classify every log so it's filterable and analyzable later.     | [Enums](/core-concepts/enums.md)                                                  |

## A first log

Here's what a complete, buffered log looks like in Triton 2.0:

{% code lineNumbers="true" %}

```apex
Triton.log(Triton.makeBuilder()
    .category(TritonTypes.Category.Apex)
    .type(TritonTypes.Type.Backend)
    .area(TritonTypes.Area.Accounts)
    .summary('Recalculated account rollups')
    .level(TritonTypes.Level.INFO));

Triton.flush();
```

{% endcode %}

Three moves, every time:

1. **Build** the log with a builder (`Triton.makeBuilder()` gives you one, pre-set to the `Apex` category).
2. **Hand it to `Triton`** — here `Triton.log(...)` adds it to the buffer.
3. **Flush** when you're ready to publish. (Need it persisted immediately? Use `Triton.logNow(...)` and skip the separate flush.)

If that looks like more ceremony than you want to repeat, good — that's exactly what [templates](/core-concepts/builder-and-templates.md) and the [convenience level methods](/core-concepts/static-logging-api.md) are for. The example above collapses to a one-liner once you've set a template:

{% code lineNumbers="true" %}

```apex
Triton.info(Triton.t.summary('Recalculated account rollups'));
```

{% endcode %}

## Where to go next

If you like learning top-down, read the five pages above in order — each builds on the last. If you'd rather learn by doing, jump straight to your context: [Logging in Apex](/common-apex-usage-patters.md), [Logging in LWC](/beyond-apex/lwc.md), or [Logging in Flow](/flows.md).