The system

The operating layer.

An AI operating layer built inside an aviation parts, MRO and landing gear leasing group. Four months, 1,650 commits across 15 repositories, added function by function as the business needed them.

Timeline.

  1. April
    Knowledge base. Company mail, chat and documents made searchable in one place.
  2. May
    Core functions. Enquiry handling, quote drafting, onboarding paperwork, live reads of the ERP and the accounts, a decision queue for the owner.
  3. 31 May
    Governance. A registry of every running job, a gate on outbound email, written operating rules.
  4. June
    Quality gates. A sanity check on every draft, alerts when a data feed stops, a supervisor over the functions.
  5. July
    Stop controls and census. One master stop, plus a check that every acting job is registered to it. A census of all jobs, with stale ones retired. An automatic-send pilot under explicit grants. Regression evaluations.
  6. August
    Hardening. A fail-closed stop rule, a dedicated customer-facing machine, the records function rebuilt, employee starter packages, operating rules reconciled with the running system.
  7. 2 Sep
    Adversarial audit. 311 evaluations across all four machines.
  8. 20 Sep
    Manual re-verification. 20 audit findings re-checked by hand against the original logs.

How it is wired.

Nine inputs, one operating layer, six recipient groups, four outbound channels.

How the operating layer is wired Nine inputs on the left feed one operating layer governed by four rules. On the right, six recipients. Four outbound channels, each gated, all covered by one master stop. The layer does not sign documents and does not move money. INPUTS Email, every mailbox WhatsApp working groups ERP: stock, quotes, orders Accounting and bank feeds Parts marketplaces Calendars and meetings Shared documents Fleet and market data Its own decision log Operating layer: four rules 1 Related signals groupedone report, relationship stated 2 Routed to the process ownerdecision items only 3 Figures from the system of recordfailed source check: item withheld 4 Recorded recipient, recorded actionsproposal, approval, execution, confirmation KNOWLEDGE ingested, deduplicated, dated. Facts with a source outrank text. CONTROLS monitoring, recipient verification, scope gate, payment-language guard, ERP read-only by default, self-audit. FIXED RULES Does not sign documents. Does not move money. Stop events report to the owner through a separate, ungated path. RECIPIENTS Owner: daily summary Sales: priced, checked quotes Purchasing: items to chase Finance: source-fresh figures Marketing: publishable signals People: privacy-restricted OUTBOUND CHANNELS each authorised, gated, logged, revocable Internal email, capped Customer quotes Marketplace submissions Public stock listings ONE MASTER STOP COVERS ALL FOUR
  1. Related signals are grouped. Items that belong together are reported in one place, with the relationship stated.
  2. Decision items go to the recorded process owner. Items that need no decision are not sent.
  3. Figures come from the named system of record. They are pulled when the report is created. When a source check fails, the item is withheld and marked for correction.
  4. Each recommendation has a recorded recipient. Actions are recorded as proposal, approval, execution and confirmation.

Functions.

Process owners keep approval. The layer reads source systems, prepares drafts, runs checks and sends follow-ups.

Enquiries and quotes

Read incoming requests, price them against stock and history, and draft quotes. Approved offers can send automatically under set rules, with manual-only control for any customer.

Purchasing

Track purchase requirements, request supplier offers, and record each offer in the system.

Finance

Read cash, receivable and payable balances from their source systems, with bank data taking precedence over book records.

People

Handle staff questions and paperwork. Health and personal data are never routed by job title.

Market

Read market and regional sources each morning and report only the items that changed, with the source next to each.

Meetings

Convert recordings into minutes and track the follow-ups. Attendance is taken from the recording, not the invitation.

Marketing

Extract publishable signals from internal meetings, with figures and names removed and a verification note on each item.

Knowledge

Store mail, chat, meeting and deal records in separate access-controlled logs, so restricted material is excluded from shared summaries.

Controls

Verify recipients, apply the lowest permission in any group, screen payment language, keep the ERP read-only by default, and audit the layer's own output.

Outbound channels.

The layer sends through four outbound channels. Each is authorised by the owner, gated, logged and revocable.

  1. Internal email. Capped per recipient per day and in total, screened for confidential content, listed in a daily digest.
  2. Customer quotes. Enabled only while an explicit arming file is present. A price floor applies to every quote. Any account can be set to manual only.
  3. Marketplace submissions. Separate stop control.
  4. Public stock listings. Explicit arming, daily cap, separate pause.
One master stop covers all four channels.

Two fixed rules: the layer does not sign documents and does not move money. Stop events report to the owner through a separate, ungated path.

Controls.

Recipient verification

A message must name its recipient in two independent places, and both must match, or it is not sent.

Scope gate

Outbound drafts are classified, every recipient including copies is checked, and the lowest permission in the group applies.

Payment language

Messages containing payment or bank instructions are held unless explicitly released, and every decision is logged.

Figure freshness

A financial figure is re-pulled from its source when the draft is written. If the source is stale, the figure is withheld.

ERP access

Read-only by default. Only approved quoting functions write, to their own records, through one audited path.

Self-audit

Job monitoring, the 2 September audit of the scheduled jobs, and manual review of 20 findings on 20 September.

Registry figures.

As of 20 September 2026.

219
scheduled jobs running on four machines, including jobs that monitor other jobs.
313
jobs registered over the project's life, 33 retired.
40
capabilities, each tied to a credential and a policy.
38
written policies.
202
schedules.
16
internal delivery channels.
4
outbound channels.
1
master stop.

Audit record.

On 2 September an adversarial audit completed 311 evaluations covering the scheduled jobs on all four machines. It recorded 102 findings: jobs that finished without error and reported success while the output was wrong or reached nobody. The audit attributed the largest groups of findings to a control verified on the wrong machine, input feeds that stopped while processing continued on schedule, and operating rules that no longer matched the running system. The affected controls were changed during the week of 2 September.

On 20 September, 20 of the 102 findings were chosen at random and re-checked by hand against the original logs. 19 held. 1 was wrong: the audit had read two lines marked blocked and reported that a daily cash alert never arrived, when the next line in the same file, 308 milliseconds later, recorded it as sent. Across the full log, 108 of 132 alerts went out. The finding was corrected and the checker now reads the final delivery state before reporting on any send.

Built inside the business.

The layer was built by the founder of a group operating across the US and Europe, through written instructions and review, over four months, while the business ran on it. The registry and audit counts on these pages are the ones used to run it, published with their dates. MUNERON is the company that documents the layer and the method behind it.

Contact MUNERON

For companies already running AI in the business, with jobs nobody has independently checked.

Get in touch