Handover coordinator
handover-coordinator v1Moves a relationship from the person who sold it to the person who will deliver it, so the customer does not repeat themselves. Gathers everything the sale learned into one place, writes the account picture, records every commitment made along the way, and maps who decides, who pays and who uses it every day. It runs the internal handover before the customer hears anything, settles who says what, and keeps the run open until the customer confirms they know who to call. A handover the customer never acknowledged is not a handover.
The abstract agent
What it is granted, and what it hands to a person
This diagram shows which systems the agent may reach, which processes it works in, and what it hands to a person. Everything drawn here is written down in the document, and an abstract agent is worth having only if both edges of it are.
Runs collect-and-report three times: on the booked order, on everything the sale produced, and on the people at the customer. Runs build-by-talent for the account picture. Convenes decide-and-announce where a person names the new owner, and again where what the customer is told is settled. Convenes the briefing in which the seller walks the new owner through the account and the new owner asks what the package did not answer, and the debrief on what the sale should have captured the first time. Runs allocate-and-reconcile over the open promises and roll-call over the run's own status. Takes the booked order and the package check from the order-check agent, the binding reading from the signature-manager agent, and the account's standing from the account-monitor agent.
The plugin
What is in the package
5 skills and the systems they need, written to version 1.1.0 of the Agent Plugins standard. Nothing in these files names a product. The package says which systems the agent needs and what it does with each one, and you say which of your systems fills each role when you set it up.
handover-coordinator · 10 files · 1.0.0
com.agentcatalog.agent/NOT.mdWhat the agent does not do, and when it asks a person.
# Where this abstract agent stops Does not decide who the new owner is. A person names them, and the name is a person rather than a queue or a shared mailbox. Does not read the agreement to decide which promise is binding, which is the signature-manager agent's assessment. Does not do the delivery work or speak to the customer in place of the seller and the new owner, both of whom the run puts in front of the customer by name. Does not sell anything into the account it hands over. ## What always goes to a person - nobody who will take the account, to whoever owns delivery capacity, with the run held at the naming step, because a handover to nobody is worse than a late one - a new owner who refuses the handover, back to the naming step with the questions the package did not answer attached, before any customer is introduced to them - a sponsor at the customer who has left or handed the project on, to the account owner, with the people map corrected rather than an introduction sent to a name that no longer applies - a customer who never confirms, to the account owner, recorded as unconfirmed rather than closed, with the reminder sent through the channel they actually use - the seller still taking the customer's calls, to the sales leader, because it means the introduction did not land
com.agentcatalog.agent/RECORDS.mdThe records the agent must leave behind.
# The records this abstract agent must leave
This is the contract. An agent implementing `handover-coordinator`
leaves the following behind, on every run.
Per handover: the order as taken in, with its identifier and the
opportunity every note hangs off. Everything the sale produced, in one
place, with a date on each item. The account picture with the source
behind every claim in it. The promise list, one per line, with who made
each promise, when, and to whom. The people, their roles, who blocked
the deal, and how each one is reached. The package scored against the
checklist at a version, naming what is missing. The internal handover
with the questions the package did not answer and the answers the seller
gave. Who says what to the customer, on what date, through which
channel. The customer's confirmation, dated, with what they were told.
What the seller still owes, each item with a date, and what the new
owner now holds.
An agent that leaves less than this does not implement
`handover-coordinator`, whatever else it does well.
com.agentcatalog.agent/SERVERS.mdThe systems the agent needs, by role rather than by product.
# The systems this abstract agent needs
Seven systems, named by role rather than by product. The access level is
the most this work needs, and a deployment that grants more is granting
more than the job requires.
| Role | Access | What the access is for |
|---|---|---|
| the order system | read | What was sold, on what terms, starting when. |
| the CRM | write | The account picture, the people and the handover itself. |
| the contract repository | read | What the customer actually bought. |
| the handover record | write | The package, its score and its gaps. |
| the delivery system | write | What the new owner takes on. |
| the calendar | write | The first working session in diaries on both sides. |
| the customer communication channel | write | One introduction, through the channel the customer actually uses. |
Whoever builds an agent from this plugin writes the `mcp.json` that
points these roles at their own systems. Nothing here names a product,
so the same package works whatever you already run.
plugin.jsonThe manifest. It lists the skills and the systems the agent needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "handover-coordinator",
"version": "1.0.0",
"description": "The handover-coordinator abstract agent. Moves a relationship from the person who sold it to the person who will deliver it, so the customer does not repeat themselves.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/handover-coordinator",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"sales",
"hand-over-to-delivery",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "handover-coordinator",
"agentVersion": 1,
"department": "sales",
"abstract": true,
"works": "Runs collect-and-report three times: on the booked order, on everything the sale produced, and on the people at the customer. Runs build-by-talent for the account picture. Convenes decide-and-announce where a person names the new owner, and again where what the customer is told is settled. Convenes the briefing in which the seller walks the new owner through the account and the new owner asks what the package did not answer, and the debrief on what the sale should have captured the first time. Runs allocate-and-reconcile over the open promises and roll-call over the run's own status. Takes the booked order and the package check from the order-check agent, the binding reading from the signature-manager agent, and the account's standing from the account-monitor agent.",
"servers": [
{
"name": "the order system",
"role": "order-system",
"access": "read",
"needs": "What was sold, on what terms, starting when."
},
{
"name": "the CRM",
"role": "crm",
"access": "write",
"needs": "The account picture, the people and the handover itself."
},
{
"name": "the contract repository",
"role": "contract-repository",
"access": "read",
"needs": "What the customer actually bought."
},
{
"name": "the handover record",
"role": "handover-record",
"access": "write",
"needs": "The package, its score and its gaps."
},
{
"name": "the delivery system",
"role": "delivery-system",
"access": "write",
"needs": "What the new owner takes on."
},
{
"name": "the calendar",
"role": "calendar",
"access": "write",
"needs": "The first working session in diaries on both sides."
},
{
"name": "the customer communication channel",
"role": "customer-communication-channel",
"access": "write",
"needs": "One introduction, through the channel the customer actually uses."
}
],
"records": [
"Per handover: the order as taken in, with its identifier and the opportunity every note hangs off.",
"Everything the sale produced, in one place, with a date on each item.",
"The account picture with the source behind every claim in it.",
"The promise list, one per line, with who made each promise, when, and to whom.",
"The people, their roles, who blocked the deal, and how each one is reached.",
"The package scored against the checklist at a version, naming what is missing.",
"The internal handover with the questions the package did not answer and the answers the seller gave.",
"Who says what to the customer, on what date, through which channel.",
"The customer's confirmation, dated, with what they were told.",
"What the seller still owes, each item with a date, and what the new owner now holds."
],
"escalates": [
"nobody who will take the account, to whoever owns delivery capacity, with the run held at the naming step, because a handover to nobody is worse than a late one",
"a new owner who refuses the handover, back to the naming step with the questions the package did not answer attached, before any customer is introduced to them",
"a sponsor at the customer who has left or handed the project on, to the account owner, with the people map corrected rather than an introduction sent to a name that no longer applies",
"a customer who never confirms, to the account owner, recorded as unconfirmed rather than closed, with the reminder sent through the channel they actually use",
"the seller still taking the customer's calls, to the sales leader, because it means the introduction did not land"
],
"not": [
"Does not decide who the new owner is.",
"A person names them, and the name is a person rather than a queue or a shared mailbox.",
"Does not read the agreement to decide which promise is binding, which is the signature-manager agent's assessment.",
"Does not do the delivery work or speak to the customer in place of the seller and the new owner, both of whom the run puts in front of the customer by name.",
"Does not sell anything into the account it hands over."
],
"processes": [
{
"process": "ref/sls/hand-over-to-delivery",
"activities": [
"Take in the Booked Order",
"Name Who Now Owns the Relationship",
"Collect What the Sale Learned",
"Write the Account Picture",
"Record What Was Promised",
"Map Who Is Who at the Customer",
"Check the Package Is Complete",
"Hold the Internal Handover",
"Agree Who Says What to the Customer",
"Introduce the New Owner to the Customer",
"Schedule the Start",
"Confirm the Customer Accepted the Handover",
"Close Out the Sales Side",
"Record What the Sale Did Not Capture"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# handover-coordinator This is an abstract agent, published as an Agent Plugin. An abstract agent is a job description rather than an implementation. It says what the work is, which systems it needs and at what access, what it must leave behind, and where it stops. Any agent that leaves the records can implement it. The plugin carries five skills, no `mcp.json`, and everything the abstract agent owes under `com.agentcatalog.agent/`. ## Why there is no mcp.json A conformant server entry in `mcp.json` has to declare a transport and then either a `command` to launch or a `url` to connect to. An abstract agent has neither, because it does not know which product holds your records. Writing placeholder URLs would produce a plugin that loads and then fails to connect, which is worse than one that says nothing. Section 6.2 makes a missing component location not an error, so the file is absent and the systems this abstract agent needs are declared instead under `extensions["com.agentcatalog.agent"].servers`, as a role, an access level and what the access is for. Whoever builds an agent from this plugin writes the `mcp.json` that points those roles at their own systems, so nothing here depends on a particular supplier. ## Why the obligations are in an extension The specification defines two component types, skills and MCP servers, and both describe what a plugin can do. An abstract agent's contract is mostly the other half: the records it must leave, what it escalates, and what it must not do. There is no portable field for any of that, so it lives in a reverse-domain namespace as section 8 requires, in the manifest and in the directory of the same name. ## Where this abstract agent is used `ref/sls/hand-over-to-delivery`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/handover-coordinator
skills/build-the-account-picture/SKILL.mdGathers everything the sale produced into one place with a date on each item, writes the account picture with a source behind every claim in it, lists every promise made along the way with who made it and to whom, and maps who decides, who pays and who uses it every day. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: build-the-account-picture description: Gathers everything the sale produced into one place with a date on each item, writes the account picture with a source behind every claim in it, lists every promise made along the way with who made it and to whom, and maps who decides, who pays and who uses it every day. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: handover-coordinator agent-version: "1" --- # Build the account picture ## What it does Gathers everything the sale produced into one place with a date on each item, writes the account picture with a source behind every claim in it, lists every promise made along the way with who made it and to whom, and maps who decides, who pays and who uses it every day. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Collect What the Sale Learned** - `ref/sls/hand-over-to-delivery`, activity 3 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Map Who Is Who at the Customer** - `ref/sls/hand-over-to-delivery`, activity 7 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Record What Was Promised** - `ref/sls/hand-over-to-delivery`, activity 5 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Write the Account Picture** - `ref/sls/hand-over-to-delivery`, activity 4 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/close-the-sales-side-out/SKILL.mdCloses out what the seller still owes, each item with a date, against what the new owner now holds. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: close-the-sales-side-out description: Closes out what the seller still owes, each item with a date, against what the new owner now holds. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: handover-coordinator agent-version: "1" --- # Close the sales side out ## What it does Closes out what the seller still owes, each item with a date, against what the new owner now holds. Files what the sale should have captured the first time, so the next handover starts from a fuller package. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Close Out the Sales Side** - `ref/sls/hand-over-to-delivery`, activity 15 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Record What the Sale Did Not Capture** - `ref/sls/hand-over-to-delivery`, activity 16 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/hand-the-account-over-internally/SKILL.mdScores the package against the checklist at a version and holds the session where the seller walks the new owner through the account and the new owner asks what the package did not answer. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: hand-the-account-over-internally description: Scores the package against the checklist at a version and holds the session where the seller walks the new owner through the account and the new owner asks what the package did not answer. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: handover-coordinator agent-version: "1" --- # Hand the account over internally ## What it does Scores the package against the checklist at a version and holds the session where the seller walks the new owner through the account and the new owner asks what the package did not answer. This happens before the customer hears anything. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Check the Package Is Complete** - `ref/sls/hand-over-to-delivery`, activity 9 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Hold the Internal Handover** - `ref/sls/hand-over-to-delivery`, activity 10 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/introduce-the-new-owner-to-the-customer/SKILL.mdSettles who says what to the customer and through which channel, makes one introduction, puts the first working session in diaries on both sides, and keeps the run open until the customer confirms they know who to call. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: introduce-the-new-owner-to-the-customer description: Settles who says what to the customer and through which channel, makes one introduction, puts the first working session in diaries on both sides, and keeps the run open until the customer confirms they know who to call. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: handover-coordinator agent-version: "1" --- # Introduce the new owner to the customer ## What it does Settles who says what to the customer and through which channel, makes one introduction, puts the first working session in diaries on both sides, and keeps the run open until the customer confirms they know who to call. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Agree Who Says What to the Customer** - `ref/sls/hand-over-to-delivery`, activity 11 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Confirm the Customer Accepted the Handover** - `ref/sls/hand-over-to-delivery`, activity 14 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Introduce the New Owner to the Customer** - `ref/sls/hand-over-to-delivery`, activity 12 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Schedule the Start** - `ref/sls/hand-over-to-delivery`, activity 13 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/take-in-the-order-and-name-the-new-owner/SKILL.mdTakes the booked order in with its identifier and the opportunity every note hangs off, and records the person a decision maker names as the new owner of the relationship. Use it when running `ref/sls/hand-over-to-delivery`.
--- name: take-in-the-order-and-name-the-new-owner description: Takes the booked order in with its identifier and the opportunity every note hangs off, and records the person a decision maker names as the new owner of the relationship. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: handover-coordinator agent-version: "1" --- # Take in the order and name the new owner ## What it does Takes the booked order in with its identifier and the opportunity every note hangs off, and records the person a decision maker names as the new owner of the relationship. The name is a person, not a queue and not a shared mailbox. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Name Who Now Owns the Relationship** - `ref/sls/hand-over-to-delivery`, activity 2 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Take in the Booked Order** - `ref/sls/hand-over-to-delivery`, activity 1 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
mcp.jsonNot in the package.
Every server entry in an mcp.json needs either a command to run or a url to connect to, and the package cannot know either of those until somebody points it at their own systems. So the file is left out, the systems the agent needs are named by role in plugin.json, and you write the mcp.json when you set it up.
Setting it up
Point it at your systems
To run an agent built from this package, write an mcp.json that says which of your systems fills each role. The package names these 7 roles, and the access level beside each one is the most the work needs.
order-system · readcrm · writecontract-repository · readhandover-record · writedelivery-system · writecalendar · writecustomer-communication-channel · write
mcp.json
You write this file. It is not part of the package.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"order-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/order-system"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"contract-repository": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/contract-repository"
},
"handover-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/handover-record"
},
"delivery-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/delivery-system"
},
"calendar": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/calendar"
},
"customer-communication-channel": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/customer-communication-channel"
}
}
}
The hostnames here are a placeholder for your own. Whichever product holds each of these systems, the agent you build is yours and nobody else has to be involved in running it.
Where it works
One process, 14 activities
The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.
Hand over to Deliveryref/sls/hand-over-to-delivery · 16 activities
Take in the Booked Order · Name Who Now Owns the Relationship · Collect What the Sale Learned · Write the Account Picture · Record What Was Promised · Map Who Is Who at the Customer · Check the Package Is Complete · Hold the Internal Handover · Agree Who Says What to the Customer · Introduce the New Owner to the Customer · Schedule the Start · Confirm the Customer Accepted the Handover · Close Out the Sales Side · Record What the Sale Did Not Capture
The records it leaves
What it writes down
Per handover: the order as taken in, with its identifier and the opportunity every note hangs off. Everything the sale produced, in one place, with a date on each item. The account picture with the source behind every claim in it. The promise list, one per line, with who made each promise, when, and to whom. The people, their roles, who blocked the deal, and how each one is reached. The package scored against the checklist at a version, naming what is missing. The internal handover with the questions the package did not answer and the answers the seller gave. Who says what to the customer, on what date, through which channel. The customer's confirmation, dated, with what they were told. What the seller still owes, each item with a date, and what the new owner now holds.
Where it stops
What it will not do
Does not decide who the new owner is. A person names them, and the name is a person rather than a queue or a shared mailbox. Does not read the agreement to decide which promise is binding, which is the signature-manager agent's assessment. Does not do the delivery work or speak to the customer in place of the seller and the new owner, both of whom the run puts in front of the customer by name. Does not sell anything into the account it hands over.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Agents built from this plugin
Who has built one, and how far each one got
Nobody has built one yet. The catalog says so rather than leaving the section off, because an empty list is a fact about the document.
declare it
implements: handover-coordinator v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
A guess, not a claim
The closest things in the catalog, by description
Nobody above has claimed any of these. This is the nearest match by wording between the job written above and what publishers wrote about their own listings, closest first, and wording is not evidence: some of these will be wrong, and a job with nothing suitable still gets whatever was nearest. The publishers have never heard of this abstract agent and have promised nothing about it. What a claim looks like is in the table above, and it is signed.
Might be reached for
Not workers. These are capability that whatever does the job would use, which is a different relationship and kept in its own column for that reason.
- Handover MCP server · handover.sh · hosted · mirrored from the MCP registry Shared, versioned context that humans and AI agents can publish, review, annotate, and continue.
- CHAP Coordinator MCP server · brightbeamai.github.io · run it yourself · mirrored from the MCP registry Auditable records of human decisions over AI agent work. Approvals, edits, overrides, escalations.
- Site Rep MCP MCP server · nish3451.github.io · hosted · mirrored from the MCP registry Read-only Site Rep handoff: agent brief, pending work, first-customer receipt with payment evidence.