Prospectus
The short institutional case. It answers the two questions a research office or a department actually asks first: what do you actually do, and how would we buy it.
Prospectus · PDF, v2 · Short form, 7 sections
Organizations do not need better sentences. They need documents that survive complex production, terminology that holds across a set, controlled multilingual work, review that can be traced, and a dependable path from intake to release.
This prospectus is deliberately short. It maps four customer types to a configured response and a business value, states why an eighteen-year language-services operation is positioned to build this, and lays out the service stack in layers.
Four customer types, four different answers. Academic departments get editing, translation, formatting, reference work and thesis and publication support, which amounts to a governed service layer without hiring a new internal team. Publishers and journals get submission preparation, reference integrity, cross-file QA and author communications, which shortens production cycles and reduces language-driven returns. Legal and regulatory teams get termbases, bilingual alignment, version control and offline-capable workflows, because their problem is consistency and evidence on high-stakes document sets rather than fluency. Language-service partners get white-label modules, managed workflows and overflow capacity, which is new capability under their own brand.
The service stack, in layers. Outcome first, then core transformation (editing, translation, formatting, reference work, conversion), then assurance (human review, second editor, specialist verification, QA report, risk register), then add-ons (reference intelligence, presentation workflow, terminology, cross-file consistency, document forensics), then lifecycle (follow-up, reviewer response, resubmission, proof stage). A customer can buy one layer or all of them. The layering is what makes a scoped pilot possible.
Why an editing company is the right builder for this. Not a claim about technology. A claim about operational memory: eighteen years of specialist academic and multilingual document work, and the accumulated knowledge of tracked Word files, handovers, second editing, formatting, references and delivery. The software was developed around real jobs, real exceptions and real customer-service needs rather than around a demonstration. Customer service runs in English, Traditional Chinese and Japanese.
Security is configured, not promised. Requirements differ by institution, jurisdiction, document class and deployment, so the prospectus presents a control profile to be configured against rather than a slogan. It covers identity and least privilege, tenant separation, encryption in transit and at rest, retention and deletion profiles, secure development requirements, restricted logs, approved AI tasks with human release, and job manifests and checkpoints. It carries an explicit statement that Uni-edit is not certified and that formal conformity requires separate assessment by an authorized body.
Four deployment choices, because assurance has to fit the actual control boundary: a managed environment with customer-specific identity, storage, budgets and policy; a customer-owned deployment with agreed operating responsibilities; hybrid processing where controlled local tools handle selected stages; and an offline-first environment for defined runs that prohibit cloud inference at production runtime.
It ends on a paid pilot, not a proposal. Difficult live material, measurable acceptance criteria: document fidelity, turnaround, reviewer effort, unresolved findings, terminology consistency, evidence completeness, and user experience. The output is a scoped operating design and a commercial proposal, not an overbroad promise.
Universities, research organizations, research offices, programme owners, and specialist document teams.
We already have editing suppliers.
A workflow assessment call.
Uni-edit holds no ISO certification, accreditation or independent conformity assessment. Uni-edit can develop and configure controls to support a customer's security, privacy, contractual or sector requirements, and the prospectus maps them so procurement has something to assess. Certification and formal conformity require separate assessment by an authorized body.
The service stack describes what can be configured for an engagement. Scope, service levels and commercial terms are agreed per customer, and no pricing is published because none is fixed.
