The single source of truth for well construction data.

What AURA gives every kind of user

One platform, multiple front doors — a portal for day-to-day users, an admin console for platform operators, automated data-quality monitoring that runs without anyone watching, and a notification layer that reaches ops before they have to ask.

Access control isn't just role-gated pages — it goes down to the individual field, with locked-field enforcement covered in Chapter 09 — Data Governance.

Where the data lives, and what moves it.

AURA is a small set of services around one PostgreSQL database — a public API, an admin API, an import engine, and a cache — behind a single gateway. The interesting part is the edge, where agents inside the customer network let AURA reach systems it can't directly see.

The runtime, in one picture

One entry point, a handful of services, and one database that everything reads from and writes to — the same aura_data table the next chapter unpacks in full.

The edge: reaching systems AURA can't see

The architecturally interesting part isn't the database — it's the edge. AURA never bridges into the operator's network. Instead, a lightweight agent runs inside the customer's VDI (on the operator's VDI), pulls what AURA needs from systems like Well Data Master's Oracle database, and pushes results back out. AURA initiates nothing behind that boundary; the agent always calls out, never the other way around.

And the platform documents itself

The diagram above isn't a slide someone drew once and forgot — AURA's own admin console generates the same picture live, straight from its running services.

Add a new data source with zero code and zero migration.

AURA's core architectural bet: one physical table, one JSONB column, config-driven ingestion. A brand-new Operations Reporting System vista can be live and serving BI reports in under an hour, because there is no Python to write and no schema to migrate — only JSON to edit.

Sources → the aura_data table → consumers

Config, not code — the 5-step workflow

Adding a new Operations Reporting System vista (example: miestacion) never touches Python. Edit JSON, pre-create the partition, deploy the config, trigger an import — the data is live the same minute.

{
  "endpoints": [
    ...
    {
      "path": "/api/vistas/miestacion/",
      "data_type": "miestacion",
      "id_field": "miestacionid",
      "last_updated_field": "lastmodificationdate",
      "initial_suffix": "pagina",
      "incremental_suffix": "modificados-desde",
      "query": { "size": 1000 },
      "limit": 1000,
      "categories": ["data_priority"] // HIGH_PRIORITY or optional
    }
  ]
}

Five patterns that make this work

The Ledger in action — auditing time & money

When a BI number looks wrong at 7 AM, the ledger shows precisely which records hadn't arrived yet, when they did, and what they changed — because every record keeps its full timing history, not just its latest value.

One trigger. Many systems.

AURA is becoming the automation core of the operator's well-construction stack: an event in one system — an AFE created, a scheduled sync tick, a field update landing in Operations Reporting System — automatically configures, populates, or refreshes the others. No one re-types the same well into three different screens.

A · The AFE cascade

When the operator creates a new AFE, AURA fans that single event out to the Corporate ESB, Operations Reporting System, completions staging, notifications, and BI — work that used to mean manual entry into 3+ systems now happens in the background within 15–60 minutes.

Each branch, in detail

B · Well Data Master read → create well (D1)

Five times a day, a VDI agent reads the operator's Well Data Master Oracle master and syncs it into AURA — keeping field, area, and well-status attribution current on all 6,575 active wells without anyone running a manual export.

C · Update Well Data Master operation dates (D2 write-back)

Chained right after the D1 read on the same cron tick, AURA writes field-sourced dates and survey depths back into Well Data Master — guarded by an idempotency ledger and a no-downgrade rule so a stale or shallower survey can never overwrite a better existing value.

D · Well File System push for Daily Events Viewer

Every 15 minutes, a VDI agent pulls pending wells, events, and operations from AURA and pushes them into the Well File System — feeding the Daily Events Viewer, the daily drilling dashboard that consolidates reports, activities, and contractor performance.

Proof: this is running, not a plan

Every automation in this chapter is backed by a live scheduled job on the AURA platform — not a diagram of an intention. The Services panel shows roughly 35 systemd services with real-time health, and System Status confirms the integrations themselves are reachable.

12 systems, one platform

AURA doesn't just store data — it's the hub connecting Analytics, Operations Reporting System, Well Data Master, Well File System, FARO, Themis, TPO, Projects, and more. Click any card to see how data actually moves in and out.

34 endpoints, one consistent contract

Built for the consumers that matter: BI dashboards and UTF template exports. Every endpoint — reporting, completions, drilling, AFE — shares the same auth model, the same query parameters, the same metadata envelope, and the same four output formats. Learn the pattern once, integrate any BI tool or script the same way.

The endpoint surface, by domain

Reporting carries most of the surface area — financial reports, operational timelines, and well metadata. Completions covers frac/wireline stage tracking and 10-second telemetry. The remaining domains are narrower, purpose-built endpoints.

Anatomy of a request

One annotated example teaches the whole contract: standard query parameters, the __aura_* metadata envelope on every record, and a consistent top-level metadata block.

# Real request — costos_mensuales, formatted for BI consumption
GET /reporting/costos_mensuales?start_date=2026-03-01&output_format=parquet&field_template=BI
Authorization: Bearer <jwt_or_api_key>

{
  "data": [
    {
      "pozo": "W-1606",
      "mes": "2026-03",
      "monto_total": 184230.55,
      // stable BI merge key — integer, unique-per-row
      "__aura_external_id": 88213041,
      "__aura_data_source": "ops-reporting",
      "__aura_last_updated": "2026-07-14T06:02:11-03:00",
      "__aura_active": "active"
    }
  ],
  "metadata": { "count": 100, "total_records": 100, "timestamp": "2026-07-14T10:30:00-03:00" }
}

Quality isn't a phase — it's a process that runs every 5 minutes

AURA ships with a testing and monitoring framework sized to match its data surface: 1,626 unit tests gate every commit, a smoke suite gates every deploy, a 3,500-test combinatorial sweep runs daily against every endpoint, and continuous monitors watch imports, locks, and health around the clock.

Four cadences, one framework

Fast checks run on every commit; slower, wider checks run less often but cover more ground. Together they read as a single sentence: every commit, every deploy, every day, every five minutes.

That continuous layer runs at two levels: inside AURA (import-lag, database-lock contention, endpoint health, and data-quality scans, all reporting to FARO) and outside it, where the RCI Monitor platform watches the host itself — services, disk, memory, load, and SSL expiry. A failed sync and a failing server both page the team before users notice either one.

The CI/CD gate pipeline

Every push and pull request runs the same sequence of gates, in order — all must pass before merge.

The data is governed, not just stored.

Governance in AURA is three disciplines working together: authoritative masters, enforced safeguards, and a complete audit trail — so the data can be trusted independent of whichever technology happens to move it.

A · Masters — one authoritative source per entity

Every governed entity has exactly one system of record. AURA doesn't compete with that authority — it observes it, mirrors it faithfully, and gives operators a single place to manage the master data everything else depends on.

B · Safeguards — the data protects itself

Where AURA is not the system of record, it writes back carefully — guarded, staged, and reversible — and where a field is sensitive, access can be locked down to that single field without touching anything else on the record.

C · Audit — who did what, when

Every request is logged, every field-level change has history through the Ledger, and three dedicated admin views turn that raw log into something an operator can actually use.

Three more admin views turn that raw log into governance: Audit Performance tracks the audit system's own health, Usage Analytics shows who is calling which endpoints (Chapter 07 covers the volume side — 99,940 requests and 98.6M records served in 30 days), and API Traces gives a request-by-request drill-down when something needs investigating.

Why operators choose AURA

Everything in this presentation is running in production today, over 280M+ records at a major energy operator. This is what that buys — and how to see it against your own wells.

What an operator gets

The numbers behind the claims