Supported by the source
What is the SI base unit for length, and its symbol?
Answer: meter (m).
| Base quantity | Name | Symbol |
|---|---|---|
| length | meter | m |
Source: NIST SP 811 web reference, section 4.1, Table 1. Page updated 18 August 2025.
Private AI & Workspaces
Private AI on
hardware you control.
Studio film
Run open models with sensitive documents on your workstation or private server. Search sources, prepare cited outputs and support research within an agreed processing boundary.
Your task
You need to work with confidential documents or research material while controlling where the files, model processing and outputs are allowed to go.
What you receive
A model and document workspace matched to your hardware, with tested tasks, access settings, local exports and operating instructions.
What you provide
Source rights/access, users, processing boundary and output needs.
SAMPLE · Illustrative review
Check what the source supports.
Sample review prepared from a public NIST reference. The examples show how a supported answer and a missing answer can be presented for review.
Outside this reference
How long must our company retain its documents?
Answer: Not found in this source.
This chapter describes SI units and prefixes. A company retention policy is needed to answer this question.
Scope and acceptance
Scope, deliverables and acceptance checks
Scope and deliverables.
Your proposal identifies the included deliverables and their checks. The outline below helps define that scope.
Hardware and workload assessment: model and runtime matched to document formats, volume, language, concurrent users and acceptable response times.
Acceptance criteria
Run representative tasks on the intended equipment and record accuracy, response time and memory use.
Document intake: parsing, scanned-text recognition and cited search, with supported formats, update and re-index controls and visible failure states.
Acceptance criteria
Import a new file, open its cited passage, update the index and show an unsupported-file or unreadable-page state.
Repeatable tasks: reusable instructions and workflows with named input folders, permitted actions and output locations.
Acceptance criteria
Preview a permitted file task, inspect the result and demonstrate the agreed undo or recovery step.
Processing boundary: a documented offline workstation, private team server or explicitly connected profile.
Acceptance criteria
Check the actual document, processing and output routes for each profile; test external connections separately.
Outputs and activity record: reports, tables and drafts saved to agreed folders, with a record of what ran and any information sent outside the workspace.
Acceptance criteria
Open the exported result and trace it to the source and activity record.
Access and recovery: installation, user permissions, backup, restore and export arrangements.
Acceptance criteria
Verify an authorised account and test the agreed backup/restore or export route.
Performance assessment where useful: targeted retrieval, concise context and supported caching measured against a baseline on the agreed tasks.
Acceptance criteria
Compare the same task set before and after an adjustment; report observed changes without promised savings.
Research configurations: evaluate reduced-refusal or abliterated models for research requiring broader response behaviour. Record the selected checkpoint, licence and evaluation tasks.
Acceptance criteria
Evaluate the selected configuration on the agreed research tasks; record answer quality, refusal behaviour and limitations. Reduced refusals do not establish accuracy.
Handover: configuration, operating notes, update plan, walkthrough and the agreed acceptance demonstration.
Acceptance criteria
Complete the checklist below with representative non-confidential material.
Acceptance checks to agree
Define the checks for your task before implementation.
- Source traceability: check that cited passages support the answer.
- Unsupported answers: check how the workspace handles missing or conflicting evidence.
- Access boundaries: check which users can retrieve each approved source.
- Numerical work: check agreed calculations against reference results.
- Handover: check editable exports, configuration and operating notes.
- Offline delivery, when required: test the complete agreed workflow without an external connection.
These are commissioned capabilities, configured and tested for the agreed task.
Disconnected acceptance checklist
Offline acceptance
Verify the offline workflow.
An offline scope covers document intake, scanned-text recognition where required, retrieval, model inference and output without cloud processing or an external runtime connection. The complete task is tested with external network access blocked. Access controls, backups and exported files are assessed alongside local processing.
- Cold start with external network access blocked. Load the required fonts, interface assets, document tools and model; inspect for attempted external requests.
- Import a new document, including a scanned page where recognition is in scope. Ask a question and open the cited passage.
- Update or re-index the document and show a clear failure state for an unsupported or unreadable input.
- Prepare an output, inspect its saved location and compare it with the source and activity record.
- Preview one permitted reversible file task, run it and demonstrate the agreed undo or recovery.
- Test any connected profile separately. Show the outbound payload, destination and required review before the external step.
These are commissioning and acceptance requirements.
First engagement
One approved document collection and a representative question set.
Where the work runs
Choose the operating boundary
Where the work runs.
The document, processing and output routes are agreed before installation. A locally installed interface does not establish local processing.
Offline workstation
Agreed processing boundary
- DocumentsPrepared device
- ProcessingLocal document processing and model inference
- OutputsAgreed local folders
Disconnected acceptance test
Connection: installation and model transfer beforehand; core work must pass disconnected acceptance.
Connected workspace
Agreed processing boundary
- DocumentsNamed local or company folders
- ProcessingLocal processing plus approved provider operations
- OutputsAgreed folders
Approved provider
Connection: selected task or status messages are sent through approved providers. The scope lists every connector, recipient and outbound payload.
Scroll across for document, processing, output and connection details.
| Mode | Documents | Processing | Outputs | Connection |
|---|---|---|---|---|
| Offline workstation | Prepared device | Local document processing and model inference | Agreed local folders | Installation and model transfer beforehand; core work must pass disconnected acceptance. |
| Private team server | Company-hosted storage | Company-hosted processing within the agreed network | Named team folders with access controls | Company network for colleagues; remote and external access are configured separately. |
| Connected workspace | Named local or company folders | Local processing plus approved provider operations | Agreed folders; selected task or status messages sent through providers | The scope lists every connector, recipient and outbound payload. |
| Hosted processing, optional | Source location defined in the profile | Selected prompts, excerpts or files sent to the approved model provider | Saved locally or to the agreed service | An explicit separate profile. The offline profile never switches to it silently. |
Document routes, logs and external providers
- Synced folders, backups, activity logs and account access must follow the chosen handling boundary. The acceptance check inspects those routes as well as the main task.
- A connected scope names the information sent outside: task requests, prompts, document excerpts, files or status messages. Only the approved payload and recipient are enabled.
- Local processing still requires device access controls and an agreed backup and recovery route. Hosted processing has its own provider terms and must be explicitly selected.
Choose where the work runs: local, cloud or hybrid
Deployment decision · Choosing the right architecture
Compare data handling, expected usage and the work of operating each setup. Local, cloud and hybrid each fit different requirements.
| The decision | Local / on-premises Owned or leased hardware | Cloud / API Hosted models and compute | Hybrid Split by task and data |
|---|---|---|---|
| Data & offline access | Keep processing on site. Fully offline operation needs the entire workflow to run locally. | Requires connectivity and agreement on provider location, retention and access. | Keep sensitive tasks local. Define exactly what may leave for external processing. |
| Cost & workload | Assess against steady use; lease or hardware, energy and support costs continue when idle. | Usage charges can suit occasional work and bursts; compare costs at your expected volume. | Budget for local capacity, external usage and the work of connecting both. |
| Models & response time | Choose compatible open models within memory and concurrency limits. Benchmark your actual tasks. | Access hosted models; account for rate limits, network delay and provider changes. | Select models by task. Test quality, response time and the offline fallback. |
| Operations & ownership | Assign responsibility for updates, access, backups and hardware maintenance. | Provider-managed infrastructure; your team still manages access, integration and output review. | Maintain both environments, routing rules and recovery when a service is unavailable. |
Start with the work. Then choose the architecture.
The assessment compares representative tasks, answer quality, response time, data requirements and total operating cost before recommending a deployment.
Models and adaptation
Private AI · Unrestricted models
Unrestricted models. Local. Yours.
Answers from your documents. Sources you can check.
Search approved documents and open the passage behind each answer. Documents and model processing stay inside the boundary you agree; a fully offline setup is tested with the connection off.
Reduced-refusal models. An abliterated model is an open model whose internal weights have been modified to reduce learned refusal behaviour. It can answer more of the questions that a standard model may decline.
Local by default. The setup includes the model, your document workflow and the interface on suitable local hardware. Fully offline operation is available after the complete setup passes a disconnected test.
Yours to keep. Model choice, revision, licence and support arrangements are confirmed at scoping, and the model stays replaceable.
Fewer refusals do not add knowledge or guarantee accuracy. The checks assess answer quality alongside refusal behaviour using tasks that matter to your work.
Two reduced-refusal model options, selected for different hardware: a capable laptop or a Locus server.
Capable laptopLocal candidate
Qwen3.8-27B Abliterated
A quality-focused option for local research, document work and coding. On a laptop with 32 GB RAM and a 12 GB GPU, the Q4_K_M build needs CPU/GPU sharing; context length and response speed are checked during setup.
Locus serverServer candidate
GLM-5.3-Flash Uncensored
A larger option for private research and coding on Locus hardware. The 4.05-bit EXL3 build is a candidate for its two 96 GB GPUs; deployment testing must confirm context length, simultaneous users and response speed.
Specific model recommendations, revisions and licences are confirmed at scoping. Refusal-rate figures do not establish answer quality. Optional reduced-refusal model configurations are assessed against the agreed tasks. Source review and answer-quality checks remain part of the workflow.
- Research freedom. Explore sensitive questions.
- Private context. Keep documents local.
- Offline operation. Work without a connection.
- Model choice. Keep the model replaceable.
Performance and optional model adaptation
Targeted retrieval, reused context and supported caching can be assessed against the same representative tasks. The report states the measured response time, accuracy and resource use; it does not promise a saving percentage.
Retrieval supplies source passages without changing model weights. Fine-tuning is considered only for a defined task that remains unmet, using separate evaluation examples and the applicable licence terms.
Connect your knowledge or adapt a model: retrieval and task-specific training
Your data. Your way of working.
Turn your personal database, company records and documents into a workspace that answers questions with relevant source material.
Connected knowledge
Connect your knowledge.
Search approved documents and databases, retrieve the relevant passages, and review the sources behind an answer. Update the source material without retraining the model.
Model adaptation
Adapt a model when the task requires it.
When a task needs it, fine-tune a compatible model on approved examples from your own work. Define the training data, target behaviour and evaluation before training starts.
Begin with your data, a task and examples of a useful answer. The checks assess the approach, access controls and deployment with you.
Locus hardware and responsibilities
Adel Labs × Locus
A private model environment without buying the GPUs upfront. Locus provides the leased infrastructure; Adel Labs builds the working system around your research and team.
LocusGPU rental & infrastructure
The hardware, on site.
Locus offers dual NVIDIA RTX PRO 6000 Blackwell servers installed in the client’s environment, with configuration and maintenance scoped to the workload.
Adel LabsModel setup & integration
The system your team uses.
The setup installs the selected model, connect approved documents and tools, and test the agreed tasks. Your handover includes the interface, configuration and operating instructions.
Result. From leased hardware to a research environment your team can operate.
Fully local. Offline when required.
Scope model inference, document retrieval and outputs to remain inside your environment. Any offline requirement is defined in the agreed acceptance checks.
Hardware, infrastructure and support responsibilities are recorded in writing before work starts. Capacity and pricing follow an assessment of the model, document length, concurrent users and support needs. Any remotely hosted option is scoped separately.
Fee, exclusions and handover
What sets the fee and schedule?
- Document formats and volume; scanned pages and languages.
- Model size, target equipment, concurrent users and response requirements.
- Access, backups, external connections and the agreed acceptance tasks.
These inputs determine the proposal. No fee or delivery date is fixed before the included work and dependencies are agreed.
Scope, exclusions and handover
Hardware purchases, new integrations, model adaptation, remote access and ongoing support are included only when named in the proposal.
The proposal identifies the source, configuration, access and operating notes included at handover. Third-party software and model licences remain applicable. Maintenance, update testing and further development are scoped separately.
Before we begin
Questions about this scope.
Does offline really mean no internet?
The agreed offline workflow must run on the prepared device: document parsing, scanned-text recognition, search, inference and outputs. Installation, model transfer and optional updates happen beforehand. Acceptance uses a disconnected cold start, a new document and the required interface assets.
Read the acceptance checklist →Can a team use the same workspace?
A private server can serve authorised colleagues on the company network. Document permissions, backups, remote access and external connections are specified separately. Team access alone does not establish an offline or confidential configuration.
Compare operating modes →Is it trained on our documents?
Document retrieval makes approved files searchable and supplies cited context. It does not change model weights. Fine-tuning is a separate option when a defined task and an evaluation on held-out examples justify it.
What hardware is needed?
That depends on model size, document formats and volume, concurrent users and acceptable response times. Representative tasks are tested on the intended machine before the installation scope is agreed; the results may call for a workstation or a team server.
Private AI & Workspaces
Which documents and tasks should stay within your control?
Describe the material, the people who need access and the work the prepared system must complete.