At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| File name and MIME type | Match the exact allow-listed pair | Supported or rejected type | Renaming a file does not bypass MIME checks |
| Tenant and account context | Derive the session owner marker | Owned upload session | Other users cannot resume the session |
| Staged chunk | Check position, length, and SHA-256 | Stored receipt or failure | Conflicting bytes at one position are rejected |
| Complete file | Reassemble in order and hash again | Ingestion or integrity failure | Every expected chunk must exist |
| Parser output | Apply extraction and operation budgets | Bounded evidence record | Semantic checks depend on the file type |
How it works
- Open Upload controlled evidence.
- Choose the supported file and retention settings.
- Select Upload evidence.
- Let staged upload verify each chunk when required.
- Wait for whole-file verification and parsing.
- Review the returned evidence state and identifiers.
Example
A staged upload receives the correct first chunks, but one later chunk has a different hash. The server rejects that chunk. Finalization also fails when any chunk is missing or the assembled file hash differs from the declared value. No evidence record is promoted from an incomplete file.
What this does not mean
Integrity checks confirm the received bytes and bounded parser result. They do not approve the file, prove its business meaning, certify legal validity, or establish that the source was correct.
Related questions
Next step
Keep the upload open until final file verification completes.
View on Atlassian Marketplace