Start with a decision, not a platform migration.
Choose one consequential decision with a named owner, a repeatable operating path and an outcome that matters. Define the evidence available at decision time, the policy that governs it, who may approve or override, the action that follows and the outcome to observe.
DTF connects those elements under one decision identity. The source systems continue to own their data, policies, workflows and execution responsibilities.
Evidence
Identify the source, fields, timing and evidence required for the decision.
Policy
Bind the applicable policy version and its material constraints.
Authority
Define who may recommend, approve, reject or override.
Action
Record the authorised action and material alternatives.
Outcome
Declare the later result, observation window and measurement method.
Installation follows the customer's control boundary.
DTF is built around a Node.js API, a React Workbench and a PostgreSQL-backed decision-evidence store. The codebase supports containerised deployment, but a production installation still requires an agreed operating design.
Customer-hosted and managed patterns each require explicit decisions about identity, tenant boundaries, network egress, secrets, key custody, backups, monitoring, retention and supplier access. A deployment is not secure merely because it runs in a container or customer environment.
API and Workbench
Authenticated services record decisions while Workbench makes the retained record inspectable.
Evidence store
PostgreSQL retains structured decision evidence according to the agreed retention design.
Approved interfaces
Authenticated HTTP APIs and approved read-only connectors or loaders link existing systems to DTF.
Customer-specific design
Identity, access, keys, networking, backup and monitoring are configured for the actual environment.
A practical implementation path.
The first implementation should prove one complete decision path before expanding to more teams, systems or decision types.
Choose the decision
Name the decision owner, operating problem, population and success measure.
Define the contract
Map source identity, semantics, policy, authority, action and required outcome.
Use approved access
Configure the API or read-only integration in a non-production environment.
Test verification
Exercise complete records, missing evidence, changed copies, replay and refusal paths.
Release through governance
Obtain security, privacy, data-owner and production approvals from accountable people.
Measure and support
Monitor the service, retain evidence, attach outcomes and manage releases through change control.
Using DTF means inspecting the decision, not just the answer.
A model, rule or person may produce a recommendation. DTF records whether it was accepted, rejected or overridden, which authority applied and what action was authorised.
Operators and reviewers use Workbench to inspect the record, verify its integrity and replay it against the dependencies retained from decision time. When the outcome matures, DTF links it using the declared measurement method and evidence limits.
Open the complete record
See the evidence, policy, authority, action and available outcome together.
Check integrity
Confirm that the retained record and its required dependencies remain consistent.
Reconstruct the decision
Use the bound versions that governed the original decision rather than current state.
Connect what happened next
Attach the observed outcome without converting correlation into an unsupported causal claim.
The customer retains the authorities DTF cannot assume.
A working implementation needs a decision owner, data owner, policy owner, security or infrastructure owner and an accountable production approver. Those roles decide permitted use, access, policy meaning, operational release and acceptable evidence retention.
DTF records those controls and decisions. It does not replace customer governance, legal judgment, security approval or human accountability.