7. What happens when an evidence connector fails halfway through a run?

A good answer should describe detection, reconciliation, recovery and ownership—not merely confirm that a connector exists.

Why it matters to buyers. Archer’s published data-feed documentation distinguishes completed, warning, faulted and other execution states. It also describes run history and counts of created, updated, deleted and failed records. That is useful evidence of the operational detail buyers should request, rather than relying on an integration catalogue. (help.archerirm.cloud)

Put it to: Ayoub Fandi and the buyer’s enterprise architect; require the proposed integration engineer to respond separately.

A strong answer should cover: - Supported objects, synchronisation direction and the authoritative system for each field. - Authentication, service-account privileges and secret rotation. - Partial runs, rate limits, schema changes, deleted objects and expired credentials. - Safe retries without unintended duplicates, conflict handling and reconciliation totals. - Evidence timestamps and the difference between source state and collection time. - Monitoring responsibility across the platform supplier, connector supplier, partner and buyer.

Ask for proof: interrupt a controlled test run, change a source record and restore access. Inspect what the platform collected, missed, duplicated or marked stale.

For each integration, request a dependency register containing its owner, support boundary, expected volume, freshness target, failure response and ongoing cost.

Follow-up: “Who receives the alert, who has authority to repair the failure, and how do we prove that the recovered evidence is complete?”

Expert quote — pending interview: [Insert approved quotation and attribution.]