DriftFence is designed to keep protected workflow data in your repo.
DriftFence is a local CLI and GitHub Action. The core product does not require sending repo contents, workflow traces, or protected contracts to a DriftFence-hosted service in order to run.
This page covers the public website, public evaluation surfaces, and early commercial conversations. If a later paid pilot requires private materials or a different handling model, that should be covered in the commercial agreement for that pilot.
What the public site may collect.
The public site may collect ordinary website delivery data such as server logs, basic request metadata, and the information you choose to share through public GitHub issues, structured fit-review intake fields, or later private email correspondence.
If analytics or ad-attribution tools are enabled on the public site, they should only be used to measure campaign quality, results-page engagement, fit-review starts, and fit-review submissions. Source attribution should stay limited to ordinary marketing data such as page path, referrer, and campaign parameters. This page should be updated as those tools are added or changed.
What DriftFence itself does not require.
The default product path is local and Git-native. DriftFence runs in your repo, compares repo-stored contracts to test-generated traces, and produces repo-local reports. No hosted DriftFence control plane is required for the launch product.
- No default upload of workflow traces to a DriftFence service.
- No default hosted contract storage.
- No runtime production traffic collection.
How information should be shared.
Use public GitHub issues only for non-sensitive product questions, bugs, and documentation feedback. Use the GitHub private vulnerability reporting path described on the security page for suspected security issues.
Do not post secrets, private repository contents, or customer data in public issues.
How to reach us or ask for changes.
Today the practical channels are the private workflow fit-review page for commercial and fit-review conversations, and GitHub issues for public product questions. Security-sensitive reports should use private GitHub vulnerability reporting.