Capture every record, wherever it lives.
M365, ServiceNow, FOIA.gov, file shares, paper: pre-built connectors, the Records API, and an ETL lane bring records into RMA iQ with NARA metadata and AI classification on the way in.
Breadth, depth, and a documented seam.
The three things federal records teams keep asking for, and the shape of the whole capture layer.
Meet records where they live.
Pre-built connectors cover the federal stack agencies actually run on: M365, SharePoint, Google Workspace, Outlook, Box, file shares, databases, ServiceNow, email, SMS, Teams, paper, plus the citizen-facing four: FOIA.gov, Pay.gov, Login.gov, ID.me. The library keeps growing, and each one respects the source system's permissions, audit trail, and rate limits.
See the connector gridBring them in with structure.
Every record that arrives lands in RMA iQ with NARA-mandated metadata already populated: identifier, title, description, creator, date. Fields that don't map cleanly are preserved as custom metadata, and AI classification, redaction, and routing can run at the moment of capture, before the record reaches a records officer's queue.
How the capture layer worksWire up the rest yourself.
The Records API is documented, versioned, and stable. Anything the connectors don't cover, your integration team or Feith Services can wire up without a vendor engagement. AD/LDAP sync ships with the platform, and every capture event emits a webhook downstream workflows can subscribe to.
The Records API approachThe connectors agencies reach for most.
These are the source systems federal teams run on most, each with a production-grade connector maintained by Feith and aware of the source's permissions model. The set keeps growing, and anything outside it is handled by the Records API or the ETL lane.
Capture modes
API-first throughout: any system with a documented API can be wired into the capture layer, and AD/LDAP sync ships with the platform.
Three lanes. One layer.
Most agencies use all three. Which lane handles a given source depends on what the source can offer and what the records team needs out the back.
Records API
The most direct lane. Source systems push records to Feith through documented REST endpoints. It's the workhorse for bespoke line-of-business systems, custom intake portals, and anything the connector grid doesn't cover. The API validates NARA fields at submission, so malformed records are rejected before they reach the archive.
Pre-built connectors
A growing library of federal and enterprise connectors, each a production-grade integration maintained by Feith. Connectors handle authentication, rate limiting, deduplication, and source-system pagination so the records team doesn't have to.
ETL
The migration lane, for what the API and connectors can't reach. Legacy file shares with thirty years of folder structure, database tables from sunset systems, scanned paper, backup tapes. This is where federal records migrations actually happen.
Four operations that run across all three lanes.
Classification
Records are classified against the agency's records schedule (housed in RMA iQ) at the point of capture. The model reads the content and proposes a category; records officers review proposals in batches.
Metadata extraction
Unstructured content (paper, scanned PDFs, free-text email bodies) is read by the extraction model, and NARA-mandated fields are populated from the content itself.
Redaction on intake
Records flagged as CUI or PII can be redacted at capture, before they're ever indexed for search. Proposals carry exemption codes and plain-language justifications, the same surface FOIA Workbench uses downstream.
Routing
Records can be routed to specific cases, queues, or workflows by content. A record from M365 can be matched to an open FOIA case and added to its evidence set automatically, the integration point with Workflow & Automation.
What guards the layer itself.
The capture layer sits in the path of every record entering RMA iQ. It inherits RMA iQ's ATO posture and adds source-specific protections at each connector.
Credentials to source systems
Managed identity, service principal, or OAuth refresh tokens, stored in the platform's secrets vault. No long-lived plaintext credentials on disk.
In transit
TLS 1.3 between every source and the capture layer. Mutual TLS for source systems that support it.
At rest in the capture buffer
AES-256. Buffer retention is short by default; records move to RMA iQ on a sub-minute SLA in most deployments.
Source-system permissions
Connectors operate under the source's RBAC and see only what the integrated identity is authorized to see at the source.
CUI during AI on intake
The AI operations run inside the platform's trust boundary. CUI-flagged records can be configured to skip the AI lane entirely where agency policy requires human-only handling.
ATO inheritance
The capture layer is in scope for the same ATO as RMA iQ. FedRAMP High, IL5, and IL6 deployment modes all include it.
Audit trail
Every capture event is logged (source, timestamp, identity, payload hash, classification outcome, redaction proposals, destination ID) and queryable from the same audit surface as RMA iQ.
Air-gapped deployment
The capture layer runs air-gapped. ETL and on-premises connectors need no external network reach, and the Records API can operate on an internal-only network.
The full posture is documented in the platform's System Security Plan, maintained for each ATO and available under NDA to agencies in active procurement.
A migration story from a cabinet-level agency.
A composite of two recent federal migration engagements. Names are anonymized and volumes are illustrative within an order of magnitude, but the shape of the work, the lane usage, and the hard moment in the middle are accurate.
A cabinet-level agency with roughly 30,000 users needed to retire two legacy document management systems and consolidate fifteen years of records into a single NARA-compliant archive. Four parallel intake streams were running on the legacy systems and could not be paused.
Two weeks into the historical ETL, a records officer running a sample audit flagged a date discrepancy. One legacy system had stored creation timestamps in local time with no timezone metadata. Records that looked created in 1998 might actually be from 2003, depending on which regional office had ingested them, and the records schedule depends on the actual creation date for retention math.
The first three weeks of migrated records had to be re-ingested. Feith Services worked with the agency's data team to write a timezone-normalization step that ran against every record as it moved through the ETL lane, using regional office identifiers to anchor each timestamp. The fix added two weeks to the engagement, and zero records were lost.
- Zero downtime to the four parallel intake streams during the migration.
- All historical records ingested with NARA metadata populated, classified against the agency's schedule, and indexed for FOIA search.
- Two legacy DM systems decommissioned within the engagement window.
- The timezone-normalization step is now a reusable component in the ETL lane for any source with the same defect.
What separates this from a horizontal capture layer.
Three structural choices set the Feith Capture Layer apart from horizontal capture vendors and the capture modules bolted onto general-purpose DM systems. Each showed up in the migration above.
The capture layer and the archive are built by one company.
Most capture vendors ship records to whatever archive the agency owns; the integration is a separate engagement, often with a separate vendor, and the round-trip semantics get negotiated. The Feith Capture Layer was built against RMA iQ, so the round-trip is engineered end-to-end by one team. Records written through capture are readable through the same identity, with the same metadata, under the same retention policy, on the same audit trail.
Records are captured in place.
The capture layer goes to the source. It doesn't require source systems to migrate to a vendor cloud. Air-gapped sources stay air-gapped; on-premises sources stay on-premises; the connector model operates under the source's RBAC. Agencies don't give up architectural control of their systems to use Feith for records management.
AI on intake is a native operation.
The four AI operations run as part of the capture pipeline itself. The same model layer that classifies records on capture powers Record Insight downstream, so classification at capture and at search return the same answer for the same record, under the same governance, audit trail, and policy enforcement as the rest of the platform.
The same layer, for regulated industries.
The capture layer is in production across federal agencies, but the engine is industry-neutral. Regulated enterprises (life sciences, energy, financial services, higher education) use the same three lanes with a different connector mix.
SAP 
Oracle 
Salesforce 
SQL Server PeopleSoft DocuSign Documentum Alfresco ADP Enterprise connectors ship on the same release cadence as the federal grid. The Records API and ETL lane are identical across federal and enterprise, and single-tenant architecture is standard for both.
See the Capture Layer on your stack.
Tell us what systems you need to capture from. We'll show you the connector list, the API surface, and a worked example for your environment.
Contract vehicles
GSA Schedule 70 · SEWP V · CIO-SP3 · 8(a) STARS III · State contract vehicles available
Request received.
A Feith integrations engineer will reach out within one business day with the connector list, API documentation links, and a worked example tailored to the source systems you listed.
Where next
The capture layer is the entry point. Five places to go from here.