The Three-Ledger Methodology

An implementation methodology for industrial operational data substrates: ledgers that only append, derivations versioned by methodology, and exports attested cryptographically.

1. Executive summary

This methodology defines an industrial operational data substrate built on three commitments. The first commitment is ledgers that only append: every observation, every derived value, and every administrative act is written once and never rewritten. Corrections are new entries that reference the entries they correct. The second commitment is derivations versioned by methodology: derived values like allocations, accruals, reconciliations, and KPI rollups are computed under an explicitly versioned methodology specification, and a new version of that specification produces a parallel track of derivations alongside the old one. The historical track is never overwritten. The third commitment is exports attested cryptographically: every export of operational or derived data carries a verification artifact that the recipient can validate independently of the platform that produced it.

The substrate runs in a topology of two tiers. A field tier sits on the operating site and consists of an intelligent software agent on site, running on a dedicated hardware kit; that agent decodes site protocols, preserves provenance at the moment of capture, and continues operating during cloud disconnection. A cloud tier holds the ledgers, the cryptographic notary, the long-term archive, the exchange surface for downstream consumers, the identity registry, and the machinery for conflict resolution. The two tiers communicate over an application protocol agnostic of the transport, carried on whatever physical link the site provides.

The substrate keeps three ledgers, kept distinct. The operational ledger records what was observed: sensor readings and operational events that arrive from outside the system. The derivations ledger records what was concluded: values computed inside the system under a methodology specification. The audit ledger records what was done to the system itself: configuration changes, authorizations, methodology transitions, exports. The disciplines that govern those three ledgers are commutatively distinct, and conflating them, as most platforms do, is the root cause of the four pathologies described in section 2.

2. The problem

Industrial operational data platforms exhibit, with depressing regularity, four pathologies that this methodology is engineered to eliminate.

2.1 Immutable provenance, mutable methodology

Operators correctly insist that the raw observation record is sacred: no one rewrites a sensor's voltage reading after the fact. But the derived values, things like allocations across commingled streams, accruals across reporting periods, and KPIs that drive commercial settlement, are computed under business rules that change. When the rules change, most platforms either silently recompute history under the new rules, destroying the prior interpretation, or freeze history under the old rules and apply the new rules going forward, creating a discontinuity at the cutover that no one can audit. Neither is acceptable. Provenance and methodology are both first-class, and both require versioning, but the disciplines differ: observations are versioned by arrival, since you cannot un-observe what arrived, while methodologies are versioned by registration, since you can, and routinely will, change how you interpret what arrived.

2.2 Inadequate isolation across multiple tenants

Industrial customers operate under disjoint regulatory regimes. A national hydrocarbons regulator, a state environmental authority, an offshore safety body, and a private commercial counterparty have different evidence requirements and different egress constraints. A platform that treats all tenants as rows in a shared database, discriminated only by tenant_id, cannot satisfy a customer whose contract or regulator requires a dedicated database, and cannot satisfy a customer whose regulator requires that data never leaves a specific physical jurisdiction. Compliance isolation is not a feature flag; it is a deployment topology, and the methodology must support multiple tiers of it from day one.

2.3 Silent reconciliation of conflicting readings

In every real industrial dataset, two instruments occasionally observe the same physical phenomenon and disagree. A memory gauge and a surface readout report different bottomhole pressures. An MWD pulse and a wireline log report different formation depths. A meter at custody transfer and a tank gauge report different volumes. The engineering temptation is to average the two readings, prefer the more "trusted" instrument, or quietly drop the outlier as a transient. Each of those moves silently erases a finding, the disagreement itself, that is operationally consequential and, in regulated contexts, legally consequential. A correct methodology records both readings, links them, flags the disagreement, and treats the resolution as a separate auditable event.

2.4 Vocabularies that fade with the architecture

Most platforms accumulate vocabulary as they grow. Components are named for the technology in vogue when they were written, words like the kafka layer, the snowflake mart, the redis hot store, or for the team that owned them, words like the platform-eng service, or for the bug they were originally introduced to work around. This vocabulary is decorative and carries no architectural commitment, and so commitments leak away. Engineers cannot remember which component was supposed to only append, which was supposed to be the source of truth, which was supposed to require an authorized signature to write to. A coherent vocabulary, drawn from a single source domain whose institutions already encode commitments analogous to the architecture's, is itself a form of compliance enforcement. Section 11 returns to this.

3. The methodology: three commitments

The methodology rests on three commitments. They are mutually reinforcing; weakening any one of them weakens the other two.

3.1 Commitment 1: ledgers that only append

Every record that bears a fact in the substrate, observations and derivations and audit entries alike, is written exactly once. There is no UPDATE and no DELETE in the data model of the ledgers. Corrections are expressed as new entries that reference the entry being corrected; deletions are expressed as new entries that mark the prior entry as superseded. The architecture enforces this at the schema layer, where there are no update or delete grants on ledger tables, at the application layer, where the write path emits only inserts, and at the audit layer, where any administrative override of these constraints is itself an audit entry, scoped and expiring.

3.2 Commitment 2: derivations versioned by methodology

Every derived value is computed under a methodology specification that is itself a versioned artifact in the substrate. A new version of a methodology specification does not retroactively rewrite past derivations; it produces a parallel track of derivations alongside the old one, beginning from a registration timestamp. Consumers of the derivations ledger select the methodology version explicitly. The architecture enforces this by binding every derivation record to the methodology specification version under which it was produced, and by treating the registration of a new version as a state transition recorded in the audit ledger, as described in section 8.

3.3 Commitment 3: exports attested cryptographically

Every export of data from the substrate, whether to a regulator, to a commercial counterparty, to a downstream analytics system, or to the customer's own data lake, carries a verification artifact that the recipient can validate without trusting the platform. The verification artifact contains the cryptographic seal chain over the exported records, the methodology specification version under which any derived records were computed, the identity of the authorizing principal, and, in higher modes, a Merkle anchor on a public chain that proves the export's contents were sealed before some external timestamp. The architecture enforces this by routing every export through the cryptographic notary; an export emitted on any other path is a defect.

4. Three ledgers, kept distinct

The substrate maintains three ledgers, and they are not the same ledger viewed three ways. They are kept distinct because the disciplines that govern them are commutatively distinct.

4.1 The operational ledger

The operational ledger records what was observed. Its records arrive from outside the system: sensors, controllers, gauges, instruments, meters, manual entries, third-party data feeds. The operational ledger is immutable on arrival; the substrate has no authority to alter what was observed. Corrections to observation records, things like a recalibrated sensor, a re-keyed manual entry, or a vendor's late-correcting data feed, are themselves new observation records that reference the prior record they correct. The operational ledger is the substrate's evidentiary floor: every derivation, every export, every adjudication ultimately resolves back to entries in this ledger.

4.2 The derivations ledger

The derivations ledger records what was concluded. Its records are born inside the system; they did not arrive, they were computed. Each record is computed under a versioned methodology specification, against one or more observation records, and is sealed at a period close. When the methodology specification is revised, the derivations under the new version are written as a parallel track alongside the prior version's derivations; the prior records are not rewritten and are not deleted. The derivations ledger is therefore not a single time series of derived values but a forest of parallel time series, one per methodology version, each fully recoverable.

4.3 The audit ledger

The audit ledger records what was done to the system itself. Configuration changes, role grants and revocations, methodology specification registrations and deactivations, period closes, exports, identity-credential issuance and revocation, egress policy edits, notary mode transitions, signing-key rotations, and override authorizations all appear here. The audit ledger is the place from which administrative state is derived. There is no separate "current configuration" table that drifts from the audit log; the configuration is what the audit log says it is at any given timestamp. Section 8 develops this point at length for methodology versioning.

4.4 Why three, not one

A single ledger, with a record_kind column, is the naive answer. It fails for three reasons. First, the retention policies differ: observations may need to be kept indefinitely, derivations may need to be kept for the duration of a regulatory regime, and audit entries may need to be kept for the duration of any liability arising from administrative acts. Second, the isolation requirements differ: observations may need to leave the substrate in bulk to a customer's data lake, derivations may be exported only to a regulator or counterparty, and audit entries may never leave the substrate at all. Third, the write paths differ: observations are written by the field tier or by ingestion adapters, derivations are written by the derivation engine after a period close, and audit entries are written by the platform itself in response to administrative acts. Conflating the three obscures these differences and produces, eventually, all four pathologies of section 2.

5. Topology in two tiers

The substrate is deployed as two cooperating tiers.

5.1 The field tier

The field tier sits on the operating site. Its core is an intelligent software agent at the site, running on a dedicated hardware kit specified by RCI for the deployment. The agent decodes the protocols specific to the site, things like Modbus, OPC-UA, vendor-proprietary serial framings, ASCII or CSV files dropped by site systems, WITSML feeds, and so on, into the substrate's canonical observation record envelope. The agent stamps each observation with provenance at the moment of capture: the timestamp asserted by the source, the receive timestamp at the agent, the original units of measurement, the adapter and adapter version that decoded the record, the identity of the ingest node, and a content hash. The agent operates without depending on health probes from the cloud; if the cloud tier is unreachable, the agent continues to capture, persist locally, and forward when connectivity returns. The field tier is dedicated hardware, not a container deployed on a customer SCADA host; the hardware kit isolates the substrate's evidentiary chain from anything else running at the site.

5.2 The cloud tier

The cloud tier holds the three ledgers, the cryptographic notary, the long-term archive, the exchange surface that exposes data to downstream consumers under contract, the identity registry that issues and revokes credentials for principals both human and machine, the fleet-management agent that supervises deployments of the field tier, and the machinery for conflict resolution described in section 9. The cloud tier may be deployed multi-tenant or single tenant per customer, as set out in section 10. The cloud tier is where derivations are computed, period closes are sealed, exports are issued, and audit entries are accumulated.

5.3 The wire transport

The transport between field and cloud is agnostic of the transport at the application layer. The application protocol carries observation records and control messages; it neither knows nor cares whether the underlying physical link is Starlink, the customer's WAN, cellular, microwave, or a leased line. The choice of transport is a decision made at deployment time, driven by the site's connectivity options. Constraints on what may flow over the link are enforced at the firewall layer with signed policy: the firewall configuration is itself a record in the audit ledger, signed by an authorizing principal, and changes to that configuration are administrative acts. Transport encryption is mandatory; the choice of transport is not architecturally privileged.

6. The atomic units

Three record types form the substrate's atomic vocabulary.

6.1 The observation record

An observation record is one sensor reading or one operational event. Its envelope carries dual timestamps, namely the timestamp asserted by the originating instrument or system and the receive timestamp at the agent in the field tier. It carries the original units of measurement with no destructive conversion at write. If the sensor reports kPa, the record stores kPa, and any conversion to psi is a derivation. It carries full provenance: the adapter that decoded the record, that adapter's version, the identity of the ingest node, and a content hash over the canonical serialization.

{
  "record_id": "01HZ9X3K4M2A...",
  "record_kind": "observation",
  "tenant_id": "tenant-acme",
  "site_id": "site-north-04",
  "stream_id": "wellhead-pressure-sensor-7",
  "timestamp_source": "2026-05-04T13:42:17.250Z",
  "timestamp_receive": "2026-05-04T13:42:17.418Z",
  "value": 18437.2,
  "uom_original": "kPa",
  "provenance": {
    "adapter": "modbus-tcp-decoder",
    "adapter_version": "2.4.1",
    "ingest_node": "field-agent-north-04-a",
    "content_hash": "sha256:9b1c4f..."
  },
  "seal": {
    "mode": "A",
    "signature": "ed25519:7f3e..."
  }
}

6.2 The derivation record

A derivation record is a value computed from one or more observation records, and recursively from other derivation records, under a methodology specification version. Its envelope carries the methodology specification version under which it was computed, the set of records it derives from referenced by record id rather than embedded, the period close event at which it was sealed, and the cryptographic seal that links it into the chain. A derivation record is never produced ad hoc; it is produced as part of a period close, and the period close is itself an event recorded in the audit ledger.

6.3 The audit entry

An audit entry is a record of an act upon the system itself. Its envelope carries the actor, which is the principal that performed the act. It carries the act itself, whether a configuration change, role grant, methodology registration, export, or similar. It carries the target, which is the configuration item, role, methodology lineage, or export specification. It carries the rationale, a human-readable justification that is required on every entry. And it carries the seal. Coverage that defaults to deny applies: every event in the substrate is an audit entry by default, and any exclusion from audit coverage is itself an audit entry that registers the exclusion, as set out in section 10.

7. Cryptographic notarization

A cryptographic signature per record links the substrate's records into a tamper-evident chain. The signature scheme is implementation-specific. The substrate uses Ed25519 over a canonical serialization at the time of writing. What matters methodologically is that every record carries a signature whose verification depends on signatures over prior records, so that any retroactive alteration of a record invalidates the chain from that point forward.

The substrate offers two notarization modes, configurable per tenant:

Mode A: internal certificate. Records are signed under a key held by the substrate, anchored to an internal certificate authority. Mode A is sufficient for SOC 2 baseline obligations and is the floor of the substrate's notarization commitment. A tenant on Mode A obtains tamper-evidence relative to the substrate operator: any alteration of a sealed record by the operator after the fact is detectable, and any alteration by an external attacker is detectable, but a recipient who does not trust the operator cannot, on Mode A alone, prove the records were sealed at any specific historical moment.

Mode B: Mode A plus periodic Merkle anchoring on a public chain. In Mode B, the substrate periodically computes a Merkle root over the records sealed since the prior anchor and publishes that root to a public chain. The choice of which public chain is a deployment parameter. Mode B grants the property of verification without trust in the platform: a recipient holding an exported record and the corresponding Merkle inclusion proof can verify, against the public chain, that the record's contents existed and were sealed before the public-chain timestamp of the anchoring transaction. Mode B is the appropriate setting for tenants whose downstream consumers, such as regulators or commercial counterparties, require independent verification.

Each export from the substrate carries a verification artifact: a self-contained bundle of the exported records, the seal chain over those records, the methodology specification versions under which any derivations were computed, the authorizing principal's identity and signature on the export, and, in Mode B, the Merkle inclusion proofs and the transaction identifiers on the public chain required to verify the anchors. The verification artifact is what the recipient validates; the substrate's continued availability is not required for validation.

8. Methodology versioning: the five rules

The hard part of operating a derivations ledger is not writing the first version of the methodology specification. It is writing the second. The four pathologies of section 2 cluster around precisely this transition. The substrate enforces five rules.

8.1 The five rules

Rule 1: active is a derived attribute, not a stored flag. Whether a methodology specification version is currently active is computed by walking the audit ledger for that lineage's registration and deactivation entries; it is not stored on the methodology specification record itself. This rule is load-bearing because it makes the active state recoverable from history: any disagreement about whether a version was active at some past timestamp is resolved by replaying the audit ledger to that timestamp, not by trusting whatever flag happens to be set on a row right now.

Rule 2: at most one version of a methodology lineage may be active at any time. A "lineage" is a chain of methodology specification versions that succeed one another (v1 → v2 → v3...). Two versions of the same lineage cannot be simultaneously active; the substrate would not know which one to use to compute a new derivation. Different lineages are independent and may all be active simultaneously.

Rule 3: supersession is atomic. When v2 supersedes v1, the audit ledger records a single compound entry that both registers-and-activates v2 and deactivates v1. Never two entries. An implementation that uses two entries has a window, even a millisecond, during which either both versions are active in violation of Rule 2, or neither is active so the lineage has no current version and a derivation request in that window has no methodology under which to compute. The compound entry is one act, atomic in the audit ledger.

Rule 4: soft deletion is a derived predicate, not a stored state. A methodology specification version is "soft-deleted" iff every version in its lineage is inactive. There is no is_deleted column. A lineage with v1 superseded by v2, both inactive, is soft-deleted; a lineage where v3 is currently active is not soft-deleted, even if v1 and v2 are inactive. This rule makes soft deletion reversible by future registration without any retroactive flipping of flags.

Rule 5: rollback is re-registration. Superseded versions cannot be reactivated. If after running v2 for a quarter the operator decides v1's rules were preferable, the operator does not reactivate v1. The operator registers v3, whose computation rules mirror v1's, atomically deactivating v2 per Rule 3. v3 is a new version with a new identity and a new registration timestamp; derivations produced under v3 are distinct from those produced under v1, even though the rules are identical. This rule preserves the monotonic forward direction of the lineage and avoids the ambiguity of "is this derivation under the old v1 or the re-activated v1?"

8.2 The state matrix

Every methodology specification version sits at the intersection of two axes: whether it is currently active, computed per Rule 1, and whether it has a current successor in its lineage, meaning a successor version that is itself either active or has its own current successor. The matrix has four cells; the rules forbid one of them.

The forbidden cell, with states active and superseded, is the cell the rules exist to prevent. A version that is both active and superseded means the lineage has two active versions, this one and the current successor, which is precisely Rule 2's violation. The substrate's write path checks this invariant on every audit entry related to methodology; any transition that would produce a state in the forbidden cell is rejected at write time, before the audit entry is sealed.

8.3 Why these rules are load-bearing

These five rules are not a coding convention. They are the substrate's only defense against the first pathology of section 2, immutable provenance with mutable methodology. Without them, the derivations ledger drifts: rows get flagged active and inactive in non-atomic sequences, columns for soft deletion desynchronize from registration history, rollbacks resurrect old versions and produce derivations whose lineage cannot be reconstructed, and the question "which methodology produced this derivation?" becomes unanswerable. With them, the derivations ledger is a forest of parallel tracks, every track fully recoverable, every transition between tracks recorded as a single atomic act in the audit ledger.

9. Disagreements between two witnesses

When two instruments observe the same physical phenomenon and disagree, the disagreement is itself a finding of operational consequence. The methodology refuses the convenience of resolving such disagreements silently.

9.1 The rule

Both readings are recorded in the operational ledger. A link record is written that names both observations and flags them as a disagreement between two witnesses on a specific phenomenon. The phenomenon is named explicitly, with examples such as bottomhole pressure at depth X, formation top of unit Y, or volume at custody transfer for batch Z. Neither observation is altered, suppressed, or annotated as "wrong"; the link record is the structure that says "these two records purport to measure the same thing and they don't agree."

9.2 Adjudication

Adjudication is a separate, recorded event, written to the audit ledger. The adjudicator may be automated, driven by a rule set per tenant with directives like "prefer the memory gauge over the surface readout when the spread exceeds 2%" or "always escalate disagreements involving meters at custody transfer", or human, a principal with the Approver role for that tenant, escalated from automated rules or invoked directly. The adjudicator's identity, the rule set version if automated or the human principal if manual, the rationale, and the resolution are all sealed into the audit entry.

9.3 The resolution as a third record

The adjudication's outcome is a third record, a derivation record under a methodology specification version that handles disagreements between two witnesses, that references both original observations and the audit entry recording the adjudication. The ruling never replaces the disagreeing observations. Downstream consumers reading the derivations ledger see the resolved value; downstream consumers reading the operational ledger see both original observations and the link record; downstream consumers reading the audit ledger see who adjudicated, when, and why. All three views are simultaneously and permanently recoverable.

10. Compliance across multiple tenants

The substrate supports three isolation tiers and an audit posture that defaults to deny.

10.1 The three isolation tiers

The tier is a decision made at deployment time and is, itself, recorded in the audit ledger of the deployment that hosts the tenant. Migration between tiers, for instance when a small tenant on the shared tier outgrows it and requires the dedicated tier, is a substantial operational event, planned and audited; the methodology does not pretend it is free.

10.2 Audit coverage that defaults to deny

Every event in the substrate is an audit entry by default. Exclusions exist because auditing every event would saturate the audit ledger and obscure the entries that matter. Routine high-cardinality reads such as a dashboard polling the operational ledger every five seconds, debug traces emitted during incident response, and pings between cloud-tier services for health checks are the typical candidates. But each exclusion is itself an audit entry, authored by a principal with the Approver role, scoped to which event types on which tenants and on which subsystems, expiring on an explicit end timestamp rather than "until further notice", and bearing a rationale, a human-readable justification recorded on the entry.

10.3 The global list of event types that may never be excluded

A small set of event types may never be excluded, on any tenant, by any principal, under any rationale. This list is hard-coded in the substrate and applies globally:

• Methodology specification registrations, deactivations, and lineage transitions
• Period close events and the seals they produce
• Exports of any kind, to any destination
• Lifecycle events for identity credentials, including issuance, rotation, and revocation
• Changes to egress policy
• Notary mode transitions between Mode A and Mode B and back
• Rotations of any signing key in the substrate

An attempt to register an exclusion that intersects this list is rejected at write time, before the exclusion's audit entry would be sealed. The list is a structural property of the substrate, not a configuration value.

11. The discipline of vocabularies driven by metaphor

The fourth pathology of section 2, vocabularies that fade with the architecture, is a pathology of naming. It deserves a methodological response of its own.

11.1 What goes wrong without it

When a system's vocabulary is decorative, commitments leak away. A component named for the technology behind it, with names like the message bus or the columnar store, tells the next engineer nothing about what guarantees the component is supposed to provide; renaming the technology without changing the guarantees, or vice versa, is silent. A component named for the team that built it tells the next engineer even less, and the team itself may no longer exist. A component named for the bug that prompted its introduction is the worst case: the name is meaningful only to the engineer who remembers the bug, and that engineer leaves.

11.2 What a coherent metaphor does

When the names are drawn from a single coherent source domain, a metaphor whose institutions match the architectural commitments the substrate is making, two things happen. First, the names encode commitments: the institution being borrowed already had a job, already had constraints, already had relationships to other institutions, and importing the name imports those structures as a constraint on the implementation. Second, the names generate further names organically: as the architecture grows, the next component to be added has a natural place in the institutional landscape of the source domain, and its name emerges from that landscape rather than from whatever technology happens to implement it.

11.3 What the methodology prescribes, and what it does not

The canonical methodology prescribes that a metaphor be chosen, that it be coherent by being drawn from a single institutional source domain, and that its institutions match the architectural commitments. The methodology does not prescribe which metaphor: pick one whose institutions match the commitments your substrate makes. A platform whose central commitment is custodial preservation might draw its vocabulary from archival institutions; a platform whose central commitment is adversarial verification might draw from judicial institutions; a platform built around ledgering that only appends and around notarization might draw from a settlement system that already operated with clerks, registries, and seals. The methodology is agnostic about the metaphor; the choice is part of instantiating it.

11.4 The IETF draft

The engineering theory of the discipline of vocabularies driven by metaphor, including the rules for choosing a source domain, the constraints on coherence, the cataloging of borrowed institutions, and the working examples, is the subject of the IETF draft draft-rodriguez-grana-metaphor-vocabularies by Rodriguez and Graña. Practitioners building substrates under this methodology should treat that draft as the reference text for the vocabulary discipline. One worked instantiation of the methodology, including a chosen metaphor drawn from the institutions of the rural pueblo of nineteenth-century interior Argentina and the full vocabulary that metaphor produces, is documented separately as the El Mundo white paper.

12. Implementation notes and engagement

What is hard, what is easy, and where RCI is in implementing the methodology.

12.1 What is hard

The state model for methodology versioning. The five rules of section 8 are simple to state and surprisingly hard to implement correctly. The hardest part is Rule 3, atomic supersession: most data stores do not provide the atomicity guarantee the rule requires, and naïve implementations on top of those stores have the millisecond-window vulnerabilities the rule exists to prevent. The implementation requires care.

Isolation tiers across multiple tenants. The shared tier with row-level security is the cheapest to operate but the most error-prone; the tier with a dedicated database per tenant is straightforward to operate but requires careful automation of per-tenant deployment; the on-prem tier with a single tenant is operationally demanding because every site is its own deployment. Choosing the right tier per tenant, and operating all three tiers concurrently, is a substantial engineering investment.

Audit that defaults to deny, with a global list of event types that may never be excluded. Most logging frameworks default to "log nothing unless asked"; this methodology requires the inverse, with structured exclusions. Retrofitting an audit that defaults to deny onto an existing platform is harder than building it in from the start.

Custody of cryptographic notary keys. Mode A requires only a competent internal certificate practice; Mode B requires that practice plus an operational discipline around periodic anchoring transactions on a public chain, including the cost, the reliability, and the key custody for the public-chain account that signs the anchoring transactions. Key compromise, or loss, at the notary is the substrate's worst-case operational event.

Selection of the adjudicator for conflict resolution. Rule sets per tenant for automated adjudication, escalation paths to human Approvers, and the operational discipline that ensures Approvers are responsive: all of this must exist before the first disagreement between two witnesses arrives. Building the machinery after the disagreement arrives is too late.

12.2 What is easy

The agent in the field tier, if the operator already has an ingest pipeline for ASCII or CSV files. The agent's protocol decoders are modular; adding a new decoder for a format specific to a site is routine engineering. Operators who already standardize on ASCII or CSV at the site can adopt the field tier with minimal change at the site.

The long-term archive, once the retention model is decided. The archive itself is technologically conventional: object storage with versioning, lifecycle rules, and a catalog. The hard part is deciding the retention model, namely for how long, under what regulatory regime, and with what access controls, and the methodology informs that decision but does not make it.

12.3 Where RCI is

RCI's Data Platform for an Oil & Gas Operator is a platform built from multiple components for the work of well construction. It spans data masters catalogs, field reporting data from both a legacy system over 20 years old and a new reporting system, AFE modeling for Authorization for Expenditure, a Well File lifecycle system, and an analytics system for drilling and completions. Its seminal system became officially operational in May 2026 for all field types of operations in well construction, and the platform continues to expand through 2026 and 2027. That platform was the first implementation of the ledgering approach described in sections 3 through 10; the methodology presented here is its formalization and re-usable expression.

Two design partnerships are in motion. The first is the continued expansion of the Oil & Gas Data Platform: adding capabilities across the components above, and progressively incorporating the methodology's formalized constructs as they reach production readiness. The second is a partnership for methodology adoption with a geothermal utility: a project with shallow wells under permitting for water wells, focused on temperature equalization, that adopts the methodology's record-keeping concepts for its own platform for planning and reporting. The utility uses the discipline without deploying the field tier described in section 5. The second partnership validates the methodology's transferability across industrial domains and regulatory regimes; the first validates its operational soundness at production scale.

12.4 How to engage RCI

RCI works with customers in industrial data as a design partner, not as a vendor of a finished product. The engagement starts with a methodology fit assessment that asks whether this substrate matches the customer's compliance regime, evidence requirements, and operating topology, and proceeds through a phased implementation. Customers who wish to engage should write to pueblo@roderickc.com.

Companion document: the El Mundo white paper, one worked instantiation of this methodology.