NERVE is live across local, private and approved-cloud deployments. Book an evaluation
Sources and formats
A broad source fabric. A controlled integration boundary.
NERVE acquires approved material from many source families through adapters. Each connector and parser arrives with its own declared scope, version, licensing position and acceptance evidence, so you always know exactly what a route into the fabric covers.
Adapters available now
Source families
The source families NERVE acquires
These groups describe the material NERVE accepts. Each one is a family of adapters with its own declared scope, recorded version and licensing position, so breadth never comes at the cost of knowing what you have.
Source family
Files and archives
Loose files, folder trees and container formats collected from approved storage locations or submitted as bounded packages.
Acquisition style
Acquired by directory walk, scheduled sweep or bounded submission, with container decoding applied before parsing.
Typical canonical output
FileRecord entries carrying file metadata, container path and cryptographic identity, with child records created for decoded members.
Provenance considerations
Container nesting, recursion limits and member-level path context must be recorded so every extracted item can be traced to its enclosing archive.
Source family
Documents and office content
Reports, correspondence, spreadsheets, presentations and scanned material held as document files.
Acquisition style
Acquired as files, then handled by format parsers that read text, structure and embedded objects.
Typical canonical output
DocumentRecord entries with typed text content, structural locators and document-specific extensions; derived OCR or text layers recorded separately.
Provenance considerations
Parser name and version, page and paragraph locators, and the distinction between embedded text and derived OCR output all need to be retained.
Source family
Messages and email
Mailboxes, message exports, chat transcripts and messaging packages supplied through approved routes.
Acquisition style
Acquired from mailbox or export packages rather than by live interception, with per-message extraction from the submitted container.
Typical canonical output
MessageRecord entries holding participants, timestamps, body content and attachment relationships, with attachments becoming linked records.
Provenance considerations
Participant identifiers describe accounts, not confirmed people. Thread reconstruction and attachment linkage must be recorded as observations rather than conclusions.
Source family
Enterprise repositories
Document management systems, collaboration platforms, content libraries and case or record stores.
Acquisition style
Acquired through a connector that reads approved collections over a published interface, using acquisition windows and checkpoints.
Typical canonical output
Typed records that match the retrieved item, with repository identifiers, library or site context and version information held as source-specific extensions.
Provenance considerations
Repository versioning, permission context at the time of acquisition and the scope of the account used must all be recorded against the acquisition.
Source family
Databases and exports
Relational extracts, tabular exports, structured dumps and reporting outputs supplied as bounded datasets.
Acquisition style
Acquired as exported datasets or through a read-only query boundary, never by writing to the source system.
Typical canonical output
GenericRecord entries that retain the original column names and row position, with a typed mapping applied only where a mapping has been agreed.
Provenance considerations
Row and column locators, export query definition, extraction time and any upstream transformation applied by the exporting system all need to travel with the data.
Source family
APIs and feeds
Published interfaces, syndicated feeds, webhook deliveries and scheduled pull endpoints.
Acquisition style
Acquired by polling or subscription against an approved endpoint, with pagination, checkpoints and replay-safe job identity.
Typical canonical output
Typed records derived from the payload schema, with the untouched response retained as the original and the payload shape recorded as an extension.
Provenance considerations
Endpoint, request parameters, response schema version and the acquisition window must be recorded so a later re-read can be compared to the first.
Source family
Streams and sensors
Telemetry, event streams, sensor readings and other continuously produced observations.
Acquisition style
Acquired through a streaming adapter that commits bounded batches, so a continuous feed still produces discrete, addressable acquisitions.
Typical canonical output
Typed observation records, including LocationObservation where a place is reported, each carrying its own event time separate from acquisition time.
Provenance considerations
A location observation records what a source reported, not confirmed presence. Observation method, reporting precision and batch boundaries must be retained.
Source family
Device and forensic packages
Extraction packages, acquisition reports and structured outputs produced by specialist acquisition tooling.
Acquisition style
Acquired as a submitted package. Importing a package produced by another tool is a different job from performing a direct device acquisition.
Typical canonical output
Typed records for the messages, files, media and observations inside the package, each linked back to its position in the submitted package.
Provenance considerations
The producing tool, its version, the package structure and the chain of custody supplied with the package must be recorded alongside the original bytes.
Source family
Historical holdings
Legacy collections, migrated stores, inherited archives and long-retained material with incomplete context.
Acquisition style
Acquired as a bulk submission, handling items that arrive without reliable original metadata rather than rejecting them.
Typical canonical output
Typed records where a parser exists, and preserved originals with minimal canonical context where it does not, so nothing is silently discarded.
Provenance considerations
Missing or uncertain source context must be represented as missing rather than inferred, and any reconstruction has to be recorded as a derived judgement.
Source family
Geospatial and media
Imagery, video, audio, mapping layers and other spatial or time-based media holdings.
Acquisition style
Acquired through dedicated streaming and import paths, because large media should never depend on a browser upload.
Typical canonical output
MediaRecord entries with container and track metadata, with transcripts, thumbnails and extracted text held as separate derived records.
Provenance considerations
Generic file and spatial metadata is treated as core parsing. Specialist interpretation of satellite, radar or multispectral products belongs to an optional domain capability pack.
Four support layers
Support for a source is built from four separate layers
Saying that NERVE “supports” something is imprecise, because support is assembled from distinct parts that can each be present or absent. Separating them tells you precisely what a given route gives you.
Layer 1
Acquisition connector
Reaches an approved source, authenticates with protected credentials, respects the operations it is allowed to perform, and returns the original payload together with its acquisition context.
Layer 2
Container decoder
Opens archives, packages and nested containers under recursion and size limits, so every member becomes an addressable item with its enclosing path recorded.
Layer 3
Format parser
Reads one content type and produces canonical records with locators. The parser name and version are recorded against every output so results can be compared after an upgrade.
Layer 4 (optional)
Domain capability pack
Adds specialist interpretation for a subject area. Packs are approved and installed separately, so the core platform carries no domain assumptions it cannot justify.
Where the line sits
Generic file metadata and generic geospatial metadata are handled by core parsing. Specialist interpretation of satellite, earth observation, radar and multispectral products is delivered as an optional domain capability pack, so the core carries no domain assumptions it cannot justify.
No semantic support still means preservation
If no parser understands an item, the original is still accepted, hashed and preserved with its acquisition context. The item is recorded as unparsed rather than dropped, so a later parser can revisit it.
Core parser set
A focused core format set
The core set covers plain text, structured data, tabular data and document structure without a heavy dependency surface. Domain capability packs extend it, so the baseline stays small, reviewable and fast to accept.
Core format set
TXT
JSON
CSV
DOCX
Dependency posture
Parsing uses maintained, security-reviewed libraries, kept current and replaceable, rather than bespoke readers with no review history.
Packaging posture
Parser packs are versioned, signed and bounded, so an organisation knows exactly which code produced a given derived record and can pin or roll back.
Claim posture
Parsers carry acceptance evidence recorded against them, so a supported format is a statement you can check rather than a label.
The integration boundary
What a connector must establish before it counts
Integrations are held to the same checklist, and each point has an answer on the record before a connector becomes a route into the fabric.
01
Endpoint and account scope
Which system, which tenant and which collections are in scope, together with the exact account used to read them.
02
Authentication and protected credentials
How identity is proven, where secrets are stored, how they are rotated and who can see them.
03
Allowed operations
Read-only by default. Any write, delete or acknowledge action has to be declared and separately authorised.
04
Acquisition windows
The time or change range each run covers, so coverage and gaps can be reasoned about afterwards.
05
Pagination and checkpoints
How a long run resumes after interruption without re-reading or silently skipping material.
06
Replay and idempotency
Re-running a job must not create a second copy of the same acquisition or a second ingest identity.
07
Rate and volume limits
The limits the source imposes and the limits the connector imposes on itself to stay within them.
08
Canonical mapping
Which source fields become which canonical fields, and which are left unmapped on purpose.
09
Source-specific extensions
Fields with no canonical home are carried in a declared extension rather than dropped or forced.
10
Egress rules
Where data is permitted to travel during acquisition, and which network paths are forbidden.
11
Failure handling
What a partial, rejected or quarantined outcome looks like, and what the operator is shown.
12
Licensing position
Whether the organisation is permitted to acquire and retain this material through this route.
13
Acceptance evidence
The recorded tests that establish the connector behaves as declared.
Questions about sources
The questions buyers ask first
Each named system is reached through its own connector, with declared product versions, a licensing position for that route and recorded acceptance evidence. We confirm those four things against your specific estate during an evaluation, so you know exactly what a route covers before you rely on it.
Each connector and parser carries its own recorded acceptance evidence, available on request during an evaluation.
Where to go next
Bring your own sources to the conversation
An evaluation starts from the material you actually hold, not from a feature list. We work through the sources in scope, the licensing position for each route, and the evidence you need before relying on a result.
The governed path
Follow a source through acquisition, preservation, normalisation and publication, stage by stage.
Governance and claim limits
How authorisation, audit and the boundaries of what a record can prove are handled.
Search across the common model
See how material from different source families lines up in one result set.