Storage

Sync to the storage you already trust

Engineering firms have already chosen where their documents live. A new sealing tool that demands a new file silo creates duplicate workflows, version drift, and an 'outside the system' set of records compliance has to chase. We do not become your file system. We integrate with the file system you already have.

Executive summary

Five cloud storage providers integrated today: AWS S3, Azure Blob, Google Drive, Microsoft SharePoint, and Box. On every successful seal, the immutable PDF is enqueued for upload to your configured destination via Oban.

Sync is post-commit, retried, and trackable: we never claim a sync succeeded before the destination acknowledged. Failed uploads retry with exponential backoff and are visible to admins in the storage settings dashboard. The seal is sealed; the upload is observable.

Our commitments

Five rules for the storage integration

01

Sync after the seal commits, not before

Storage upload is enqueued only after the database transaction succeeds. A failed seal never produces an orphan file in your bucket.

02

Provider credentials are encrypted at rest

OAuth tokens, S3 access keys, SFTP passwords — all field-level AES-256-GCM with redact: true. A database read alone does not yield usable credentials.

03

Sync status is observable, not assumed

Per-document sync state (pending → syncing → synced → failed) is a database column you can query and alert on. We do not pretend something is uploaded if it is not.

04

The original is yours, not ours

The sealed PDF in your storage is yours to keep, move, archive, or audit. We do not require it to live in our infrastructure to remain verifiable — verification works from the bytes regardless of where they sit.

05

No silent provider fallbacks

If your S3 sync fails, we do not silently switch to a "default" location. Failed uploads stay failed and surface to your admins; you choose the recovery path.

Implementation — providers

Five integrations, one architecture

AWS S3
Azure Blob
Google Drive
SharePoint
Box

Implementation — the sync pipeline

How upload actually happens

Trigger Post-commit hook on seal Enqueued only after the seal transaction commits
Worker queue Oban :storage_sync Per-org concurrency limits; protects under heavy load
State machine pending → syncing → synced / failed Per-document column; queryable and alertable
Retry Exponential backoff 5 attempts before final dead-letter classification
Credential storage AES-256-GCM at rest Field-level encryption with redact: true
OAuth refresh Automatic Expired access tokens refreshed transparently before each upload
Path validation Containment-checked Configured destination paths verified to be within the customer's bucket / drive
Test connection Self-service Admin UI verifies credentials work before enabling sync

The full picture

What is built, what is being built, and what we chose not to build

Live today

Five cloud provider integrations

Live

S3, Azure, Google Drive, SharePoint, Box.

Post-commit upload via Oban

Live

Sync starts only after the seal transaction commits; no orphan files from rolled-back seals.

Encrypted credential storage

Live

OAuth tokens, S3 keys, SFTP passwords all field-level encrypted with redact: true.

Per-document sync status tracking

Live

States are queryable; admin UI surfaces failed uploads for manual retry or investigation.

Self-service test connection

Live

Admins verify credentials work before enabling sync; failures surface in the configuration UI, not at sealing time.

Building now

Per-folder sync rules

Building now

Map document folders to destination paths so different project areas land in different buckets / drives.

Bidirectional metadata sync

Building now

When a document moves in your storage, the EngineeringID record stays linked. Today, sync is one-way (EngineeringID → storage).

Two-step sync verification

Building now

Post-upload HEAD check confirms the destination object exists with the expected size and ETag before we mark sync complete.

Roadmap

Customer-managed encryption keys

Roadmap

BYO AWS KMS for at-rest encryption of stored credentials and signing material. Plaintext key material would never leave your KMS.

Glacier / cold-storage tiering rules

Roadmap

Per-org rules for moving very old sealed versions to cold storage while keeping verification live.

On-prem / air-gapped sync

Roadmap

For customers with a strict no-cloud posture, an SFTP-pulled sync where EngineeringID never initiates outbound to the destination.

Considered & rejected

Building our own "EngineeringID storage" as the default

Considered & rejected

A new file silo is the opposite of what enterprise customers want.

Why we rejected it: customers have already invested in S3 / SharePoint / Box. A new silo creates the exact integration friction we exist to remove. We default to "your storage, your control" with a transparent per-document sync state.

Aggressive sync retries that hammer your provider

Considered & rejected

Retrying every 30 seconds for an hour is an availability incident on the receiving end.

Why we rejected it: 5 attempts with exponential backoff respects the destination's rate limits. After the final attempt, we dead-letter and surface the failure to admins. We do not become a noisy neighbor.

Storing customer cloud credentials in plaintext for "operational ease"

Considered & rejected

A leaked credentials database is the canonical SaaS breach pattern.

Why we rejected it: every "we need plaintext for token refresh" is solvable with field-level encryption — decrypt inside the OAuth refresh path, drop, done. We pay the symmetric op; we never store plaintext.

Silent failover to a backup destination

Considered & rejected

"We synced your sealed document to a different bucket because the configured one failed" is not a feature.

Why we rejected it: failed sync stays failed and surfaces to admins. Silent failover to a different location creates a permanent question of "where did this document actually go?" that compliance cannot answer.

Compliance mappings

Controls this surface satisfies

SOC 2 CC6.7

Data Transmission and Disposal

TLS 1.3 in transit; AES-256-GCM credentials at rest

SOC 2 A1.2

Availability — Recovery

Failed syncs retry with backoff; final state observable to admins

ISO 27001 A.13.2.1

Information transfer policies

Defined provider integrations; no ad-hoc transfer paths

ISO 27001 A.13.2.4

Confidentiality agreements

Provider credentials handled per the corresponding provider's DPA

GDPR Art. 28

Processor obligations

Customer storage providers act as sub-processors under the customer's DPA

HIPAA §164.314(b)

Business Associate contracts

BAA-eligible providers (S3, Azure, Google Workspace) supported under your existing BAA

For compliance teams

Questions you do not need to call to ask

What happens if my storage provider is down at sealing time?
The seal commits to our database first. Storage upload is enqueued post-commit and retries with exponential backoff. A storage outage delays sync but does not block sealing.
Where do customer cloud credentials live?
Encrypted at rest with field-level AES-256-GCM. The schema field is marked redact: true so the credential never reaches Inspect, Logger, or telemetry. Decryption happens only inside the OAuth refresh / authentication path.
Do you store a copy in your own infrastructure?
The original is uploaded to your configured destination. We retain a reference to the sealed version (hash, signature, verification code) and the binary in our object storage for the verification API to function. Customer-managed deletion can purge the binary while keeping the verification metadata, by org policy.
What happens to a file in your storage when we revoke the connector?
Existing files in your storage are unaffected — they are yours. Future seals stop syncing to the disconnected provider until you reconfigure or attach a different one. The sync_state for the document is set to 'unconfigured' rather than failed.
Can we use customer-managed keys for the at-rest encryption?
Customer-managed keys (BYO AWS KMS) for at-rest field-level encryption of credentials and signing material are on the roadmap. Today, field-level AES-256-GCM keys are held in our hosted secret store.
Are sync events captured in the audit log?
Yes — sync_started, sync_succeeded, sync_failed are first-class audit events, hash-chained alongside the rest. Your auditor can verify what was uploaded, when, and to where.

Storage that respects the storage you already chose

Sealed documents land where they belong, observably, retried, and on your terms.

Get Started See sealing