Aptli

How Aptli Fits Together

Before you touch any single page, it helps to see how the pieces relate. Almost everything in Aptli hangs off one spine: a project holds jobs, each job has a material side and a work side, and both sides come back together in a report that a validation signs off on. Inventory moves underneath all of it.

This page is the map of that spine. Every box here has its own detailed guide later — this is just how they connect.

The big picture

                          ┌─────────────┐
                          │   PROJECT   │   optional umbrella
                          └──────┬──────┘
                                 │  groups many
                                 ▼
                          ┌─────────────┐
                          │     JOB     │   one unit of planned work
                          └──────┬──────┘
                ┌────────────────┴────────────────┐
                │                                  │
         MATERIAL stream                      WORK stream
       "what gets used"                    "what gets done"
                │                                  │
                ▼                                  ▼
       ┌─────────────────┐               ┌──────────────────┐
       │ Resource lines  │               │   Work Orders    │
       │   on the job    │               │  (the dispatch)  │
       └───────┬─────────┘               └────────┬─────────┘
               │                                  │
        ┌──────┴───────┐                  ┌───────┴───────┐
        ▼              ▼                  ▼               ▼
   Registered      Ad-hoc           Registered        Ad-hoc
   RESOURCE      (typed in by      ACTIVITY         (typed in by
  (from your       hand, not       (from your        hand, not
   catalogue)     registered)       catalogue)       registered)

The shape repeats deliberately. Both streams give you the same choice: pull from a catalogue of registered things, or type something in ad-hoc. You are never forced to pre-register everything to get work moving.

A project holds jobs

A project is an optional umbrella — a campaign, a site rollout, a phase of work. It groups related jobs and rolls their progress up so you can watch the whole effort in one place.

A job does not have to belong to a project. Plenty of work is a one-off job with no umbrella. The project is there when you want the rollup, not as a hoop to jump through.

A job has two streams

A job is the core unit of planned work. Think of it as having two independent sides:

Material sidewhat the work consumes. These are the resource lines on the job: the cable, the screws, the adhesive, the labour hours. Work sidewhat actually gets done. This is dispatched as work orders, each carrying an activity (the splice, the inspection, the dig).

The two streams run in parallel and don't depend on each other. A job can have material with no formal activity, or an activity with no tracked material. You add structure to each side only where it earns its keep.

Registered vs. ad-hoc — the recurring choice

On both streams you pick one of two paths for every line:

  • Registered — chosen from a catalogue you maintain (Resources for materials, Activities for work). Registering buys you consistent names, units, stock tracking, and pickup rules.
  • Ad-hoc — typed in by hand, on the spot. Nothing pre-registered. Use it for the one-time material or the unusual task that isn't worth a catalogue entry.

The same record can mix both. This is the "looser reference system" — registration is an option that adds tracking, never a gate that blocks work.

Both streams meet in a report

Planning describes what should happen. A report captures what actually happened — and it's where the two streams converge:

        WORK stream                       MATERIAL stream
            │                                   │
     work performed                     material consumed
   (against the activity)              (against the resources)
            │                                   │
            └────────────────┬──────────────────┘
                             ▼
                        ┌─────────┐
                        │ REPORT  │   what was actually done + used
                        └────┬────┘
                             ▼
                      ┌──────────────┐
                      │  VALIDATION  │   sign-off
                      │  pass / fail │
                      │  needs-revision / approved-with-notes
                      └──────────────┘

A report records the work completed and the material consumed in one place. A validation is the quality gate on top of it: a reviewer signs off with a status, and that status is what releases the work as accepted. Reports and validations are the audit trail of the job — they stay on the record even after the underlying infrastructure changes.

Validations aren't a separate menu item. They live as traffic-light badges on the Reports page — click a badge to view, edit, or create a validation without leaving the report.

The inventory side

Everything on the material stream is backed by an inventory ledger. The Inventory menu has four views, and they relate to each other like this:

   RESOURCE  ──┐
  (what it is, │
   the         ├──►  STOCK ITEM   the live balance:
   catalogue)  │    "X of this resource, at this site"
               │           │
   SITE  ──────┘           │ every change is written as a
  (where stock lives:      ▼
   warehouse, depot,  TRANSACTION   receipt · transfer · pickup ·
   or a person)                     consumption · adjustment · return
  • Resource — the catalogue entry: what the material is (also covered above as the registered material option).
  • Site — a place that holds stock. A location (warehouse, depot, field site) or a personal site (a worker's own inventory).
  • Stock Item — how much of a given resource sits at a given site. The balance only ever changes through a transaction.
  • Transaction — the immutable record of every movement in or out. This is the audit trail; you correct mistakes by adding an adjustment, never by editing history.

What happens to consumed material

When a report says material was used, that consumption doesn't just vanish from a form — it moves real stock. Consumed material goes one of two ways:

   ┌──────────┐   consumed       ┌────────────────────────────┐
   │   SITE   │ ───────────────► │ Used up at the job          │
   │ (stock)  │                  │ Gone — but recorded forever │
   └────┬─────┘                  │ as a consumption record     │
        │                        └────────────────────────────┘
        │ transferred / picked up
        ▼
   ┌──────────────┐
   │ Person or    │   Carried out as tracked inventory —
   │ another site │   still on the books, just moved
   └──────────────┘
  • Consumed at the job — the material is spent. The stock balance drops and a permanent consumption record is written. You can't erase usage; corrections are made by adding an adjustment, never by deleting history.
  • Pulled out of the site as tracked inventory — the material leaves the warehouse but isn't gone. It's transferred to another site or picked up by a worker, so it stays on the books in a new location until it's actually used.

Either way, the inventory ledger always reconciles: stock that left a site was either consumed or is now sitting somewhere else that the system can point to.

Putting it together

A typical flow, end to end:

  1. Plan — create a job (optionally under a project). Add resource lines for the materials and dispatch work orders with their activities.
  2. Authorize & pick up — workers draw the registered materials they need from a site.
  3. Do the work — out in the field, against the work order's activity.
  4. Report — capture the work completed and the material consumed.
  5. Validate — a reviewer signs off, which accepts the work and finalizes the consumption.

Where to go next

Each box on this page has a full guide:

Three menu items sit alongside this spine rather than inside it:

  • Home — a dashboard of progress and inventory rollups across everything above.
  • Field Records — the map. Jobs and features have a geographic presence there; see Map Concepts.
  • Help Requests — ask for and track support on any record.

Next up: Who Can See and Change What — how Aptli decides what each person is allowed to view and edit.