The Console assistant answers questions about the page a member has open. DALP sends each question through OpenRouter, a service that routes requests to model providers, to one fixed model that DALP does not run: ~deepseek/ sorts the question and writes the answer. The same model serves every organisation, whether it uses the free assistant on the platform's key or its own OpenRouter key.
Before a question leaves, DALP replaces the names, emails and wallet labels it finds with handles. Three kinds of text can still carry a name to the model: a name the member types that DALP does not detect, a name in pasted text under “Send documents” that matches no participant, and document text. Document text leaves as written by default on both keys, to a model provider and region that OpenRouter picks for each call. An organisation owner or a platform administrator can choose “Mask” to keep it in DALP. The organisation's OpenRouter key stays in DALP's secret store and goes only to OpenRouter, and the member's session and cookies never leave DALP. The setting is the Data sent to the model row on the Assistant page in “Organisation settings”, which also holds the model key, the capabilities, the watchers and the MCP server. To ask the assistant a question, see Search. When one request needs several controls, see Assistant plans.
Which models receive a question
DALP pins the model. No setting lets an organisation choose another model, and the free assistant and the organisation's own key use the same one.
~deepseek/ does every job that needs a model:
- It makes every decision call, a model call that must choose from a fixed list of options. The first, made for every question, asks whether the question fits the open page and whether it asks for an answer or for a change. A change request then goes to it again to pick the control. DALP takes the option the model names and treats an answer outside the options as unsure.
- It writes every answer and every draft.
- It turns a compliance policy written in words into rules, on the Compliance tab and in the Asset designer. It sees only the clause, with each value replaced by a placeholder and each word outside a fixed word list replaced by an ellipsis.
- It reads document passages and approval text when the data setting is Send documents, to pick which passage fills a field or whether a text matches what an approval does.
The ~ and -latest mark a name that OpenRouter points at the latest DeepSeek V4 Flash release, so the answering model can change without a DALP release. When the organisation has stored its own key, the Model access row on the Assistant page shows this model under “Model”.
A failed or doubtful call follows fixed rules:
- When the first decision call says the question does not fit the open page, DALP asks once more and ends the question as out of scope only when both answers agree.
- A decision call whose answer is not one of the options is asked once more, and is treated as unsure when the second answer is not one either.
- A decision call that does not answer within 8 seconds, or that fails, is not asked again. The question ends without an answer, as when the model provider cannot answer.
- A decision call refused as busy, by OpenRouter or by DALP's own limit on decision calls, is not retried, and the question ends as busy.
- When an answer would lose a sentence to DALP's check for typed figures and unbracketed names, the model is asked once, without any reads, to rewrite it.
The record of each question keeps the model that OpenRouter reported for the answer, so a reviewer can see which DeepSeek release answered. For a document, the record keeps the model of each decision call instead. The record does not name the model provider or the region that served the call.
Who receives a question
OpenRouter receives every call and passes it to a model provider that serves the pinned model. OpenRouter picks that provider for each call. DALP does not choose the provider and cannot pin it to a region, so the provider and the region can change from one question to the next.
The two kinds of key differ in whose OpenRouter account sends the question.
- Free assistant. The installation's OpenRouter key sends the question. The operator who runs the installation sets that key, and the calls run on the operator's OpenRouter account, not on the organisation's. The free assistant is the default when the installation has a key. It is shared, so it can be busy at peak times. When the installation has no such key, there is no free assistant.
- The organisation's own key. The organisation's OpenRouter key sends the question, so the calls run on the organisation's own OpenRouter account and its own quota.
Both keys send the same content: the masked question, what the assistant reads in masked form, and the document text unless the organisation chose Mask.
On both keys, each request sets OpenRouter's zero data retention filter, so OpenRouter routes it only to endpoints that declare that they keep no data. When no such endpoint is available, the assistant is unavailable and DALP does not fall back to an endpoint that may keep data. DALP sets the filter and cannot verify that an endpoint honours it.
Who can keep a question
- OpenRouter and the model provider. Zero retention is the provider's commitment to OpenRouter. DALP cannot check what the provider or OpenRouter keeps, so treat what the assistant sends as shared with both.
- DALP, in the record of the question. Each question leaves one record, which never holds the OpenRouter key. It holds:
- the question as the member typed it, and the masked text sent to the model
- the answer, with handles in place of names, and how the question ended
- the model, the token usage and the time taken
- the member's role at the time and the page the question was asked on
- any rating, with the reason and note the member wrote
- the reads the assistant made, with their inputs but never the data they returned
- the data setting in force, whether the question included text from outside DALP, and the answer of each decision call
- the handles of the conversation, with the records they stand for
- DALP, in the audit trail. Each question also writes an entry in the audit trail, and that entry keeps the request the Console sent, which includes the question as the member typed it.
- Whoever exports the questions. Readers of the “Assistant questions” tab can download the questions of a time window as a CSV file with “Export”, including each question as typed. Each export is recorded on the audit trail with its row count and window. DALP's retention does not reach an exported file.
DALP deletes the record of a question once it is older than the retention period. The operator of the installation sets that period between 1 and 3,650 days, and it is 365 days unless the operator sets another value. A daily job deletes the old records, up to 50,000 in each run, so a large backlog clears over several days. Deleting a person's DALP account deletes the records of their questions at once. The audit trail entry, which holds the question as typed, is not deleted with the record. It follows the retention of the audit trail. With no value set, the audit trail keeps entries without a limit, and the operator can set 5, 7 or 10 years. Past that period, DALP deletes an entry only once its day is anchored on the chain and in a published or acknowledged end-of-day audit report, so an entry for a day that was never anchored and reported stays.
Three kinds of reader open the records on the Assistant questions tab of the Audit trail: members with access to the audit trail, organisation owners and platform administrators. The tab shows the fields of each record, with the refusal code, the reads in words, and the masked text only when it differs from the question. Each read of the tab is itself recorded on the audit trail.
What the assistant reads
The assistant answers only about what the open page is about, and it reads as the member who asked. Six kinds of page can be asked about. Apart from an asset, DALP checks the member's access to the page's subject before it calls a model:
On an asset page the masked question goes to the model before any read of the asset's data, so it leaves DALP even when the member turns out to have no access to that data.
Each read goes through the same API route the Console calls, with the member's own session. A read the member may not make is refused, and the assistant says it cannot read that data. The Console assistant has no tool that writes. A question makes at most six rounds of reads with at most four reads in each round. A question about another asset, another participant or something the page does not cover gets one sentence saying what the page covers, and no model writes an answer for it.
What DALP replaces before a question leaves
DALP looks up the names in the question through the asking member's own search and swaps each one for a handle, a label such as holder 7 that stands for one record for the rest of the conversation, so a follow-up question can say holder 7 again and mean the same holder. The question with real names stays in DALP, in the record of the question. The models get only the question with handles.
DALP looks up at most five names in a question, within two seconds. A name past that limit, a name the search does not find, and a search that fails are replaced with “someone”, “an organisation” or “an address”, never sent as written. Emails are replaced without a search.
Some names are not detected. A name written only in lower case, a single first name that is also an ordinary word, as in “Did Will sell?”, and a name such as vitalik.eth reach the model as typed. Keep such names out of a question, or write them with a capital letter.
The assistant reads asset data to answer. It never passes that data to the model as it is stored. For each read, DALP keeps an allow list of fields and drops every other field. Names, emails and wallet labels become handles with a masked label, such as the country and the type of holder. Dates and amounts reach the model as references to a field of the read, not as values, and the Console puts the real values back after the answer returns.
Pasted text
A question longer than 140 characters is masked as pasted text, however it reached the question field: a paste, a drop, dictation or autofill. A pasted text may be up to 4,000 characters.
DALP looks up at most 20 names in a pasted text, within three seconds. A name that matches a participant becomes a handle. Under Mask, every other name becomes a numbered placeholder such as name:1. Under “Send documents”, names that match no participant stay as written. Under both values, emails, IBANs and phone numbers become contact:1, iban:1 and phone:1, and an address that matches no participant becomes address:1.
When the search cannot answer, DALP does not send the text with names left in. The question ends with “I can't read pasted text right now.” and no model call. The masked text goes first to the model, which sorts the request. When a pasted text asks for a change, the drafting model receives it marked as data from a third party. When it asks for an answer, the model receives the masked text as the question. Only the masked text leaves DALP. The record of the question and its audit trail entry keep the pasted text as the member gave it, with its names, emails and IBANs. A draft from a pasted text also records a count of what was masked.
What a draft sends
A request to change the management fee, freeze part of a holder's balance or split an asset's shares goes through the same replacement. The model also receives the name of the control and the names of its fields. A holder the request names is replaced by a handle first, and a holder field takes only a handle: never a name, a description or an address.
A draft saves nothing. The Console opens the control with the values filled in, and the member reviews every field and confirms with the usual wallet verification. The draft itself carries no verification.
What the data setting adds
The setting has two values. Send documents is the default when no choice has been stored, on the free assistant and on the organisation's own key alike. A stored choice applies on both keys.
- Mask: document text is not sent. The assistant is told that document text is withheld.
- Send documents: document text is sent as written, including any names inside it, with each item cut at 8,000 characters.
Document text means four things: a PDF a member drops on the Console, a term sheet the assistant reads on the Asset designer, the label of each election option on a corporate action, and the description the initiator typed on a multisig mint. The mint description check also sends the mint amount and the token symbol.
Under both values, names in the question and in what the assistant reads from records become handles. The one exception is a pasted text under Send documents, where names that match no participant stay as written.
Send documents cannot hide a name that appears inside a document, because DALP does not rewrite the document text. When you switch from “Mask” to “Send documents”, the confirmation says so before it saves.
Under Mask, the assistant offers no PDF reading, on the Asset designer or anywhere else in the Console.
Who can allow documents
Two conditions must hold before DALP stores an explicit Send documents choice, on the free assistant or on the organisation's own key:
- The person is an organisation owner or a platform administrator. A member cannot open the Assistant page, and the Platform API refuses the request with “Allowing documents to be sent needs an organisation owner or a platform administrator.”
- The person confirms in the “Send documents to the model?” dialog with Allow sending. The request carries that confirmation, and the audit trail records that it was given.
An organisation owner or a platform administrator can set Mask again. Adding or removing the organisation's own key leaves the choice as it was: after a removal the free assistant goes on sending documents unless the organisation chose “Mask”, and the confirmation for removing the key says so. An organisation that never made a choice keeps the default.
How DALP treats text from outside
A document or an approval text written by someone else can say anything, including instructions to the assistant. DALP treats it as untrusted data. DALP admits document text and approval text into a prompt through a single step, and no other path puts it there. Pasted text takes its own path, described under Pasted text.
Under Mask, that step never reads the text and puts the sentence “Document text is not shared with the assistant.” in its place. Under “Send documents”, it marks the text as data from outside DALP, removes invisible and control characters, breaks any sequence that could imitate that mark or a reference to a record, and cuts each item at 8,000 characters. The assistant is told not to follow instructions found inside such text, and not to repeat a handle, a figure reference or a citation found in it. A question that included such text is marked on its record, and a draft from that question keeps only values that the member's own request contains.
The model can still follow such an instruction, so DALP limits what a manipulated answer can do. The Console assistant has no tool that writes, a person confirms every change it drafts, and every read runs as the asking member, so a manipulated answer cannot read more than that member could. It can still mislead or fill a draft wrongly, which is why the member reviews each field before confirming.
The hosted MCP server on the same Assistant page is a separate door. An outside AI client connected to it can prepare a write for a person to sign, or run a write under an agent mandate that the organisation set up, within that mandate's limits and with no person confirming the write.
How an answer cites its figures
The model never types a figure into an answer. It writes a reference to a field of one of its reads, and the Console shows the value from that read in the page's own number format. DALP removes every sentence that holds a digit outside such a reference or a known handle, and every sentence whose reference points at no value in a read. Standard names that contain digits, such as ERC-3643 or T+2, and list numbers are kept. A number written as a word, such as “three”, is not checked. The check proves a figure came from a read, not that the sentence around it is right, so check a material figure on the page its source opens.
Under the answer, Sources lists up to eight records the answer relied on, such as a holder, an event, an action or a document. “Show on page” opens the page that shows the record and marks it. An answer can also carry a small table or a row of figures, built from the same reads. On the latest answer in a conversation, the line at the top opens a list of every read the assistant made. A read that the DALP CLI also offers shows the dalp command that repeats it, with a button to copy it. See Using the DALP CLI with AI agents.
Limits on questions
Each member and each organisation can ask a fixed number of questions in each window. The member's count is checked first, so a question refused for the member's limit does not use up the organisation's.
A window resets on the clock. A refused question says when to try again. When a member has three questions or fewer left, the search dialog says how many and when the window starts over. A document the assistant reads counts as a question. A question that has not finished after 45 seconds ends with no partial answer, and so does a question the model provider cannot answer.
The Usage row on the Assistant page shows organisation owners and platform administrators the questions asked in the last 7 days, the questions refused because the assistant was busy, and the limits that apply to the organisation's key. The count includes typed filters and compliance policy readings. A term sheet check and an approval brief are not counted. When members rated answers, the row also counts the answers rated helpful and not helpful. When anyone asked a question in the last 7 days, “See these questions in the audit trail” opens them, for a reader who can open the audit trail.
Draft from a document
A member can drop a PDF anywhere in the Console, or pick Draft from a document in the search palette. DALP recognises what kind of document it is and opens the control it calls for, filled in:
- A subscription agreement opens the mint control on the asset it names, with the investor and the units.
- A bank statement opens the bank rail's Payments page with each unmatched credit the statement pays and the client it names.
- An identity document set opens the verification issuance on the named participant's Verifications tab.
- A regulator or board letter that sets a filing obligation opens New obligation with the name, cadence, deadline and LEI it states.
- A term sheet opens the Asset designer, which fills the asset once its type is chosen.
The model only picks which passage of the document answers a field, or says none or unsure. DALP reads every value from that passage with its own rules, so the model never writes a field value. An investor, participant or client is filled only from a name the member's own search finds, and an address, email or IBAN in the document is never used. Each filled field shows the page and the words it came from, and a field DALP could not settle stays empty with the pages to check.
Nothing is saved until the member submits the control, with the usual approvals and wallet verification. The control opens only for a member who may use it on that page.
The PDF is uploaded, read once and deleted, whatever the outcome. DALP does not keep it for a later read. The record of the question holds the kind of document, the field ids and what was found for each, never the document text. The passages the model reads go to ~deepseek/. Each document counts against the assistant's limits.
The approval brief
A person who opens a corporate action waiting for a decision, or a multisig mint or transfer approval waiting for a co-signature, sees an Assistant brief at the top of the sheet. DALP builds it from the same records the person can open, read with their own session, so it shows nothing they could not already see. The summary and every figure come from DALP's own checks, and no model writes them.
A model sees text only for two checks. For a corporate action it reads the label of each election option, and for a multisig mint it reads the description the initiator typed, to judge whether the text says what the plan or call does. A model reads that text only when the data setting is Send documents, as What the data setting adds describes. Under “Mask” those two checks do not run and the brief shows the other checks.
The brief is a reading aid. It never blocks an approval, and it does not approve or vouch for the action. “Approve”, “Reject” and “Co-sign” work the same with or without it.
Watchers send nothing to the model
A watcher reads DALP data on a schedule and posts what it finds to the Actions page of the members who own that work. It sends nothing to OpenRouter or to a model provider. The brief on each finding uses fixed wording filled with figures from DALP, so no model writes it. A watcher therefore runs without an OpenRouter key: it needs only the assistant switched on. Each watcher is off until an organisation owner or a platform administrator turns it on under Watchers on the Assistant page, and every run leaves an entry in the audit trail.