Every field. Public.
No exceptions.
See exactly what the Verdaic agent can send, why each field exists, how it's processed and how long it's retained.
"energy_wh": 0.42,
"energy_src": "measured",
"cpu_pct": 18.7,
"on_battery": true
}
Never collected — on any plan.
Anonymous mode also removes hostnames and other user-linked identifiers. Core privacy controls are never paywalled.
Only the signals needed to understand impact.
1. Inventory Default · hardware only
Device identity and capabilities used to model embodied-carbon and power models.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| manufacturer, model | Device make/model | Keys the embodied-carbon and power models | |
| chassis / hypervisor | laptop / desktop / server / vm | Decides measured vs modelled energy | |
| cpu model, cores, threads | Processor details | Feeds the power model | |
| ram, disks, gpus | Capacity and component power deltas | Used in power and capacity models | |
| os_version, hostname | Operating system and hostname | Hostname dropped in anonymous mode |
2. Power & energy Default · core product
Battery and energy metrics, modelled from CPU × power curves where needed.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| energy_wh per 5-minute bucket | Battery-measured on laptops | Modelled from CPU × curves elsewhere | Measured / Estimated |
| energy_src | measured / estimated | The honest data tag on every figure | |
| on_battery | AC vs battery per bucket | Context for interpreting energy | Measured |
3. Utilisation Default · core product
Activity and utilisation signals that explain device impact.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| cpu_pct, mem_pct | Averaged from 60-second samples | Core utilisation inputs | Measured |
| disk read/write volumes | Volumes only | I/O load and throughput | Measured |
| idle_seconds, screen_on_seconds | Input-idle time (CPU heuristic) | Power-state modelling | Estimated |
| boot / shutdown / sleep / resume | Power-state changes with timestamps | Lifecycle and uptime analysis | Measured |
4. Per-app energy Pro · opt-in
Attribution of energy use to applications. No window titles, documents or URLs.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| app name | Executable name (e.g. "chrome") | Attribution key | |
| cpu_seconds per app per day | Cumulative CPU time | Workload and efficiency analysis | Measured |
| energy_mwh per app per day | Device energy attributed by CPU share | App-energy footprint | Estimated |
5. Software inventory Opt-in
Installed software and startup items. No usage tracking.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| installed app name / version / publisher | From the OS package registry | Software inventory and compliance | |
| startup items: name, command, location | What launches at boot | Startup-bloat insight |
6. Health & patch posture Opt-in
Device health and update state to manage reliability and risk.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| battery health_pct, battery_cycles | Design vs full-charge capacity | Keep-vs-replace signal | Measured |
| SMART predict_failure per disk | Drive firmware's failure verdict | Predictive reliability | |
| os build, last_patch_at, last_patch_id, hotfix_count | Patch recency | Vulnerability exposure | |
| pending_reboot | Updates waiting on restart | Uptime and compliance |
7. Network volumes Pro · opt-in
Volume of data transmitted and received. Destinations, domains and content are never collected.
| Fields | What it is | Why we use it | Source |
|---|---|---|---|
| net_rx_mb, net_tx_mb per 5-minute bucket | Bytes transmitted / received | Network impact accounting | Measured |
Measured when we can. Estimated when we must.
The source label travels with every figure.
Read directly from supported hardware or battery counters.
AccurateModelled from utilisation and verified hardware power curves.
0.42 kWh — ESTIMATED View calculation methodHow data moves — and how long it lives.
Your organisation stays in control.
Choose what the agent can see, how it's used and how long it's kept.
A manifest you can verify.
"version": "2026-05-28T10:15:00Z",
"schema_version": "1.4",
"categories": {
"inventory": "enabled",
"power_energy": "enabled",
"utilisation": "enabled",
"per_app_energy": "opt-in",
"software_inventory": "opt-in",
"network_volumes": "opt-in"
}
}
Questions answered
Can employees see what leaves their device?
Yes. The Local Data Inspector shows every payload before it is sent. Nothing is hidden — employees can inspect, verify and export locally anytime.
Does Verdaic read files or messages?
No. Files, filenames, messages, browsing history, keystrokes, screen contents and window titles are never collected — on any plan.
What changes in anonymous mode?
Anonymous mode drops hostnames and other user-linked identifiers from payloads, so data can't be tied back to an individual.
Why is some data estimated?
Where a device can't expose a real energy counter, Verdaic models consumption from utilisation and verified hardware power curves — and labels it estimated.
Can optional categories be disabled?
Yes. Every opt-in category is off by default and controlled by your admin in the signed manifest.
How can an organisation delete its data?
Authorised administrators can export or delete all of the organisation's data at any time from the admin console.
Inspect the agent before you trust it.
Run Verdaic locally, view every payload and decide what your organisation enables.