RIL is inside Deploy
RIL means Retvest Intelligence Layer. It is included in Retvest Deploy as the system of record for AI work. It connects the context, activity, decisions and evidence behind the work. It is not a separate product purchase.
People and agents both have a role
A useful record distinguishes the employee or customer, the AI agent, the tools acting on its behalf and the human who approves or corrects the work. The intended capture scope includes identity, authority, input context, source references, model and tool activity, effects, outputs and review history for supported workflows.
This is not a claim that every employee action, device or integration is already captured. The current activity foundation and broader native recording, company investigation and integration coverage have separate qualification boundaries. Agree the enrolled surfaces and record fields for your pilot.
Define what belongs in the record
- Context
- The inputs, instructions and relevant source context used for the task.
- Activity
- The steps and AI work behind the result.
- Decisions
- Review, corrections and the authority behind a decision.
- Evidence
- The records, receipts and references that support the outcome.
Follow work through its lifecycle
A Work Run provides the unit around which work and review can be discussed. Correction history and review decisions should preserve the relationship to the original work. Agree which workflows and evidence fields are included in your pilot before relying on a record for a business decision.
Keep a correction connected to its history
A correction is a proposed change related to a Work Run. The correction history and audit record describe that proposal and its review. Applying, rejecting or requesting a retry is a separate decision; those actions need the required authority and current Work Run version.
If the record has changed, read it again before deciding. If a write times out, reconcile its outcome using the record and request metadata before trying again. An uncertain network response is not evidence that the action failed.
Plan access and retention
Recording work does not mean every user should see it. Define who may read, review or export records, which information must be retained, and when it should be removed. Private work requires its own access boundary; an administrator role alone should not imply access to its contents.
Agree the record requirements
Specify which task context, activity and review decisions are in scope; which supporting artifacts must remain available; and who can export them. Set retention around the business purpose and information involved. Record fields and export formats must match the version delivered for your pilot.
Use a Work Run identifier to keep related records together. Preserve the original record when explaining a later correction instead of presenting a revised answer as though no earlier decision existed.
Use the record with context
A receipt or hash can help reconcile an artifact; it does not establish that an AI answer is factually correct or that a business process is legally compliant. Define the human review and evidence requirements for the use case.
Explore RIL inside Deploy → / Read API and Work Run concepts →