Workflowrun again on a new scope

Mapping any database to a reference schema

The same fact lives in two systems that cannot read each other's shape of it, and somebody hand-writes the mapping between them, once per pair, every time.

The problem to solve

Two systems hold the same facts in shapes that cannot be read against each other. Integrating them, or refactoring one into the other, means somebody hand-writes a mapping, once per pair, every time.

The solution it delivers

A database’s records render against a reference schema with that schema as a parameter, so the mapping is a run rather than a new piece of work.

01

The run as one route: which tools get involved, in what order, and where the chain is not mechanised yet.

TWO SHAPES, ONE FACTONE REFERENCE SHAPETarget schema asa parameterANY DATABASE (SOURCE)SCRIBEANY DATABASE (TARGET)NOT MECHANISED YETNOT MECHANISED YET

One run, start to finish. A box with an accent tick is a tool acting and opens its own page; a rounded box is an artefact or a record; a diamond is a decision the work cannot pass without. A dashed line is a hand-off the suite has not mechanised yet.

reads the declared contract
Nothing is sent. The downstream tool reads the upstream tool’s declared contract at call time, which is why substrate tools have no invoke step.
02Which tools, in what capacity
actuate
03How the work crosses between them

As with every other Scribe render leg, the handoff into a target is a contract read (Scribe reads the source and the declared target schema at render time; nothing is sent as a message), the same pattern as the Spine and Frame render targets already catalogued, generalised to an arbitrary operator-provided target.

The tools this workflow runs through