More Applications, the Same Accountable Routes
How transaction routing connects an extended enterprise — and why recovery, reconciliation and quality belong in the foundation.
Don Gunter, GKyu Tech — developed with Codex. October 24, 2026.
A dollar entered at a register can leave evidence in several places: the register, a payment client, a gateway and an issuer. Each participant has its own responsibility. A successful message exchange tells us something about that journey. An accountable system lets us inspect what each participant actually accepted, recorded and returned.
Our latest Workstation iteration makes that journey visible. The picture below comes from the native desktop presentation. Its highlighted connection follows retained receipt references between simulated service actors. Pressing Play selects observations; it cannot send another payment.
This is the expansion of P we have been working toward: more useful application combinations over a reusable feature set, F. Our shorthand is P = (S, w, C): selected registered features, configured weights and application configuration. Types, dependencies and operating contracts constrain which combinations make sense. The W, the engineering work, includes modeling, adapters, generation, testing, correction and review. A screenshot demonstrates an observable capability. The change journal and tests establish a narrower, checkable account of the work behind it.
The current demonstration brings together retail, banking, a credit-card company, an ATM company, payment services, equipment and organizational views. All funds, companies and addresses in these examples are fictional. We are testing a Phase 1 foundation with functioning local workflows and explicit unfinished interfaces.
A company and a payment server are different productions. One describes a business composition with places, equipment, accounts and relationships. The other describes a software participant. A company can operate several sites and applications. Customer, supplier and member describe account relationships to parties; they do not replace party identity. Keeping these distinctions lets us change a grouping without accidentally changing who owns a balance.
The small thing at the center is T: a processing or translation boundary with defined inputs, recognition rules and outputs. Depending on its contract, it may push, pull or pump records. It can route a recognized token, translate a representation, forward a journal selection or call a handler. It does not require a thread, process or remote machine of its own.
Conceptually, the route is compact:
source record
-> admit its declared representation and context
-> select the configured route / translation
-> destination handler or journal
-> retained outcome / receiptEach arrow has a contract. File access belongs to the provider. Record integrity and source identity belong to the data/accountability boundary. Eligibility, account authority and posting decisions belong to business policy. Presentation selects and renders the resulting information. Putting a record in a parent journal does not, by itself, authorize a financial posting there.
Printing is an optional presentation. A sales, receiving or waste receipt can be retained as compressed text inside the electronic journal (EJ), linked to its ticket and source context. With the identified encoding and codec, that text can later be displayed, shared, reported or printed. Retaining the issued text also allows it to be retrieved without silently substituting wording from a newer template. Compressed NCR receipt text is one reference behind my practice of treating these receipts consistently across transaction kinds.
The structured provider outcomes in our graph and the operator-readable receipt text are related representations with different purposes. Neither paper nor compression supplies posting authority or proves completion. The current demonstration retains structured outcomes; its financial-to-common-binary-EJ adapter, including this compressed-text binding, remains an integration boundary rather than a completed feature.
REST, an API or a local callable route gives us an interface through which those contracts can operate. Protocol framing and encoding belong in adapters; business meaning and authority remain explicit policies. A transport acknowledgment, an admitted document, an approved transaction and a settled payment are separate observations. X12 makes a useful distinction here: its 997 describes syntax acknowledgment without establishing the semantic meaning of the encoded information; its 820 serves payment-order/remittance purposes. Our external X12 and ISO wire profiles remain integration work. X12 997, X12 820.
The same separation applies to physical access. An isolated terminal can appear in an inventory while having no network route. A manual custody relationship can exist without becoming a cable. Declaring that distinction early gives later adapters somewhere precise to attach.
We now exercise two processing arrangements. In one, eight kernel instances route through local callables inside a single process. A retained seven-request scenario can advance by steps and recover its cursor. In the other, eight owned worker processes communicate over loopback interfaces. Both use the same reference policy kernel and per-actor journal provider, with independent data scopes. The Workstation observer reads service results and publishes views without sending financial commands. These are tested local arrangements; they establish neither WAN performance nor production deployment readiness.
The bank owns one ATM context; the ATM company owns another. Their customer balances, cash accounts and journals remain separate. An in-store charge sale posts a local customer receivable. An external credit-card sale follows an issuer route. Reusing the machinery preserves those differences in meaning.
The reference profile uses integer minor currency units and scaled quantities, with an explicit rounding rule. It does not implement a jurisdictional tax engine. A routing key identifies a destination; account ownership and policy determine what can be posted when the record gets there. Even balanced entries need those other checks: an internally consistent record can still represent the wrong account, amount or authority.
Our non-reset totals, or NRT, retain an epoch and cumulative debit/credit information per actor. A reporting interval is a selection between accountable boundaries. Opening a view, capturing a report or changing the calendar does not reset those counters. The site report compares independent receipts and interval evidence under a declared policy. It does not silently adjust money, close accounting periods or establish external settlement. Missing baselines and unresolved findings stay visible.
A failed exchange is where this distinction earns its keep. Suppose an issuer commits, but its reply is lost. The caller cannot safely infer that nothing happened. Our test retains the request identity and a pending outcome, then retries that same identity to obtain the retained result. It does not switch gateways and create a fresh payment after an ambiguous capture. Concurrent withdrawal tests also check that reserved funds cannot be spent twice. These are bounded tested contracts, rather than a claim of universal exactly-once delivery.
Record integrity and business validity need separate recognizers. An incomplete or malformed record must not import as a good transaction. A well-formed request can still fail eligibility or authority checks. Retaining the rejected representation lets an operator investigate without promoting it into accepted state. A digest helps compare bytes; it does not authenticate the sender or prove the truth of the content.
Get Don Gunter’s stories in your inbox
Join Medium for free to get updates from this writer.
This is also why supply-chain interruptions are more than a broken delivery route. An extended enterprise depends on several flows arriving in a usable relationship: goods, information, instructions, acknowledgment and payment. CISA describes how dependencies can transmit disruption across infrastructure systems. OECD identifies particularly consequential dependencies through disruption risk, importance and limited substitution. CISA infrastructure dependencies, OECD supply-chain interdependencies.
Consider an illustrative delivery of perishable stock. The truck arrives, but the lot identity or temperature evidence is missing. The goods are physically present; the receiving decision is unresolved. If the system treats arrival as permission to release, it can distribute a problem before anyone recognizes it. If it treats every missing message as a lost shipment, it can order replacements unnecessarily. Stock availability, traceability and release authority are different facts.
Now consider the information and money alongside that shipment. A missing acknowledgment may prompt a duplicate order. An invoice may arrive before receiving evidence. Payment uncertainty can leave both parties with different views of their position. A downstream production schedule can fail while an upstream dashboard still looks healthy. These are example failure paths, not claims that our current simulator implements purchasing, cold-chain monitoring or supplier settlement.
There is a software supply chain here, too. An incompatible grammar or unreviewed application update can interrupt the flow even when the cable and business are healthy. Our compatibility correction allows presentation registrations to change without rekeying a financial book. It preserves the original source and epoch; other policy changes still require an explicit migration boundary. Compatibility is something to specify and test.
That graph helps explain the engineering problem. A node being present does not guarantee a usable path. A usable path does not guarantee the right authority or adequate capacity. An alternative may exist at a different cost, and changing the query must not rewrite previously committed history. The route planner supplies one part of the answer; policy decides whether the alternative is acceptable.
The response to an interruption therefore needs an accountable state: what was last committed, what remains pending, who must act, and what evidence permits the next transition. Faster transport alone cannot supply those answers.
Actual browser replay of native planner results. Closing link 2 changes the selected route from a cost of 420 to 500 synthetic minutes. A disconnected route and an isolated custody point return no path. These are fictional route costs, not driving directions.
The recovery tests stop owned workers at designated boundaries. Interrupted staging retains the earlier committed state and pending work, blocking further advance. Interruption after a completed end frame recovers the newer state and its cleanup requirement. Forwarding through site and enterprise mirrors preserves the original namespace; repeating the parent merge adds zero tickets. These tests exercise process interruption, not hardware power-loss durability.
This is where the connection to hazard analysis becomes useful. FDA describes HACCP through hazard analysis, identifying critical control points, limits, monitoring, corrective action, verification and records. Its food-safety meaning is specific; our engineering use is an adaptation of that control discipline to information, control and financial flows. The financial demonstration is not a HACCP plan or certification. FDA HACCP principles and application guidelines.
Control questionApplication to this engineering workWhat can go wrong?Duplicate posting, ambiguous outcome, incomplete record, wrong owner or missing evidence.Where can that failure be controlled?Admission, account-authority, reservation, commit and reconciliation boundaries.What must hold at that boundary?Declared schema/context, retained request identity, valid transition and balanced permitted postings.How do we notice deviation?Pending state, refusal records, cumulative counters, receipt comparisons and timed observations.What response is permitted?Same-identity retry, blocked advance or review; an adjustment needs its own authority.How do we verify the control?Independent checks, restart/interruption tests, duplicate and concurrency cases, and report round trips.What evidence survives?Original records, source/owner identity, outcomes, revisions and captured reports.
This table maps the design questions to our work; it is not a completed domain hazard analysis. A genuine critical control point is designated because analysis establishes why control there is essential. Adding a log statement does not make a step critical. The useful common principle is that evidence, limits, responsibility and corrective action travel with the process being managed.
The site report can be represented as JSON, portable report XML, browser HTML and a native Workstation view. Those are presentations of captured information. They retain a source relationship without pretending that independently observed books were captured in a single global atomic snapshot. A failed refresh preserves the prior accepted native report with a diagnostic, so a stale display must remain distinguishable from a current observation.
The same distinction already appears in our movement-analysis work. Changing membership, grouping, measure or time bucket changes a query and its projection. It does not rewrite the movement source. Each and pounds remain separate quantity series; journal references let the operator inspect where an aggregate came from.
That gives us a practical route toward richer business intelligence. A useful graph should have an inspectable path back to the records behind it. The current movement fixture and ACME financial books are separate demonstrations; they have not been joined into a live inventory-accounting pipeline. Their compatible design direction is what this iteration is testing.
What did our latest day’s work add? The change register identifies three completed engineering increments: 230, site accountability; 231, service discovery and workflow/route recovery; 232, native Workstation integration. The recorded application definitions expanded from 19 to 22 in the service/model bundle. The installed native composition now exposes 26 descriptors, including its overview, two workflow examples and receipt playback. Those are registered entry points with differing capabilities, not 26 finished independent products.
The service bundle produces 225 artifacts from its selected model and templates. The two workflow recipes produce 26 artifacts, including transition definitions, diagrams, guides and draft training/procedure resources. The native composition selects and adds its own views. These are different manifests with shared content, so their file counts should not be added into a feature score. Generated check sheets remain unaccepted until someone performs the checks.
The new native report source is a small generic wrapper around the existing reader and renderer. The desktop runtime was rebuilt; the authoritative native journal/graph libraries and copied SDK did not change in these three increments. We still wrote adapters, provider guards, generation and qualification tools. The gain is visible reuse with bounded changes, rather than an assertion that configuration eliminates engineering.
Retained qualification scopeRecorded resultFinancial reference54 unit tests; eight owned worker processes; 56 journey checkpoints, including 11 browser results with 178 assertions.Workflow/route reference14 recipe units; 30 existing checkpoint-contract checks; 26 native process operations; four route queries.Final installed native integration15 native regressions; 15 adapter/generator units; all 26 Explorer entries open, close and reopen.Cross-presentation observationThree requests and three same-identity retries across eight services; zero observer financial commands; published book states match their sources.
These scopes overlap and test different boundaries; summing them would obscure what passed. The final native regression process took approximately 16.2 seconds, including engine startup and 15 tests, with a sampled peak working set of approximately 2.84 GB. That is an engine/test-process observation, not an application footprint, query benchmark or energy measurement.
For the requested 24-hour comparison, the defensible evidence is the day’s three recorded increments and their retained artifacts. We did not record a complete joint labor-time baseline, a Git commit delta or a comparable alternative implementation. We therefore cannot honestly attach a measured percentage of work saved, a dollar return or a thermodynamic saving. The screenshots show expanded observable capabilities. The journals tell us which claims we can support.
Owner acceptance is still pending. The native financial views currently inspect reports and records; financial entry remains in the web application or local scenario runner. External payment networks, production security, controlled settlement and Android/store qualification remain separate gates. Our four-product handoff remains at 12 of 24 named gates; this iteration does not turn that into a release-completion percentage.
I can now review the desktop demonstration through Windows → ACME business simulation, ACME Bank Office, ACME Point of Sale and ACME observed receipt playback, following the supplied owner procedure. The next useful work is to perform those checks, retain what happened and refine the boundary that actually failed. That is the standard we want the foundation to make easier: useful applications whose behavior we can explain, recover, inspect and improve together.





