From a Written Brief to a System in Production
The process is built to run asynchronously. A written brief starts it, a fixed-price proposal follows, and working software arrives at every milestone. Meetings are held when they are useful: a walkthrough of a milestone, a design question that is faster to settle in conversation. None is required.
Send a written briefYou
A few paragraphs describing the process or product, who uses it, the systems it touches, and what a good outcome looks like. The form on the portal asks for exactly this and takes about ten minutes. A document you already have works too.
Discovery and scopingBoth
We read the brief, ask questions by email, and look at a sample of the real data. For a process that has not been automated before, this is a short fixed-fee engagement that produces the architecture and a data assessment. Typically one to two weeks.
Fixed-price proposalDI-DS
A written proposal naming the scope, the milestones, the acceptance criteria for each, the price, and what operating the system will cost afterward. Nothing is charged until you accept it.
AgreementBoth
A standard services agreement signed electronically, with the proposal attached as the statement of work. Data handling, intellectual property and confidentiality are stated in it.
Access and dataYou
Access to the systems the application will integrate with, a sample of real data, and a person who can answer questions about the process. Credentials go through authenticated portal access and are scoped to the work.
Build in milestonesDI-DS
Development proceeds in milestones, typically two weeks apart. Each one delivers working software deployed to a test environment where your team uses it against real data and tells us what is wrong.
AcceptanceYou
Each milestone is accepted against the criteria written in the proposal. Measured results, such as extraction accuracy or detection accuracy on your data, are reported in writing.
DeploymentDI-DS
The application goes to production in your cloud account or ours, with monitoring, logging, backups and a rollback path in place before the first user touches it.
Operate or hand overOptional
DI-DS operates the system under a monthly arrangement covering monitoring, retraining, support and incremental features, or hands it over with documentation, source code and training for your team. You choose.
What we ask of you during a build
- Write the brief. About ten minutes on the portal form, or send a document you already have.
- Answer questions by email. During scoping and at the start of each milestone.
- Provide access and sample data. Usually the longest-lead item, and the one that most affects the schedule.
- Use each milestone. Your team tries the software against real work and tells us what is wrong.
- Accept each milestone in writing. Against the criteria in the proposal.
How an assessment works
Meetings are optional for standard assessments. A complete engagement, from purchase through agreement, authorization, intake, assessment, reporting and remediation plan, runs asynchronously. A form collects what a kickoff meeting collects, and collects it more accurately. A written report delivers what a readout meeting delivers, and it can be forwarded to the people who need it.
Every engagement includes a findings call at no extra cost, available whenever it helps.
Select your assessmentYou
Choose the AI Assurance Audit, or start scoping a Red-Team engagement. Describe the system and we will tell you which one fits, including when the cheaper option covers it.
Execute the agreement and authorizationBoth
Two documents, signed electronically: a standard engagement agreement, and a Security Testing Authorization naming the exact systems, environments, permitted and prohibited methods, testing window and an emergency stop contact. Active testing begins once both are complete.
Complete the secure technical intakeYou
A form that adapts to your answers, so retrieval questions appear for systems that retrieve and agent questions appear for systems that act. Every question offers "I don't know", and that answer tells us something worth knowing.
Provide access and documentationYou
Test accounts at two privilege levels, a staging environment where possible, an architecture description in whatever form already exists, and any prior evaluations. Everything uploads through authenticated portal access.
We assess the systemDI-DS
Automated evaluation across the assessment areas, followed by manual testing that pursues whatever the automated pass surfaces. This is where most of the time goes, and where the character of your system decides what we chase.
Every finding passes expert reviewDI-DS
Automated tooling proposes candidate findings. A person then confirms each one, clears the noise, assigns severity and confidence, and writes the remediation guidance. Everything you read has been through that gate.
Reports delivered to the portalDI-DS
An executive report and a technical findings report, both typeset as PDFs and delivered through authenticated portal access.
Optional findings callOptional
Walk through the technical report with the person who wrote it, at no extra cost. The reports are written to stand alone, so the call is there when it adds something.
Remediation or monitoring, if you want itOptional
Take the remediation plan to your own engineers, have us implement the fixes as a separate fixed-price scope, or move to Continuous Assurance where the system changes often. You choose.
What an assessment asks of you, in total
Across an entire standard assessment, this is the complete list of things that require your time.
- Sign two documents. The agreement and the testing authorization.
- Complete one intake form. Typically 20 to 40 minutes, depending on how much you already have written down.
- Provision test access. Two accounts, ideally in staging. Usually the longest-lead item.
- Answer occasional clarifying questions. Asynchronously, and only where the answer changes what we test.
- Read the reports.
That is the whole obligation. Your engineers stay on their roadmap while the assessment runs.
How your data is handled
Documents and credentials
Documents and credentials are uploaded through authenticated portal access and encrypted in transit and at rest. Customers are asked to keep test credentials short-lived and scoped to the engagement, and DI-DS flags any credential that carries more privilege than the work requires.
Findings and reports
Because a system's architecture and its weaknesses are sensitive, reports remain behind authenticated portal access, and that access is revoked on request. At the end of the testing window DI-DS reminds the customer to revoke the test credentials.
Testing is bounded by written authorization
Active testing runs only against systems and scopes the customer has authorized in writing, within a defined window, using permitted methods. Where findings suggest the scope should be wider, DI-DS returns to the customer for approval.
Start when you are ready
Scope and price are confirmed in writing before anything is charged, for a build and for an assessment alike.