Block ‘n’ Tackle incl Football logo: TM Reg

From Theory to Proof: Closing the 33% Gap

The IBM method cited above is a design, not a guarantee — it is only as strong as the checking layer built on top of it. Over the course of a single, sustained engineering push, ChubbyChecker’s checking layer went from a set of designed-but-unproven checks to a fully live, independently-verified system. We set out each stage below in the plain order it was built, because a claim like this is only worth making if the working can be shown.

Project Nucleon: One Method, Every Transaction

Stage 2b proved the IBM method works — for the simplest possible case: an atom that needs only a single database transaction to complete, such as a plain attestation. But not every atom is that simple. A Business Process, built in the Business Process Design Studio, is a sequence of atoms — and an individual atom itself is very often a short, internal sequence of its own: authorise, then act; check a balance, then adjust it; look a record up, then link to it. Each of those internal steps is its own real, committing database transaction. The natural next question was unavoidable: does the guarantee still hold once an atom is really a sequence of database transactions, not just one?

We named the answer Project Nucleon. We call one individual, committing Postgres transaction a nucleon — the smallest true unit of database work, and the level at which the serializable guarantee Stage 2b proved live actually operates. A Business Process sequences Atoms; an Atom sequences Nucleons. An atom that needs no internal steps is simply a single nucleon. An atom that needs to authorise before it acts — as several real atoms on the network already do — is a short, ordered chain of nucleons, each one only beginning its own real database work once the nucleon before it has safely and verifiably committed.

This is not a pilot confined to one transaction type. Every one of Block ‘n’ Tackle’s business atoms — 786 distinct action types spanning accounting, procurement, payroll, asset management, and every other domain the Business Process Design Studio serves — now executes under this identical guarantee, without exception. And it was proven, not just built: five transactions, submitted at the same instant, all racing to record the identical business event, were resolved to exactly one committed winner — at the identical position in the transaction record — on every one of four independently-running database servers, with no coordination between them beyond the network’s own consensus. The losing transactions were correctly and safely rejected by the database’s own serializable-conflict machinery, exactly as the IBM method predicts.

This is what “keeping every other participant honest, automatically” means in practice, not just in principle: a mathematically-grounded guarantee, implemented once, applied everywhere, and proven live under real, concurrent, adversarial-shaped conditions — the exact scenario the 33% security question above depends on.

Project Molecule: The Sequence Itself Is Now Enforced

Project Nucleon proved every individual atom is safe, however many internal steps it needs. But a claim made earlier on this page — that a Business Process is a sequence of atoms, designed by your own Executives in the Business Process Design Studio — was, until now, a description of intent, not a guarantee the database itself stood behind. Nothing actually stopped an atom from being submitted out of order; the sequence lived only in whatever discipline the caller happened to apply.

We closed that gap and named the result Project Molecule — continuing the same chemistry analogy: a Nucleon is one database transaction, an Atom is one or more Nucleons, and a Molecule is one or more Atoms, bonded together in the exact sequence your Executives design in the Studio. Every atom submitted as part of a Molecule now carries its place in that sequence with it, and the network checks this before the transaction is even admitted: submit the right atom next, and it proceeds exactly as designed; submit anything else — the wrong atom, or the right atom too early — and the database rejects it outright, before it ever reaches a block.

This was proven live, the same way every claim on this page is: a real Business Process was designed and published through the Studio, an instance was started, and an atom submitted out of sequence against it was rejected immediately, with the database’s own reason recorded and returned to the caller. The correct atom, submitted next, was accepted, executed under Project Nucleon’s own full guarantee, and the Molecule’s own record advanced to reflect it — a durable, auditable trail of exactly which atom satisfied which step of the process, held independently of, and cross-checked against, the atom’s own execution record.

Branching now carries the same guarantee. Where an atom produces more than a bare pass/fail result — an authorisation decision, a calculated amount, a quantity against a threshold — the Studio lets your Executives design each branch of a Molecule against those real, named values: route to manual review if an amount exceeds a limit, straight to automatic approval if it doesn’t, with the comparison itself checked by the database the moment the next atom is submitted, not merely followed by convention. And every path through a Molecule can now be designed to end in one of two database-attributed states, Success or Failure — so “success” and “termination”, concepts your Business Process Types have always defined, are backed by the identical database-level guarantee as every other step in the sequence.

This is designed, not just executed, from a single screen. The Business Process Design Studio now lets an Executive browse every Molecule already built alongside the full catalogue of available Atoms, side by side; select an Atom to see exactly which values it exposes; and compose the next step onto the sequence — or fork it into named, condition-bearing branches — without leaving the page.

“A Business Process is a sequence of Atoms” is no longer only a design principle your Executives follow — it is now a rule the database itself enforces, the same way Project Nucleon already enforces the integrity of every Atom inside it.

The ITOTCCA Block ‘n’ Tackle™ relies on a strategy of mimicking a paper based Accounting System, where customers and suppliers are involved in transactions which are recorded on any of the 9 Fundamental Ledgers as balancing credit and debit entries. In multi-party Accounting the same principles apply except there is more than one payer and/or more than one payee. In a single network, a Contract Id is unique and can be referenced by all concerned parties equally, despite their own Business Processes remaining distinct.

The Business Logic in our software ensures the transactions conform to the associated contract’s terms, and the Accounting Standards (IFRS). It is comparatively straightforward to correctly update the Master Ledger (the Fundamental Ledgers) in a simple dual party system, however more is required to ensure a multi-party system functions correctly. We achieve this by coding atomistic Use Cases and “Views”, tailored to each of your and any Networked Partner Business’ Needs. The requisite data is gathered & presented and Business Logic is applied at each step.

In a business-networked environment, there needs to be a process “overseer” to guarantee the Business Logic is followed as the various participants enact their roles. We provide a Process Master for each Current Business Process, situated in your cloud installation, which follows and guides the process, enforcing rules in the backend Postgres database(s).

The abovementioned atoms can be strung together in (meaningful) sequences to reach different goals, depending on the Business Process being followed. We keep as much of the Business Logic within the database and Cloud installation as possible, including the software unit doing the Business Process Following, the Process Master in the Cloud. It achieves this by referring to database tables where steps in Process Types are recorded, including the current position of each participant in a Networked Process (not all Processes are “Networked”, in this sense, ie most are internal to a member, unless other members are involved for a payment or other Networked Transaction), and also by allowing users & machines to make (validated) decisions as necessary. This approach is safe due to the facts that: a) everything occurs within a Kademlia Global Network, b) the Processes are defined with all parties’ goals in sight, and, c) everyone’s interests are protected by sound Governance during coding.

Although our systems are based on your Executives creating the Business Contracts and on the definition and instantiation of Business Processes that satisfy the terms of those contracts, ITOTCCA delivers a full “turnkey” set of Process and Contract Types to your specifications. After the initial set of Contract Types and Business Process Types are coded, (the “atoms”), ITOTCCA continues to cater for your dynamic needs for new Database Views (and gui Screens), unless it is possible to create a new Business Process Type from existing Atoms, Use Cases, Views and Screens. In the latter case the Business Process Design Studio can be used. Business Processes can automatically recognise when they are complete (as specified by ‘success’ criteria, at Process Definition), or they may be suspended or terminated at any time as necessary. In a Business-Networked System the same logic applies, except all parties’ involved in contracts between participants (“Members”) must have their own interests guaranteed and protected as much as their partners’. ITOTCCA takes on the role of broker or middle man to assist Members to cooperate in settling on Contract Terms, Conditions and Business Logic.

Not all Business Processes require a Contract. However the opposite is true – ie every Contract requires a Business Process to throw to. In fact everything that occurs on the DApp runs in a Business Process, except that Contracts are defined and (re-)created independently, before spawning a Business Process (from an existing Business Process Type) upon instantiation. The system thus requires the prior definition of the Business Process Type (ie after the definition of the Contract Type but before the instantiation of the Contract itself) that will be the basis for the running Process, which is designed to complete the Contract requirements (or possibly to do so repeatedly). ‘Success’ criteria (referring to a state of some data on the database) have to be established for each Business Process Type, as with Contract Types. A business will have some Business Process Types which have no related Contract Type, as they will represent a range of duties the business has, outside the requirements of any actual contracts. However our DApps do retain control for you over employees’ duties and the Employment Contract Job Descriptions associated with essential and performance-measurable activities in Business Processes. These “internal” Business Processes and Business Process Types are, similarly to the case with “external” Processes & Contracts, related to (Employment) Contracts and Contract Types

A Business Process is essentially a series (defined using your Business Process Design Studio) of ‘atomic’ Use Cases and Views coded in a prior stage by ITOTCCA based on your needs. The ‘atoms’ are sequenced by you, or by us under your direction, to be executed in order; but where decision-making and branching to “child” processes is possible, to an unlimited extent. Child processes must also be defined before the entire Business Process is considered ‘completely sequenced’. These atomic Use Case series, whether branched or not, should be designed with the intention of completing every necessary step (using existing “Views” – Forms, and Use Cases) from beginning to ‘success’. This requires that all terms of contracts, and every condition of more general Business Processes; every possible eventuality relevant to the process, and all actions needed, must be covered, validated &/or completed by each party involved. The definition of a Type is a separate activity from selecting the menu item generated, and Running an actual Business Process as a unique Process on the network.

Not all Business Processes achieve ‘success’, and termination is a part of Business Process Design. A Business Process spreads out like a “tree” with its root at the commencing Use Case or View. There may be several routes to ‘success’ endpoints, with multiple failure or ‘termination’ points possible along the way. It is not allowed to have “re-entrant” or “recursive” Processes, with the exception of repeating the current step. This means a stalled or failed Business Process may need to be terminated and a new Process commenced, in order to have any way of completing the Business Process involved. In that case, there may also be underlying problems with data values and validations as set in the current Process. We provide Tech Support 9am to 8pm Mon-Sat Sydney time and 9am to 8pm Mon-Sat London time.

We use a system of reserving a data field on every record in every database for the Business Channel Number pertaining to your own organisation. This ensures all your records and only your records are accessible by you and your staff. ITOTCCA employs a user/role system such that a single user may have many roles and a role may include many users. This forms the basis for restricting access to data and methods/menus as required by the organisation.

As a customer using a system similar to The General, you would be directing us as we code the initial set of Contract & Business Process Atoms, as an included part of the development services you pay for, on a transparent Trust Account basis. Unspent development funds are returned to you.

Alterations, additions etc would be an additional cost item after the initial system development is complete. You are intended to develop your own Business Processes, using your Business Process Design Studio and existing “atoms” (use cases and views) with free Technical Assistance from ITOTCCA. However if you need us to sequence new Contract Atoms and Business Process Atoms on the Business Process Design Studio, and for any coding required (such as for new Views or Use Cases) there will be an additional cost to you, based on a reasonable hourly rate. This means that if you require new or altered forms to collect different sets of data, there is a fee. If you prefer, we can entirely take over the development of further stages, including refining Business Processes, in consultation with you, at the same reasonable rate. We can assist to the extent of dedicating one or more Build Squads to each Member Site, continuously. See The General Price Sheet for typical prices.

As your Executives and IT employees learn to effectively compose Business Process and Contract Types, with our assistance, you will become more independent of us for your Business Process Design requirements, using your Business Process Design Studio. Note that it is usually possible to add any required field to an existing table. New tables may require more investigation, as with new functions. In any case the mobile/desktop apps will have to be updated by us, and re-downloaded by you and your employees.

Trade Mark Registered

ITOTCCA

The Block ‘n’ Tackle is a Database constituent of …

The Aggregator layer carries condensed data forwarded in batches directly from the Member-Classes layer, where every transaction has already been committed under Byzantine Fault Tolerant consensus. The aggregator calculates Merkle Roots of ‘Slabs’ of 24 Blocks of Traces per business Supply Network, and forwards the results to the Tophata Server, which records them to the Hedera Blockchain. Tophata then works backwards over what it has already anchored: it replays ITOTCCA’s own Preregistration Baseline records, recalculates their Merkle Roots, and compares each to the Root previously recorded on Hedera for the relevant Network. Because the anchored Root is a tree over consensus Block hashes, that comparison establishes a specific and limited thing — that our record of your Network has not been altered since the moment it was anchored. It is tamper-evidence over our own store, and we state it that way deliberately rather than let a public blockchain imply more than it delivers. Discrepancies cause a graceful shutdown of affected networks with Alerts issued and consequent investigation.

In design — the same check, run by you, without our cooperation. The retrospective Root check above is ITOTCCA auditing ITOTCCA. Useful, but it cannot show that our record ever matched your reality in the first place, and that is the check your own auditors actually need. The material for it already exists: every Trace carries a per-record digest computed over the identified row in the identified table, and every Block already carries a Trace Root over those digests, alongside the Block-hash Root. Both are already computed and stored; the Trace Root simply is not committed to. Binding it into the Root that is already anchored, and publishing the digest construction as a canonical, byte-exact specification, lets your organisation regenerate the Merkle Leaves from your own data and prove them against Hedera by inclusion proof — no access to our systems, no request to us, nothing for us to withhold.

And it costs nothing extra to anchor. This is deliberately not a second stream of Hedera records. The funnel exists precisely to keep anchoring cheap: Traces are gathered into Slabs of 24 Blocks, Slabs into batches, and batches into one Hedera anchor. Measured on a running network, 1,865,856 Blocks resolve to 7,176 anchors — about 260 Blocks per anchor, and at up to 1024 transactions per Block that is one paid Hedera transaction standing behind on the order of a quarter of a million of yours. Committing the Trace Root into the Slab Root that is already being anchored adds one hash to a record we already pay for. It does not add an anchor, so there is no new cost to carry and none to pass on. Anchoring per Block instead would multiply Hedera traffic by 260 and would be indefensible — we mention the arithmetic because a reader is right to ask before believing an offer like this one.

What we are not yet claiming. Three things gate this, and we would rather name them than imply the capability is already shipped: the Trace Root must be bound into the anchored Root and not merely carried beside it; the leaf construction must be published canonically, since “regenerate your Leaves” is not an instruction anyone can follow without it; and the Leaf set must be provably complete, because a single missing Trace turns an honest regeneration into a mismatch that means nothing.

The reliance on a single BFT-replicated cluster as the source of truth for the Network means that operations do not require cross-node communication of raw data, because all Use Case data processing is carried out by Trigger Functions and Stored Procedures within the Master Database. The multiple middleware nodes are for the attainment of Byzantine Fault Tolerant Consensus in the Ordering and Replication of Transactions and Traces. At a level above this Tolerance, ChubbyChecker adds a final set of 132 cross-checks per Trace Block (1024 transactions), to ensure compliance beyond the limited guarantees of BFT — and, as of Project Nucleon, that same database-level guarantee now covers every business atom on the network, not a subset of them, while Project Molecule extends it one level further still, to the very order in which atoms are combined into your Business Processes (a.k.a Use Cases).

Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.