# AskDona Assessment Solution Manual: Core Concepts, Architecture & API Integration (Version 1.0)
> Working architecture reference for AskDona Assessment (formerly Batch Assessment), dated 15 October 2026: evidence-based assessment infrastructure for integration into existing enterprise systems, not a replacement for their workflows or systems of record. Statements are tagged as Current SaaS, Validated PoC, Research, Proposed API or Open; proposed API designs are not a published API specification.
- Status: Current. Last verified 2026-10-21.
- In effect since: 2026-10-15
- Applies to: AskDona Assessment (Batch Assessment in the current SaaS platform) and the proposed AskDona API. Each statement carries a status tag: [Current SaaS], [Validated PoC], [Research], [Proposed API] or [Open]. Working manual, 15 October 2026.
- Canonical: https://askdona.com/ai/askdona-assessment-solution-manual.md
ASKDONA / SOLUTION ARCHITECTURE
**ASKDONA ASSESSMENT**
**Solution Manual | Core Concepts, Architecture & API Integration**
Version 1.0 — Working architecture reference • 15 October 2026
**Positioning** Evidence-based assessment infrastructure for integration into existing enterprise systems—not a replacement for their workflows or systems of record.
**Status convention** [Current SaaS] documented existing implementation; [Validated PoC] reported customer-specific evidence; [Research] experimental findings; [Proposed API] design recommendation; [Open] requires product/engineering confirmation.
Scope: This manual synthesizes two internal source documents provided on 15 October 2026. It describes reusable solution concepts separately from browser-specific behavior. Illustrative data contracts and integration patterns are design proposals, not published API specifications.
### Contents
1 Executive overview
2 Conceptual model and terminology
3 Capability boundaries: engine vs SaaS UI
4 Reference architecture and processing sequence
5 Domain and data model
6 API-first integration architecture
7 Assessment configuration and design
8 Evidence, reasoning, and decision outputs
9 Lifecycle, reproducibility, and governance
10 Security, observability, and operations
11 Use cases and integration patterns
12 Product validation and API decision register
Appendix A Illustrative API-neutral payloads
Appendix B Source and evidence register
Working manual • 15 October 2026
---
ASKDONA / SOLUTION ARCHITECTURE
## 1 Executive overview
AskDona Assessment (formerly Batch Assessment) conducts an AI-assisted first-pass evaluation of explicit criteria against relevant documents and records. For each criterion it seeks evidence, produces a preliminary judgment, explains the rationale, and identifies supporting sources. A qualified human or the partner application retains final decision-making responsibility. [S1, S2]
The preferred distribution model is an assessment engine embedded via API into QMS/eQMS, GRC, PLM/ALM, supplier-quality and related enterprise software. The partner application remains the system of workflow and record; AskDona supplies retrieval-supported assessment outputs. API/MCP/OEM modalities are strategic options, not confirmed commercial interfaces. [S2]
### 1.1 Design principles
- **Criteria-first:** make each assessed requirement and its interpretation explicit before execution.
- **Evidence-grounded:** connect every preliminary judgment to inspectable source material; distinguish missing evidence from proven noncompliance.
- **Human-accountable:** route consequential findings to human review and approval in the host workflow.
- **Composable:** isolate engine functions from document import/export, browser controls and partner orchestration.
- **Traceable and testable:** preserve assessment configuration, document identity and execution context for later verification.
- **Conservative on claims:** do not equate stable outputs with accurate outputs, or a specific PoC outcome with guaranteed performance.
### 1.2 Current factual baseline vs target direction
| Dimension | Source-supported baseline | Future/API direction |
| :--- | :--- | :--- |
| Execution | Item-level AI assessment with RAG and source references [S1] | Programmatic job submission, orchestration and result retrieval [Proposed API] |
| Input | Excel checklist plus SaaS configuration wizard [S1] | Structured criteria and contextual parameters, optionally files [Proposed API] |
| Output | Result, comment, evidence, reference written to Excel [S1] | Structured result with citation lineage; XLSX as optional adapter [Proposed API] |
| Review | Human final judgment is the operating principle [S2] | Host application owns reviewer decisions/approvals [Proposed API] |
| Lifecycle | Published/draft/archive/copy behaviors in SaaS [S1] | Versioned definitions and immutable execution snapshots [Proposed API] |
## 2 Conceptual model and terminology
| Term | Meaning and boundary |
| :--- | :--- |
| Assessment definition | Reusable specification of criteria, label rules, evaluation instructions, applicable evidence scope and output expectations. |
| Criterion / assessment item | A single requirement, control, question or check requiring assessment. |
| Evidence source | Document or record eligible for retrieval, with source identity and optional metadata. |
| Evidence passage | Specific extracted section returned as support; must be attributed to its source. |
| Applicability | Whether a criterion should be assessed for the target/context; a distinct decision from compliance. |
| Retrieval scope | Dataset or metadata constraints limiting which evidence is searched. |
| Assessment run | An execution instance against a given target, criteria/configuration and evidence snapshot. |
| Preliminary judgment | AI-produced outcome and explanation, not a regulatory or business approval. |
| Review decision | Human/host-system accepted, corrected, rejected or escalated disposition. |
| System of record | Partner application preserving authoritative workflow status, approvals and business objects. |
### 2.1 Five-stage logical lifecycle
Criteria → Evidence retrieval → Preliminary assessment → Human review → Lifecycle and re-assessment. The first three stages are supported in the current product narrative; review is a governance principle; automated differential re-assessment and change impact analysis are areas for validation or future design. [S2]
### 2.2 Three assessment design patterns
| Pattern | Definition | Fit / maturity |
| :--- | :--- | :--- |
| Checklist-based | Predefined items imported and evaluated repeatedly | Best-supported today: existing Excel-based item import [Current SaaS] |
| Criteria-based | Applicable requirements and evidence obligations span multiple sources | Industry-specific modelling and rules require validation [Proposed API] |
| Dynamic assessment | Criteria and applicability are generated based on case context | Concept under consideration, not a confirmed production feature [Open] |
## 3 Capability boundaries: engine vs SaaS UI
Do not mistake a UI step or Excel artifact for a required engine capability. The mapping below identifies the reusable semantics behind existing screens. [S1]
| Existing SaaS behavior | Underlying solution concern | API interpretation / status |
| :--- | :--- | :--- |
| Wizard: name, description, one RAG database | Definition identity and evidence scope | Definition resource and corpus binding; one-database limitation is current SaaS, not an asserted API constraint |
| Upload XLSX assessment template | Criteria acquisition and legacy report layout | Offer structured items; XLSX import/export can remain optional [Proposed API] |
| Select Excel cell range | Item extraction rules | Normalize criteria with stable item IDs; spreadsheet range adapter optional |
| Pre-questions / fixed choices | Runtime context / metadata filter inputs | Context parameters and validated filter expressions |
| Item filters mark “not applicable” | Applicability and execution skipping | Explicit applicability outcomes, distinct from model labels |
| Configure labels and guidance | Decision taxonomy and policy | Per-definition label vocabulary and decision rubric |
| Map four output columns | Output schema and renderer | Structured fields; four-column mandatory rule is a SaaS mapping constraint |
| Custom global prompt | Assessment-level evaluation instructions | Versioned policy and prompts separate from chat configuration |
| Publish / execute / history / archive | Definition and run lifecycle | Resource states and permissions designed for API clients |
| Select subset of items | Run-scoped subset | Requested criterion IDs or selection policy |
**Source inconsistency** The original report calls the UI a “nine-step” creation process while also describing eight configuration steps plus confirmation/publication. This manual uses domain phases rather than reproducing wizard numbering. [S1]
## 4 Reference architecture and processing sequence
The following is a logical architecture, not a declaration of implementation internals or specific technology choices.
| Layer | Responsibilities | Owner |
| :--- | :--- | :--- |
| Partner workflow / UI | Case creation, reviewers, approvals, remediation, record retention | Partner |
| Integration boundary | Authentication, tenant context, idempotency, request validation, callbacks/polling | Shared contract [Proposed API] |
| Assessment orchestration | Definition/run validation, applicability, fan-out, aggregation, job status | AskDona engine [Target] |
| Criteria & policy | Item descriptions, rubrics, labels, prompts, definition versions | Shared configuration |
| Evidence services | Ingestion/connectors, extraction, indexing, metadata filters, retrieval, provenance | AskDona or agreed evidence provider |
| Assessment worker | Item query formulation, retrieval, analysis, preliminary judgment, citation synthesis | AskDona engine |
| Result / audit services | Structured outputs, source references, failure details, execution telemetry | AskDona + partner record |
### 4.1 Canonical sequence
1. Partner resolves the target object and applicable assessment definition.
2. Partner submits criterion IDs, contextual facts and an authorized evidence scope.
3. Engine validates parameters, tenant access, version and available evidence.
4. Applicability rules skip or classify inapplicable items before AI processing where configured.
5. Per eligible item, system formulates retrieval queries, searches evidence, analyzes passages and produces a preliminary result.
6. Engine aggregates labels, rationale, quotations, source identifiers, completion state and errors.
7. Partner retrieves or receives results, presents source-backed findings for review and stores approved decisions in its system of record.
8. If source or criteria changes, partner initiates a new controlled run; future delta processing requires separate specification.
The supplied SaaS report describes independent item-level agents and parallel evaluation; the exact concurrency model, scheduling and job protocol for the API are not established. [S1]
## 5 Domain and data model
| Object | Minimum proposed fields | Comments |
| :--- | :--- | :--- |
| AssessmentDefinition | definition_id, version, name, criteria[], decision_policy, evidence_scope_policy | Immutable version preferred |
| Criterion | criterion_id, statement, requirement_ref, rubric, applicability_rule, expected_evidence | Stable business keys |
| EvidenceSource | source_id, title, type, version/hash, metadata, access_scope | Never cite a file name alone if stable identifiers are possible |
| EvidencePassage | passage_id, source_id, location, quoted_text, extraction_version | Ensure verifiable span/page/section |
| AssessmentRun | run_id, definition_version, target_id, context, corpus_snapshot_id, requested_items, status | Supports historical reproduction |
| ItemAssessment | criterion_id, applicability, label, rationale, citations[], missing_evidence[], error | Distinguish statuses and outcome labels |
| HumanReview | review_id, reviewer, decision, override_reason, timestamp, run_id | Typically persisted by partner |
| UsageEvent | run_id, criterion_id, billable_state, units, adjustment_reason | API billing semantics [Open] |
### 5.1 Decision model and uncertainty
The SaaS example labels include “addressed”, “not addressed”, “not applicable” and “cannot determine”; other taxonomies (Pass / Partial / Gap; Satisfied / Not satisfied / Cannot determine) have been discussed but are not universal agreed API enums. [S1, S2]
- Separate applicability from substantive satisfaction: not applicable should carry its own rationale or rule result.
- Separate insufficient evidence from negative evidence: failure to find a document does not by itself prove a control is absent.
- Represent operational failure independently of “cannot determine” (e.g., retrieval timeout is not a business conclusion).
- Keep an explicit mapping between customer-specific labels and normalized semantics if cross-product analytics are needed.
## 6 API-first integration architecture
### 6.1 Core integration responsibilities
| Concern | Suggested AskDona responsibility | Suggested partner responsibility |
| :--- | :--- | :--- |
| Identity / context | Validate API credentials, tenant scope and resource rights | Map end users, business entities and tenant context |
| Criteria | Store/version runnable definitions where contract permits | Own policy approval and regulatory applicability decisions |
| Evidence | Perform scoped retrieval from supported evidence stores | Provide lawful access, source data, entitlement rules and record identity |
| Run | Execute and report item-level status | Trigger runs, handle retries and surface workflow progress |
| Results | Return citations/rationale/status with trace metadata | Present to reviewers, capture overrides and final decisions |
| Audit | Provide engine execution trace within agreed retention | Keep official business decision and sign-off trail |
### 6.2 Candidate resource and operation model — not a published API
| Resource | Candidate operation | Design question |
| :--- | :--- | :--- |
| Definitions | Create / version / get / retire | Immutable revisions? publishing gate? |
| Evidence scopes | Bind corpus / list metadata / validate access | Hosted corpus vs partner-hosted index? |
| Runs | Submit / get status / cancel / retrieve results | Asynchronous jobs, webhooks vs polling? |
| Item results | Get details / cited passages / export | Page and span resolvability? |
| Usage | Get consumption / reconciliation | Credits vs enterprise metering? |
| Feedback | Submit reviewer correction / adjudication | Store centrally or partner-only? |
### 6.3 Contract design requirements
- **Job semantics:** asynchronous submission, stable run identifiers, terminal/nonterminal states, partial success and cancellation.
- **Retry semantics:** client idempotency keys, duplicate detection and explicit per-item retry behavior.
- **Paging and payload size:** result pagination, bulk definitions, rate limits, attachment limits and retention.
- **Delivery:** polling or signed webhooks with event order, replay handling and acknowledgment.
- **Compatibility:** explicit API version, stable enum semantics and deprecation windows.
- **Evidence trace:** immutable source IDs/versions, locations, quotations, access-controlled links and citation validation.
- **Observability:** correlation IDs, error codes, per-item timing, search diagnostics where permitted, usage reconciliation.
### 6.4 Deployment / connection options
Source material prioritizes API, MCP and OEM/white-label distribution with QMS/GRC/PLM software vendors but does not establish supported deployment models. Candidate integration patterns are (a) AskDona-managed knowledge base with uploads/sync; (b) authorized connectors to partner data; (c) customer-controlled evidence retrieval with result normalization. Security, latency, provenance and commercial responsibilities must be evaluated separately for each. [S2]
## 7 Assessment configuration and design
### 7.1 Definition authoring
- Define an assessment target, item set, criteria identifiers, required evidence and expected applicability context.
- Specify unambiguous label criteria. Current guidance recommends a category for insufficient evidence rather than forcing a pass/fail result. [S1]
- Define instructions and priority rules in an assessment-specific prompt; current assessment prompts are separate from RAG chat prompts. [S1]
- Select approved evidence repositories and metadata keys for source scope; SaaS pre-question examples include system/category selection. [S1]
- Test a representative small item set, compare against human reference judgments and revise before release. [S1]
### 7.2 Evidence ingestion and quality
Current SaaS RAG documentation lists PDF, Word, PowerPoint, spreadsheets, CSV, text, HTML, Markdown, JSON and images among supported uploads; actual ingestion support and parsing guarantees for the API need confirmation. Strict Open XML may fail in the existing upload process; metadata CSV should be UTF-8 with BOM according to the SaaS report. These are adapter-specific compatibility facts, not inherent assessment-engine requirements. [S1]
For robust assessment, define corpus ownership, document classification, metadata schemas (for example category and sub_category), source freshness, duplicate handling, superseded versions, supported languages and retrieval eligibility. [S1]
### 7.3 Evaluation quality plan
| Test dimension | Recommended measurement |
| :--- | :--- |
| Decision accuracy | Agreement with expert-adjudicated labels by criterion category |
| Citation validity | Share of cited passages that exist and support the claimed rationale |
| Evidence coverage | Recall of required evidence across available sources |
| Abstention behavior | Correct handling of incomplete, irrelevant or contradictory evidence |
| Stability | Label and citation consistency across repeated identical or controlled runs |
| Change sensitivity | Ability to explain differences after corpus/prompt/model revisions |
| Operational | Latency, partial failures, recoverability, usage and reviewer override rate |
## 8 Evidence, reasoning, and decision outputs
### 8.1 Baseline output contract
The documented SaaS Excel mapping requires four output fields: result, comment, evidence (quotation), and reference (source file). These express engine-level outputs even though four mandatory Excel columns are an interface-specific rule. [S1]
| Canonical field | Meaning | API refinement [Proposed API] |
| :--- | :--- | :--- |
| label | Preliminary category | Return both domain-specific label and normalized semantics when appropriate |
| rationale | Explanation of why the evidence meets/does not meet a criterion | Reference evidence IDs and avoid unsupported claims |
| citations | Supporting excerpts | Passage IDs, locations, quotes, source version/hash |
| sources | Documents used | Stable source identifiers and access-controlled resolvers |
| missing_evidence | What could not be verified | Separate from confirmed negative findings |
| confidence / quality flags | Review routing signals | Define calibration before exposure; no current standard asserted |
### 8.2 Human oversight
Treat AI output as a preliminary recommendation. In medical-device safety, QMS, GMP batch-release and regulated reporting, competent reviewers decide applicability, regulatory meaning and release/safety outcomes. The absence of retrieved evidence is not equivalent to nonconformity. [S2]
## 9 Lifecycle, reproducibility, and governance
In the existing SaaS, published assessments cannot be deleted, can be archived, and may be copied when changing criteria. Editing published configurations in place risks making historical comparisons misleading. [S1]
### 9.1 Recommended reproducibility envelope
- Assessment definition ID/version, item IDs and rubric versions; evaluated target and contextual inputs.
- Corpus snapshot, document IDs and versions/hashes, ingestion/extraction/chunking versions and metadata filter expression.
- Retrieval configuration, model deployment identifier and version, prompt/policy version, generation parameters and execution timestamp.
- Returned label, rationale, exact cited passages, source locations, failures and human review disposition.
A specific security PoC reported differences after 200+ documents were reloaded, including 26 items changing from addressed to not addressed under an apparently unchanged configuration. This motivates provenance and difference analysis; it does not establish the cause. [S2]
A research draft reported label variability in 11 of 13 commercial LLM deployments, while a controlled experimental pipeline produced byte-identical results under tested conditions. These research findings do not prove correctness or implementation in the commercial product. [S2]
### 9.2 Change policy
Prefer versioned definitions and explicit new runs rather than mutating historical assessment records. Keep “what changed” across criterion, evidence, retrieval and model as separate questions. Differential re-assessment and automatic impact detection remain future-scope items pending validation. [S2]
## 10 Security, observability, and operations
### 10.1 Security boundary checklist
- Authentication method, key lifecycle or workload identity, secret rotation and API caller authorization [Open].
- Tenant isolation and data residency; document and citation entitlements enforced at ingestion, retrieval and result access [Open].
- Data classification, encryption in transit/at rest, retention, deletion, backup and incident response obligations [Open].
- Prompt-injection and malicious-document treatment; ensure retrieved text never grants permissions or changes evaluation rules [Proposed control].
- Partner vs AskDona audit responsibilities; end-user attribution when the API call is machine-to-machine [Open].
- Regulated use: validation plan, change control, supplier qualification and reviewer sign-off owned under negotiated responsibility model [Open].
The SaaS source describes Owner, User Admin, Database Admin, custom-role patterns and organization-wide overrides; these are useful precedent, not proof of API scopes or OAuth/RBAC behavior. [S1]
### 10.2 Operational states and failure taxonomy
| Class | Suggested representation | Operational response |
| :--- | :--- | :--- |
| Invalid input / unauthorized scope | Rejected before run | Correct request; do not treat as assessment result |
| Evidence unavailability | Insufficient evidence or retrieval error, clearly distinguished | Review access, corpus freshness and document parsing |
| Item evaluation failure | Failed item with error metadata | Targeted retry and transparent billable adjustment |
| Partial completion | Run status plus per-item status | Consume successful outputs without hiding failed items |
| Policy / model revision | New definition or model version | Comparability assessment and controlled rollout |
The existing SaaS report states one credit per successfully processed assessment item, provisional charging on start, and refund of failed items; test runs consume credits too. This should not be presented as finalized API pricing or enterprise billing. [S1, S2]
## 11 Use cases and integration patterns
| Host environment | Partner object / workflow | Assessment task | Human owner |
| :--- | :--- | :--- | :--- |
| Security / GRC / TPRM | System review, vendor questionnaire, control assessment | Compare controls to policies and supporting evidence | Risk, security or control assessor |
| Medical device QMS | ISO 13485/QMSR audit, CAPA, complaint, DHF | Check required records and criterion-specific support | QA/RA specialist |
| PLM / ALM | Requirements, verification, design changes, risks | Trace requirement to design/test evidence | Engineering and quality lead |
| Pharma GMP / MES / LIMS | Batch record, deviation, change-control package | Check documented evidence for review readiness | Qualified quality/release personnel |
| Manufacturing / supplier quality | PPAP, process change and supplier audit | Evaluate documented requirements and completeness | Supplier quality engineer |
These are potential fit areas. Only the security-focused PoC metrics have been cited as a reported case; other industry workflows are opportunities or design candidates rather than proof of production regulatory suitability. [S2]
### 11.1 Example host workflow: QMS CAPA evidence review
1. QMS identifies CAPA record and approved checking criteria.
2. Integration passes context and authorized SOP/deviation/effectiveness-check evidence scope.
3. AskDona assesses each criterion and returns quoted support, missing evidence and preliminary labels.
4. QMS reviewer inspects sources and records accepted/overridden decisions.
5. QMS retains formal CAPA approval, audit history, and subsequent follow-up tasks.
### 11.2 Example host workflow: security control assessment
A GRC product requests a set of control checks scoped to the selected system. Metadata filters narrow the corpus; applicability rules omit irrelevant control items. The API returns evidence-backed preliminary findings, and the GRC reviewer signs off. Existing SaaS support for filtering and item skipping informs this design; the API binding is proposed. [S1]
### 11.3 Reported PoC
**[Outdated — marked 2026-10-21]** A customer security-assessment PoC reportedly covered approximately 300 criteria and 100 target systems, with over 91% accuracy and 45% reduction in assessment effort. These figures are internally reported case-specific metrics, not independently verified platform guarantees. [S2]
**Updated (21 Oct 2026):** the PoC covered roughly 400 evaluation criteria, not approximately 300, consistent with the JSOL case on https://askdona.com/en/use-cases/security-assessment/.
## 12 Product validation and API decision register
This register should be resolved by product, engineering, security, customer success and prospective integration partners before an external API specification or SLA is published.
| Priority | Decision / acceptance question | Current status |
| :--- | :--- | :--- |
| P0 | What are the first generally available API operations, supported input/output schemas and stable label semantics? | Open |
| P0 | Which evidence architectures are supported: hosted corpus, connectors, partner retrieval? | Open |
| P0 | How are tenant identities, scopes and citations authorized end-to-end? | Open |
| P0 | What are job semantics: concurrency, cancellation, retries, idempotency, callbacks and partial success? | Open |
| P0 | What is the regulatory/human-review responsibility model and accepted intended-use language? | Open |
| P1 | Which run snapshots enable attribution of changed results and meaningful reproduction? | Open |
| P1 | How are definition versions, document versions, historical run records and deletion managed? | Open |
| P1 | Which accuracy/citation/stability benchmarks are required for release? | Open |
| P1 | What are limits, SLA, uptime target, support and customer-visible telemetry? | Open |
| P1 | What is API metering/pricing relative to existing SaaS credits? | Open |
| P2 | Will MCP/OEM, SDKs, webhooks, white-label exports or bidirectional feedback ship? | Open |
| P2 | Which dynamic criteria/applicability and change-impact features are roadmap versus implemented? | Open |
### 12.1 Recommended phased implementation
| Phase | Suggested deliverable | Exit evidence |
| :--- | :--- | :--- |
| Foundation | Stable criteria + corpus reference + run + structured item results | Successful repeatable checklist workflow |
| Enterprise pilot | Async execution, granular source lineage, RBAC, telemetry, versioned runs | Partner QMS/GRC pilot acceptance |
| Scale and assurance | Document-version trace, evaluation test harness, reliability controls | Evidence/citation QA and operational thresholds met |
| Advanced | Dynamic criteria, change impact, re-assessment and richer partner automation | Domain-specific validation, not assumed availability |
## Appendix A Illustrative API-neutral payloads
The following JSON objects specify concepts only. They are not actual endpoint names, published schemas or confirmed API fields.
```json
{
"assessment_definition_version": "security-controls/2",
"target": { "type": "system", "id": "SYSTEM-123" },
"criteria": [{ "id": "CTRL-001", "statement": "..." }],
"context": { "deployment_type": "cloud" },
"evidence_scope": { "corpus_id": "CORPUS-42", "filters": { "system_id": "SYSTEM-123" } },
"client_request_id": "partner-request-001"
}
```
```json
{
"run_id": "RUN-EXAMPLE",
"status": "completed_with_review_required",
"definition_version": "security-controls/2",
"items": [{
"criterion_id": "CTRL-001", "applicability": "applicable",
"label": "cannot_determine",
"rationale": "Required proof was not found in the accessible evidence.",
"citations": [{"source_id": "DOC-9", "source_version": "v3",
"location": "section 4.2", "quotation": "..."}],
"missing_evidence": ["approved operating record"],
"execution_status": "succeeded"
}]
}
```
The example “cannot_determine” state describes evidence insufficiency, not a finding of compliance failure. A production contract must define official enums and whether citations may be empty or inaccessible.
## Appendix B Source and evidence register
| Code | Source document | Use and qualification |
| :--- | :--- | :--- |
| S1 | AskDona Batch Assessment technical research report, 15 Oct 2026 (21 pages) | Documents current SaaS steps, RAG processing narrative, Excel mappings, credits, security roles and lifecycle. Secondary research synthesis, not a verified API contract. |
| S2 | AskDona Assessment knowledge summary, 15 Oct 2026 (5 pages) | Consolidates product direction, a reported customer PoC, industry use cases, partner architecture, Assessment Science research and open questions. Explicitly an internal working note, not externally verified. |
**Editorial guardrails:** “Current SaaS” reflects reported behavior in S1; “Validated PoC” denotes results shared within S2 rather than independent certification; “Research” denotes bounded experiments; “Proposed API” is guidance; “Open” requires implementation and legal/product validation. The prospective renaming of Batch Assessment to AskDona Assessment is described in S2 as planned for 2 November 2026—not completed as of this document date.
Working manual • 15 October 2026