Delivery artifact
System and source map
Every system that holds a number, what it is authoritative for, how it connects, and where two systems disagree. Produced in the first week, before anything is built.
Data & AnalyticsWork and delivery
Every engagement ends with something your team owns.
Nigat does not hand over a slide deck and a login. Each engagement produces a defined set of artifacts, each with a named owner, that keep working after we leave. The methods behind them are shown running on public data you can download and check yourself.
What you receive
Six artifacts your team can use without us.
Every phase of the delivery method produces something concrete. These are the deliverables themselves, not a summary of them, and each one belongs to a capability you can read about in full.
Delivery artifact
Reconciliation report
Two systems, one metric, and the exact rows that explain the gap. This is the artifact that settles why the finance number and the operations number never matched.
Data & AnalyticsDelivery artifact
Model card and evaluation
What the model predicts, the data it saw, measured error by segment, the confidence range, where it should not be trusted, and who signs off before it informs a decision.
Forecasting & Machine LearningDelivery artifact
Source-cited review trail
Each extracted fact linked back to its page and rule version, with the reviewer decision preserved beside it. Versioned rules, exception queues with deadlines, and a complete audit history.
Document AI & Workflow AutomationDelivery artifact
Agent boundary and permission map
The job the agent is allowed to do, the tools and sources it may reach, the actions that require a human approval, and the evaluation scenarios it has to pass before it runs on real work.
AI Assistants & Controlled AgentsDelivery artifact
Operating runbook and service levels
What runs, what breaks, who is called, and what to check first, with health monitoring and a named response path. Handed over so the system keeps working without Nigat in the room.
Managed IntelligenceCheck the method yourself
The demonstrations run on public data, not on claims.
2 of the 3 industry demonstrations run on named public datasets. Download the same file from the same source and you can hold the result to account. Nothing here asks you to accept a number on faith.
Open-data demonstration
Service Demand & Crew Intelligence
NYC 311 Service Requests from 2020 to Present. Public snapshot used as a proxy for dispatch-intensive field work.
Synthetic-data demonstration
FHIR Evidence Readiness Intelligence
Validation rules read from the published HL7 FHIR R4 StructureDefinitions. Episodes are synthetic and generated per run, because patient records cannot be used. No PHI.
Open-data model demonstration
Predictive Maintenance & RUL Intelligence
NASA C-MAPSS FD001 simulated turbofan run-to-failure data.
The healthcare demonstration reads its validation rules from the published HL7 FHIR R4 specification, but generates synthetic episodes for every run, because real ones would contain protected health information. The RCD PacketOps demonstration is synthetic for the same reason. Where data is synthetic, it says so on the demonstration itself.
The evidence standard
Every number here names its source.
Each demonstration states the dataset it runs on and links to the place you can download it. Each artifact shown is the deliverable itself rather than a description of one. Where a figure is modelled, the inputs and the model are visible on the page that produces it.
Customer work is published only with written permission, carrying the date and the method used to measure it. That standard is what makes the evidence here checkable rather than merely quotable.
Available on request
- The system-map template and the questions it answers
- A sample model card structure for your decision type
- The synthetic RCD PacketOps packet and its rule versions
- The runbook and service-level template handed over at project close
Ask for any of these in the first conversation. They are the same templates used in delivery.
Start with the operating problem
Show us where the work slows down.
You do not need a polished technical brief. Describe the decision, handoff, report, document workflow, or AI initiative that is harder than it should be.