Meet the Leader

Kyle Castor on value creation in basis points

Kyle Castor, Founder & Principal Architect  •  61 seconds  •  Captions  •  AI-rendered presenter from the studio portrait

Transcript

00:00To private equity sponsors and operating partners here in Las Vegas: your post-acquisition value creation shouldn't be trapped in forty-page slide decks.

00:11At DataOngoing, we measure our work strictly in basis points of EBITDA. Two hours of executive input returns hundreds of automated hours, proven in our 100x time ledger.

00:24First, a 48 to 72-hour AI technology diligence read to price technical debt before wiring capital. Second, compressing your 21-day multi-entity close down to 3. Third, automated floor-to-ledger data ingestion straight into NetSuite.

00:44We ship working code in 14-day sprints. If it does not run in production, the milestone is not billed. Visit DataOngoing.ai to schedule a private advisory session.

  1. How we work →
  2. Read the 100x ledger →
  3. The productized offers →
  4. The Basis-Point Sprint →

Every figure in the brief is published on this site with its source class; the chapter links go to those pages.

Schedule a strategy callRead the full profile
Home / Workflow designs
Workflow designs

Workflow designs from delivered work

Each design below is a workflow we have built and run: the stages the work passes through, what happens in each, and the point where a person approves. The designs are redrawn from the working diagrams, so clients appear as archetypes and the figures stay on the linked case studies and ledger rows with their source class. Filter by domain or by the stage of an engagement the design belongs to.

The designs sit on the four stages of an engagement. Discovery reads the system; Build puts code into production inside a two-week sprint; Deployment goes live without stopping the operation; Trust is the approval gates, audit trails and reconciliations that let an auditor follow every record.

DiscoveryReading a system before anyone is interviewed.
BuildCode in production inside a two-week sprint.
DeploymentGoing live without stopping the operation.
TrustApproval gates, audit trails and reconciliation to the cent.

The 10 designs

  1. Document intake: paper to a posted receipt
  2. Governed AI workers: read freely, write only through a person
  3. The context packet: pre-flight queries before any model call
  4. Two-model consensus: independent readings before a draft is proposed
  5. Voice intake: a phone call that ends as a scheduled work order
  6. Single entry point: one governed router for every transaction save
  7. The diligence read: telemetry first, interviews last
  8. Live cutover: dock to ledger with lot traceability
  9. Design-change portal and invoicing on the carrier scan
  10. The revenue spine: HubSpot, Stripe and NetSuite reconciled to the cent
Domain
Stage

01 / 10AI workersBuildModeled composite

Document intake: paper to a posted receipt

Where it runs: Receiving docks and AP desks in manufacturing and distribution; packing slips with heat or lot numbers, carrier bills, vendor invoices

A packing slip or vendor bill arrives as a PDF, a scan or a phone photo. A vision model reads it, SuiteQL resolves the vendor, the parts and the open purchase-order lines, and the worker proposes an item receipt or vendor bill with its lot subrecords. A person approves; nobody re-types a heat number.

Paper to a posted receipt: the document intake pipeline The scan is read by a model; the ledger is written by a person. Every extracted field carries its source page and a confidence score.

  1. 01Capture

    1. Packing slip, bill of lading or vendor bill arrives by email, scanner or phone photo
    2. File lands in the intake queue with sender and timestamp
    3. Duplicate check by content hash against prior documents

  2. 02Extraction

    1. Vision OCR normalizes multi-page PDFs and photos
    2. Header, lines, quantities, heat or lot numbers, expiration dates
    3. Confidence per field; low confidence is flagged, never guessed

  3. 03Resolution in NetSuite

    1. SuiteQL match: vendor name to entity ID
    2. Vendor part number to item through the alias history
    3. Open purchase-order lines pulled for the three-way match

  4. 04Proposal

    1. Draft item receipt or vendor bill with lot subrecords
    2. Line variances computed against the PO
    3. Evidence packet: source page, extracted values, matched records

  5. 05Approval and posting

    1. Exact PO matches queue for one-click approval
    2. Variances open with the PDF beside the draft
    3. NetSuite writes the record under the approver’s role

Control points

  1. Nothing posts without a named approver. The approval is one click; the keying is gone.
  2. An idempotency key on every draft prevents a second receipt when a document is re-sent.
  3. Field-level confidence and source-page references make every line auditable after the fact.
02 / 10AI workersBuildModeled composite

Governed AI workers: read freely, write only through a person

Where it runs: Multi-subsidiary services holding company; enterprise managed services and complex logistics

A central router dispatches work to specialized workers, each acting only through formal Model Context Protocol tools: parameterized read-only SuiteQL, record schema, and a draft proposal. Reads return live rows. Writes stop at a review modal where a supervisor approves before NetSuite commits the record.

Aissistor orchestration: read freely, write only through a person The model is the synthesizer and anomaly detector, never the source of truth and never the hand on the ledger.

  1. 01Inputs

    1. Vendor PDF bills through OCR
    2. A natural-language question from the CFO
    3. The scheduled nightly diagnostic

  2. 02Central router

    1. Agent dispatcher and state machine
    2. Context from the corporate knowledge base

  3. 03Specialized workers

    1. AP matching worker
    2. GL margin-leak detector
    3. SuiteQL forensic auditor

  4. 04Governed MCP tools

    1. execute_suiteql, read-only
    2. get_record_schema
    3. propose_transaction_draft

  5. 05Production ledger

    1. Reads return live SuiteQL rows
    2. Drafts stop at the human approval modal
    3. Approved drafts commit to the ACID ledger

Control points

  1. Role-scoped tokens and a read/write boundary an auditor can inspect; no scrapers, no shared database drivers.
  2. Every figure in a worker’s answer traces to a SuiteQL row it did not generate.
  3. A worker can find fourteen duplicate invoices in five thousand purchase orders; it cannot post a credit for any of them.
03 / 10AI workersBuildModeled composite

The context packet: pre-flight queries before any model call

Where it runs: Any AI worker that touches entities, currencies or tax: AP matching, margin-leak detection, finance questions over the ledger

Commercial models fail inside an ERP when they are asked to remember internal IDs, tax nexus and currency rates across a long context. This design never asks them to. Code runs the queries first and hands the model a small, structured packet of live rows for the one task in front of it.

The context packet: assembled by code, reasoned over by the model A model never sees the schema. It sees a small packet of live rows assembled for the task at hand, and every value in the packet names the row it came from.

  1. 01Trigger

    1. An inbound document, a question from finance, or the nightly diagnostic
    2. The router classifies the task and picks the worker
    3. The worker’s required context is declared, not improvised

  2. 02Pre-flight SuiteQL

    1. Parameterized, read-only queries for exactly the rows needed
    2. Entity, open PO lines, currencies, tax nexus, item aliases
    3. Results cached for the run; no saved searches in the loop

  3. 03Context packet

    1. Compact structured packet with record internal IDs
    2. Personal data masked before it leaves the tenant
    3. Every value tagged with its table and row

  4. 04Model reasoning

    1. The model reasons over the packet only
    2. Each figure in the output traces to a packet row
    3. Unknowns come back as questions, not guesses

  5. 05Memory

    1. Resolved aliases and decisions written to the knowledge base
    2. The next run starts from the corrected mapping
    3. A correction by a person becomes a rule the worker follows

Control points

  1. The packet builder holds read-only, role-scoped credentials; it cannot write.
  2. Masking and row tagging happen in code before the model is called, so the model never sees a name it does not need.
  3. The packet is logged with the prompt hash, so any answer can be replayed and checked.
04 / 10AI workersTrustModeled composite

Two-model consensus: independent readings before a draft is proposed

Where it runs: Accounts payable and any intake where a model’s reading becomes a ledger entry: vendor bills, credit memos, contract terms

One model’s reading of an invoice is an opinion. Two independent readings compared by code against the purchase order are evidence. The gate proposes a draft only when both readings agree and match NetSuite; any disagreement becomes an exception with both readings side by side, and no path leads from either model to the ledger.

The consensus gate: two readings, one deterministic comparison, one human approval Two models read the same document without seeing each other’s output; code compares them to the purchase order; disagreement becomes an exception, never a posting.

  1. 01Independent extraction

    1. Model A extracts header, lines, quantities and lot serials
    2. Model B extracts the same document with no view of A
    3. Both return structured output against the same schema

  2. 02Deterministic comparison

    1. Code compares A and B line by line
    2. Totals recomputed from the lines, not read from the page
    3. Terms, duplicate invoice numbers and tax codes checked against NetSuite

  3. 03Outcome

    1. Agreement to the cent and a PO match: a draft is proposed
    2. Any disagreement: an exception with both readings side by side
    3. No path from either model to the ledger

  4. 04Human approval

    1. The approver sees the draft, the evidence and the variance
    2. One click approves; one click sends it back
    3. The record saves under the approver’s role

  5. 05Audit trail

    1. Prompt hashes and model versions in the system notes
    2. Both readings retained with the document
    3. Approval stamp and timestamp on the transaction

Control points

  1. Agreement is decided by code with fixed tolerances, not by a third model.
  2. The tolerance that lets an exact match queue for one-click approval is a setting the controller owns.
  3. Model vendors are interchangeable; the gate is the design, not a particular model.
05 / 10AI workersDeploymentModeled composite

Voice intake: a phone call that ends as a scheduled work order

Where it runs: Field-service and installation businesses whose calls arrive after hours; the same pattern answers the multilingual agent on this site

A caller reaches a conversational agent instead of voicemail. The agent discloses what it is, captures the customer, site, issue and urgency, checks the account and the schedule in NetSuite by read-only calls, and drafts a service order with a held slot. The dispatcher releases it; exceptions go to a person with the transcript.

Voice intake: from the first ring to a dispatcher’s queue The conversation is live speech. Every fact it needs comes from NetSuite through a read-only call, and the dispatcher keeps the final word.

  1. 01Call

    1. Inbound call, including after hours
    2. The caller is told it is an AI agent and consent is recorded
    3. Language detected; the agent answers in it

  2. 02Conversation

    1. Streaming speech to text and back
    2. Intent and facts captured: customer, site, issue, urgency
    3. Unknowns are asked, not assumed

  3. 03Read-only lookups

    1. Customer and site matched in NetSuite by phone, name and address
    2. Contract or warranty status, open orders, last visit
    3. Technician availability from the schedule

  4. 04Proposal

    1. Draft service order with the captured facts
    2. Proposed slot held, not booked
    3. Confirmation read back to the caller

  5. 05Confirmation and handoff

    1. Text or email confirmation to the caller
    2. The dispatcher reviews the queue and releases the slot
    3. Exceptions and callbacks go to a person with the transcript

Control points

  1. Disclosure and consent open the call; the transcript stays with the order.
  2. Every NetSuite call during the conversation is a read. The write is the dispatcher’s action.
  3. Hold, do not book: a slot is reserved for review so two callers never claim the same hour.
06 / 10NetSuite ERPBuildModeled composite

Single entry point: one governed router for every transaction save

Where it runs: NetSuite accounts where a stack of user-event scripts fires on every save: distribution, manufacturing, subscription billing

A dozen scripts on one record type run in an order nobody chose, each loading searches on the user’s thread, and the save freezes or collides. The single entry point replaces the stack with one typed router: synchronous work is in-memory validation, and everything heavy runs behind the save in an idempotent queue.

The single entry point: one router, in-memory validation, a queue behind the save Every save enters through one typed router. Synchronous work is validation against cached data; GL allocations, credit checks and dispatches run behind the save.

  1. 01Record event

    1. Sales order, item receipt or invoice saved from the UI, a RESTlet, a CSV import or EDI
    2. One deployment per record type replaces the stack of user-event scripts
    3. Context captured: role, source, record state

  2. 02Router

    1. Typed dispatch by record type and event
    2. Deterministic rule order, declared in code
    3. A feature flag per rule for safe rollout

  3. 03In-memory validation

    1. Rules evaluated against cached reference data
    2. No saved searches or record loads in the save path
    3. Reject early, with a specific message

  4. 04Queue

    1. GL allocations, credit checks, EDI dispatch and notifications queued
    2. An idempotency key per job; retries are safe
    3. Map/Reduce workers drain the queue with governance headroom

  5. 05Ledger and telemetry

    1. The save returns in well under a second in the published retrospectives
    2. Record-lock collisions fall away with the synchronous work
    3. Timing per rule logged for the speed benchmark

Control points

  1. One place to read the rules, so an auditor can see every side effect of a save.
  2. Synchronous code may not call a search; the deployment lint fails if it does.
  3. Queued jobs are idempotent and replayable. A failed job is retried, never duplicated.
07 / 10NetSuite ERPDiscoveryModeled composite

The diligence read: telemetry first, interviews last

Where it runs: Private-equity targets and newly acquired portfolio companies on NetSuite; also the first step of every DataOngoing engagement

A conventional discovery interviews people for weeks and delivers a deck. This design reads the system: a read-only role, SuiteQL over execution logs, scripts, searches, roles and integrations, and a dependency map with findings ranked by exposure. The read-out comes 48-72 hours after access, and the fee is credited to the first sprint.

The diligence read: from a read-only role to a ranked roadmap The system is read before anyone is interviewed. Forty-eight to seventy-two hours from access to the read-out, with every finding citing the row it came from.

  1. 01Access

    1. A read-only role granted by the target’s administrator
    2. Scope agreed: scripts, searches, roles, integrations, transaction volumes
    3. No workshop, no interview schedule

  2. 02Extraction

    1. SuiteQL over script deployments, execution logs and governance usage
    2. Saved searches, workflows, custom records and their owners
    3. Roles and permissions scored on the 0-4 Role Risk Index

  3. 03Analysis

    1. Hot paths: the scripts on the save path and their timing
    2. Lock collisions, N+1 searches, unindexed criteria
    3. Integrations and middleware, with their failure modes

  4. 04Architecture map

    1. Dependency map from record type to script to integration
    2. Findings ranked by dollar exposure and effort to fix
    3. What the read cannot see, stated explicitly

  5. 05Read-out

    1. A written report and a read-out with the deal team
    2. A sprint roadmap with fixed prices
    3. The read fee credited in full to the first sprint

Control points

  1. Read-only access; nothing in the target changes during diligence.
  2. Every finding cites the log row, script ID or role it came from.
  3. The report states what it could not observe, so a finding is never inferred from silence.
08 / 10NetSuite ERPDeploymentModeled composite

Live cutover: dock to ledger with lot traceability

Where it runs: $70M West Coast perishable food and beverage distributor; cold-chain food and perishable beverage distribution

Physical intake is decoupled from accounting. Scanners post to an idempotent staging RESTlet and are released in under a second; a Map/Reduce worker binds lots and expiration dates, accrues landed cost and releases the SKU to the pick wave. The move off the legacy platform ran as idempotent delta ingestion across a shift change.

Dock to ledger: the staged receipt architecture Physical intake is decoupled from accounting reconciliation. The scanner is released in under a second; the ledger work runs behind it.

  1. 01Inbound receiving

    1. Refrigerated truck at the dock
    2. Mobile RF scan of the pallet tag
    3. Capture vendor, SKU, lot, expiration, weight

  2. 02Staging engine

    1. Idempotent RESTlet staging queue
    2. Atomic subrecord validation
    3. Valid: staged item receipt in under 800 ms
    4. Variance: hold in a QA quarantine location

  3. 03Asynchronous lot and GL engine

    1. Map/Reduce allocation pipeline
    2. Bind lot numbers to FIFO inventory subrecords
    3. Accrue estimated freight landed cost
    4. Release the SKU to the pick-and-pack wave

  4. 04Governed financial core

    1. Debit inventory asset, lot-specific
    2. Credit landed-cost clearing accrual
    3. Actual carrier bill matched to the lot when it arrives

Control points

  1. A retrying scanner updates the same staging record; it never creates a second pallet.
  2. Lot and expiration subrecords are validated at the moment of physical entry, when they can still be corrected.
  3. Variances hold in a quarantine location instead of blocking the dock.
09 / 10NetSuite ERPBuildModeled composite

Design-change portal and invoicing on the carrier scan

Where it runs: $90M engineered filtration and HVAC systems manufacturer; industrial equipment and engineered filtration manufacturing

A design change is a commercial event. A Suitelet logs it, locks the production ticket, reprices against material cost and waits for the project manager’s approval before updating the sales order and work orders in one transaction. Invoicing becomes an event too: the carrier scan triggers verification, posting and dispatch of the invoice.

Order-to-invoice, before and after The facts needed to invoice exist the moment the carrier scans the bill of lading. The engine uses them; nobody re-types them.

  1. 01Before: fourteen business days

    1. Shop floor ships the equipment
    2. Paper traveler packed with the unit
    3. Design changes tracked in a shared spreadsheet
    4. Manual billing review in NetSuite
    5. Invoice created 12-14 business days later

  2. 02After: under two minutes

    1. ShipStation carrier scan
    2. Fulfillment webhook into NetSuite
    3. Paired engine verifies milestones and DCR approvals
    4. Invoice generated and posted to the GL
    5. Electronic invoice dispatched to the customer

Control points

  1. A logged change locks the downstream production ticket until it is approved or withdrawn.
  2. The sales order, work orders and invoice are linked programmatically, so an auditor traces a line without a spreadsheet.
  3. Invoices post only after fulfillment, approvals and terms are verified by the job, not by a clerk.
10 / 10NetSuite ERPTrustModeled composite

The revenue spine: HubSpot, Stripe and NetSuite reconciled to the cent

Where it runs: High-growth B2B SaaS and subscription business; b2b software and tech-enabled services

Commercial terms are captured once in the CRM. A closed-won deal provisions the customer, the sales order and the Stripe subscription; each payment webhook posts gross, net and fee as one entry; the ASC 606 arrangement is created on deal close. Every payload is hashed against the Stripe event ID so a retry posts nothing twice.

The revenue spine: one deal, five handoffs, no re-typing Commercial terms are captured once in the CRM and translated into accounting entries by code, including the gateway fee.

  1. 01HubSpot

    1. Deal marked closed-won
    2. Payload: terms, products, seats

  2. 02NetSuite provisioning

    1. Validate tax ID, currency, subsidiary
    2. Create the customer and sales order
    3. Create the Stripe customer and subscription schedule

  3. 03Stripe

    1. Charge the card or dispatch the invoice
    2. Webhook: invoice.payment_succeeded with gross, fee and transaction id

  4. 04Settlement engine

    1. Debit Stripe clearing for the net deposit
    2. Debit processing-fee expense
    3. Credit accounts receivable for the gross

  5. 05Revenue engine

    1. Create the revenue arrangement and fair-value allocation
    2. Post the monthly deferred-revenue journal

Control points

  1. The gateway fee is split at ingestion, so the bank deposit matches to the cent the day it lands.
  2. Webhook deduplication by event ID: a duplicate returns success to Stripe and posts nothing.
  3. Sales reps never own tax codes or exchange rates; the translation into accounting rules is code.

Modeled composites: each design is drawn from delivered work with the client shown as an archetype. Figures live on the linked case studies and the 100x time ledger, each with a source class. How the designs are built and billed: how we work.

Frequently asked questions

Are these the actual diagrams from the engagements?

They are redrawn. The working diagrams carry client names, staff names and account details, so the architecture is published as native lane diagrams with the client shown as an archetype. The stages, handoffs and approval points are the ones that ran.

Do the AI designs write to NetSuite on their own?

No. Every AI design here reads through governed, read-only tools and proposes drafts. A named person approves, and NetSuite writes the record under that person’s role. The approval is one click, but it is a person’s click.

Where are the numbers?

On the linked case studies and the 100x time ledger, each with a source class. The diagrams themselves carry no figures beyond what those pages already publish.

Can one of these be adapted to our stack?

That is what a two-week sprint is for. The diligence read, 48-72 hours from access, shows which design fits and what it would move; the sprint delivers it as code in production, and the read fee is credited in full to the first sprint.

Talk to the architect, not a salesperson

Aissistor technology for NetSuite: the five roles a company pays for, absorbed into one governed box at a modeled 20-80% lower cost, with the existing team repurposed rather than replaced, and every outcome published in a 100x time ledger with its source class. Read the ledger.

Schedule a strategy call   Run the five-role calculator

The direct email and phone number are shared in the receipt of a verified request.