Pillar guide
What is TimeToPoint?
TimeToPoint is the evidence layer for AI-mediated work, delegated action, and outcome-based execution. It helps organisations show what happened, who or what acted, under whose authority, with what review, and what record remains for another party to inspect.
A simple definition
TimeToPoint creates structured evidence records for AI-mediated and delegated work.
A TimeToPoint record answers six questions:
- What entered the workflow? (Input)
- Who or what contributed which part? (Contribution)
- Under whose authority? (Authority)
- Who reviewed, accepted or escalated it? (Review)
- What happened after the work was used? (Outcome)
- How should credit or compensation be distributed? (Credit / Pay)
This is the Attribution Stack — TimeToPoint's canonical evidence model.
It is useful wherever activity alone is not enough — especially when work leads to payment, approval, assurance, insurance, compliance review, dispute handling or counterparty trust.
Why normal logs are not enough
Logs are useful. They tell a technical story: what event happened, when, and sometimes where in the system. For an engineer debugging a failure, this is exactly the right shape.
For a CFO, auditor, insurer, HR leader, or client reviewer, it is usually not enough. These reviewers need a different story:
- Was the action authorised?
- Did the AI stay within scope?
- Did a person review the result?
- Can the outcome be accepted?
Logs do not answer those questions. Evidence records do.
OpenTelemetry's GenAI semantic conventions are still in development, with experimental opt-in conventions available. They are an important open primitive for instrumenting AI workflows, but telemetry is not the same as counterparty-readable evidence.
AI makes attribution harder and more important.
When AI assists work, the final output may look clean. But the business still needs to know:
- Did the human originate the work, or mostly approve it?
- Did the AI generate analysis, code, content, or decisions?
- Was the AI allowed to use that tool or dataset?
- Did a person review the output before it affected a customer, invoice or decision?
- Should the result be paid, accepted, challenged, or escalated?
Without attribution records, organisations are pushed toward two bad defaults: over-trusting outputs or over-monitoring people.
TimeToPoint is designed to provide a cleaner middle path: workflow-scoped attribution that records the work, not the worker.
The Attribution Stack — six layers, one record.
Layer 1 — Input
Input source, prompt or instruction, document or dataset, retrieved sources, prior human work, upstream system or supplier.
Layer 2 — Contribution
AI-generated draft, human-written section, AI analysis, human judgement, external source, reused template or prior asset.
Layer 3 — Authority
Agent identity, user identity, delegated authority, permission scope, policy boundary, approval requirement.
Layer 4 — Review
Human reviewer, acceptance or override, review timestamp, confidence score, reason for override, escalation decision.
Layer 5 — Outcome
Accepted or rejected outcome, customer response, financial result, operational KPI movement, downstream error, dispute.
Layer 6 — Credit / Pay
Human contribution percentage, AI contribution category, source weighting, reviewer contribution, payout or settlement rule.
Layers 1–4 are operational. Layer 5 becomes important for outcome-based AI execution. Layer 6 becomes important when AI-human work moves from cost centre to revenue instrument. Layer 6 should usually remain advisory at first.
The right level of AI autonomy depends on how verifiable the work is.
The question that matters is not whether AI can do the task. The question is whether the task can be verified without doing it again.
High verifiability
Code generation against unit tests; data extraction against labelled ground truth. Higher autonomy. Receipts captured per action. Sample audit.
Medium verifiability
AI-assisted analysis against benchmarks; vendor classification; lead scoring. Supervised autonomy. Receipts plus human review on flagged exceptions.
Low verifiability
Strategic recommendations; qualitative judgement; legal interpretation. Bounded autonomy with mandatory human review.
Consequential
Payments, contracts, clinical decisions, safety actions. Approval gates required. Receipts plus dual human approval, evidence retained 6+ years.
Trust is not assumed. It is accumulated.
Phase 1 — Shadow mode
Agent observes without acting. Receipts generated for what the agent would have done. Human still performs the action. No production risk.
Phase 2 — Assisted mode
Agent acts on low-consequence steps. Human reviews each output before it touches the system of record.
Phase 3 — Supervised autonomy
Agent acts on most steps. Human reviews exceptions, edge cases and high-consequence actions.
Phase 4 — Bounded autonomy
Agent acts within a defined boundary without per-action review. Sample-based human audit. Never unbounded.
What different reviewers want from the same record.
CFO
Was the cost real? Was the work attributable, authorised, and accepted? Is there an evidence trail strong enough to pay, hold, dispute, or escalate?
CTO
Did the agent act within scope? Were tool calls authorised? Did escalations happen on time? Can production deployment proceed?
Risk / Audit
Is the workflow inspectable? Are exceptions surfaced? Is the review chain visible? Does evidence retention align to regulatory expectations?
Insurance underwriter
Are AI deployments evidenced at policy inception and at claim? Does the deployer retain records aligned to E&O / D&O exclusion carve-outs?
ISO 42001 certifier
Does the deployer retain evidence aligned to Annex A controls? Can the certifier inspect evidence by control during audit?
Client / counterparty
Was the AI-assisted work scoped, reviewed, and accepted? Is there a record I can inspect without rebuilding the workflow?