DAACThe work we can do

Solving problems at scale.

Each workflow is a piece of work we can take on end to end: opening a sector’s scattered public record so it can be read in one place, moving a system somebody already depends on onto ground where it can share what it holds, or standing up a digital tool where the knowledge has only ever existed in people’s heads. Set out once, each one runs again wherever the same need appears, which is what lets it work at scale.

Public data consolidationIdentify the public sources, crawl and corroborate them, build the front door, and keep crawling so the front door stays true.

Problem · SCATTERED, UNKNOWN

The knowledge a sector runs on is scattered across the whole internet. It is public, and it is still hard to know about, hard to reach, and hard to hold together in one place. Anyone who needs the whole picture assembles it by hand, and it goes stale the week after they finish.

the chain

Identify the public sources, crawl and corroborate them, build the front door, and keep crawling so the front door stays true.

Each step in the order it runs, and where one stops before the next begins.

Solution · ONE PUBLIC REFERENCE

One navigable public reference for the sector, built out of sources that were only ever scattered, and answering for what is true this week rather than last quarter.

See this workflow run, start to finish ↗

Digital system development and maintenanceThe situation is read into a specification, composed into a system on the framework, verified, and re-synced whenever the framework underneath it changes.

Problem · A SITUATION, NO SYSTEM

Someone can describe their operation in full detail and still have nothing their people can use. And a system already in their hands falls behind the substrate it was built on, quietly, until a screen breaks in front of a user.

the chain

The situation is read into a specification, composed into a system on the framework, verified, and re-synced whenever the framework underneath it changes.

Each step in the order it runs, and where one stops before the next begins.

Solution · RUNNING, AND IN STEP

A described situation becomes a system people work in, and it stays in step with what it was built on instead of drifting behind it.

See this workflow run, start to finish ↗

Retranscription: turning unstructured data, knowledge or mismatched form factors into reusable data assets.

Migration of existing systems for interoperabilityThe existing system and its legacy records are recomposed on the framework, the records are conformed as they cross, and the result is parity-proved before it ships.

Problem · STRANDED ON THE OLD

An organisation depends on a system nobody can maintain any more, and holds years of records in a shape its replacement cannot read. Installing something new leaves that history outside it, and rebuilding by hand risks the thing people work in every day.

the chain

The existing system and its legacy records are recomposed on the framework, the records are conformed as they cross, and the result is parity-proved before it ships.

Each step in the order it runs, and where one stops before the next begins.

Solution · ACROSS, AND PROVEN

The system people already depend on keeps working, on a substrate that can be maintained, and the legacy records come across with it, reconciled rather than stranded.

See this workflow run, start to finish ↗

Documentation mapping to schemaSource documents are profiled, rendered against the target schema, criticised, and corrected by the operator, whose corrections return as learning.

Problem · LOCKED IN THE PAGE

An operator holds what they know in documents. The facts are on the page, in prose and tables and appendices, and nothing downstream can query a page. Someone re-keys them, or nobody does.

the chain

Source documents are profiled, rendered against the target schema, criticised, and corrected by the operator, whose corrections return as learning.

Each step in the order it runs, and where one stops before the next begins.

Solution · QUERYABLE RECORDS

Source documents become schema-conforming records an operator can query, checked by an independent critic before a person reads them, and every correction the operator makes teaches the next render.

See this workflow run, start to finish ↗

Mapping any database to a reference schemaA source database is read, conformed against the reference schema, and written out against the target, with the schema supplied rather than coded.

Problem · TWO SHAPES, ONE FACT

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 chain

A source database is read, conformed against the reference schema, and written out against the target, with the schema supplied rather than coded.

Each step in the order it runs, and where one stops before the next begins.

Solution · ONE REFERENCE SHAPE

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.

See this workflow run, start to finish ↗

Communication and engagement solutionsA change in what the organisation is triggers the rebuild of the site and of the exports drawn from the same source.

Problem · BEHIND WHAT IT IS

What an organisation puts in front of people drifts out of step with what the organisation actually is. A stale website is one instance of that, not the whole of it: the same gap opens in a one-pager still naming a partner who moved on, or an exported snapshot still carrying a figure nobody would stand behind today. Nothing marks the moment that should trigger the correction, so each surface keeps stating what used to be true until somebody happens to notice.

the chain

A change in what the organisation is triggers the rebuild of the site and of the exports drawn from the same source.

Each step in the order it runs, and where one stops before the next begins.

Solution · CURRENT, ON THE CHANGE

The same source of truth drives every surface the organisation puts in front of people, so an update is triggered by the change itself rather than remembered by whoever last touched the page. The website rebuilds because what it describes changed; everything drawn from the same source, the one-pager, the snapshot, the deck, rebuilds with it, and nothing states two different versions of the same organisation.

See this workflow run, start to finish ↗

Targeted knowledge discoveryA local source is scanned and corroborated, conformed into comparable records, and gated for discovery, permission and payment, whether it comes off the public record or out of a contributor’s own holdings.

Problem · HELD, FOUND BY NOBODY

A local supply of data sits with the people who hold it, and the market that would pay for it cannot find it. Nobody can search it, nobody can be permissioned onto it, and the routes on offer start by taking custody of the thing itself.

the chain

A local source is scanned and corroborated, conformed into comparable records, and gated for discovery, permission and payment, whether it comes off the public record or out of a contributor’s own holdings.

Each step in the order it runs, and where one stops before the next begins.

Solution · FOUND AND PAYABLE

A local data supply reaches the markets that want it: discoverable, permissioned and payable at the holder’s own discretion, with nobody taking custody of it to make that true.

See this workflow run, start to finish ↗

In full

What makes a workflow repeatable is the record it leaves behind: the same roles, the same checkpoints, carried from one run into the next. That is infrastructure the workflow stands on, and it is not sold separately.

Contact →See what it builds →