What does a Data Trust FTE own?
A Data Trust FTE on ftes.ai owns the trustworthiness of the numbers every other e-commerce Digital FTE works from. It sits in the Office of the Owner department because it serves the owner rather than any one function, and it is judged on data freshness and the reconciliation pass rate. Its outcome is a negative one, and deliberately so: no role acts on stale, degraded or failed data.
It does not own the data itself. The store platform, the returns portal, the warehouse feed and the help desk remain the systems of record. The Data Trust FTE owns the checking between them and the state that results.
How does reconciliation work?
Reconciliation means cross-checking the same quantity in two systems that should agree. Order counts and revenue between the store platform and the ftes.ai record. Refunds between the returns platform and the store's refund lines. Inventory between the store and the warehouse or 3PL feed. Ticket counts between the help desk and the tickets the Order Support FTE handled. Each check runs on a schedule and again after every sync, and each produces a pass, a variance within tolerance, or a variance that crosses it.
The tolerance per domain is set by the owner in the Setup tab, because an inventory variance of a few units on a bin count is normal and a revenue variance of any size is not. The check is deterministic: it is a query, never an estimate.
What is a trust state, and who reads it?
A trust state is the label the Data Trust FTE publishes per data domain: fresh, when the last sync succeeded within the domain's window and reconciliation passed; stale, when the sync is older than the window; degraded, when reconciliation found a variance beyond tolerance; and failed, when the source could not be read at all. The states are visible on one page in the workspace, with the last sync time and the reconciliation result behind each.
Every other Digital FTE on the store must consult the trust state of the domains it depends on before producing a recommendation. A Buyer FTE proposal that depends on inventory reads the inventory state first; if it is degraded, the proposal is withheld or labelled, and the Buyer FTE's brief says why it went quiet.
What is withheld, and what is escalated?
A recommendation built on a degraded or failed source is withheld from the morning page, or shown with an explicit label that names the degraded domain, depending on the owner's setting. Nothing built on bad data is presented as if the data were good. When a variance crosses tolerance, the Data Trust FTE raises it to the morning page itself: the two systems, the size of the gap, and the records behind it, such as the nine SKUs where the warehouse and the store disagree.
The escalation is a request for a human decision about repair. The Data Trust FTE does not correct a stock record or re-run a refund; it names what to repair and where, and records that the repair happened when the next reconciliation passes.
What does the Data Trust FTE never do?
It never repairs data, because a correction to a system of record is a human decision with consequences the FTE cannot see. It never displays a number as zero when the source could not be read; a missing source is named as missing, because showing zero has cost stores real money in markdowns and reorders decided on a blank. And it never lets a degraded state pass silently: the roles that depend on the domain say why they went quiet, and the owner sees the state on the trust page.
It also never crosses organizations. Its reconciliations, states and history are scoped to your organization, like every other role's work on ftes.ai.
What does it report, and how honestly?
The Data Trust FTE reports the reconciliation pass rate, the freshness of each domain against its window, the variances raised and resolved, and the proposals withheld or labelled because of a degraded source. It keeps a history of data quality, so a decision made last quarter can be judged against the data that was available at the time, which is what an audit asks for.
It does not report that the data is correct. It reports that two systems agree, or do not, within a tolerance the owner chose; agreement between two wrong systems is a limit it states plainly.
How does it work with the other roles, and in which tools?
Every role on the store reads the Data Trust FTE's states; the Chief of Staff FTE carries its variances onto the morning page; the Warehouse Officer FTE's receipt reconciliations and the Inventory FTE's stock truth feed the inventory domain. It reads the store platform, Shopify, WooCommerce or BigCommerce, and whichever of Loop Returns, ShipStation, the warehouse or 3PL feed, Gorgias, Zendesk and Klaviyo the store has connected, with read-only permissions granted per system and revocable at any time.
It comes early in a store's hiring order. A store that hires functional roles before it can trust the data they work from is asking for confident wrong proposals, and the Data Trust FTE's job is to make that impossible.