Ethan McNamara

Engineering · Ownership

Collect

The right file. In the right place.

Concept 47s film 5 stages · 2 paths Illustrative data

01

In plain English

What it is
A document checklist that lets suppliers upload the exact files a project needs.
How it works
You would list the missing documents and send an upload link. Each file is matched to its request, while the team can see what is received, missing, or being replaced.
Why it matters
To make missing documents visible and reduce the sorting and chasing behind file collection.

02

The product film

The missing file has a place to land. A task, a deliberate gesture and its result, inside a reconstructed Signal Studio. It plays on its own while it is on screen; pause it, scrub it, slow it down, or read it as stills.

Scene rendered by preview-collect.js · 47s · 5 beats · 3 stills

03

What it is worth

Less chasing. A clearer picture.

You shouldn’t have to search an email thread to know whether the right document arrived. Give suppliers a simple place to send exactly what you need, and see what still needs attention.

  • Clear for the supplierA short checklist explains exactly what to send.
  • Organised on arrivalEach file lands beside the request it answers.
  • Ready for your reviewSee what has arrived and what is still missing.

04

How it is built

A supplier drops the one missing document into the one empty place in a checklist. The gesture has to connect a specific file to a specific request, because that connection is the entire feature.

ease-in-out cubic
cubic-bezier(0.65, 0, 0.35, 1)
The certificate lifts
1000ms
It settles into the slot
400ms
The receipt appears
2900ms

The empty slot is drawn before the file arrives, at the size the file will be. Nothing resizes on arrival, so there is no layout shift and the placement reads as a fit rather than an insertion.

The receipt is separated from the placement by a beat. The file is stored; the request is marked received; content review is still pending. Three different facts, three different moments.

The easing here is in-out cubic rather than out-cubic: this is an object being moved by a person, not an interface responding to one, and objects accelerate.

05

The working model

Identify the missing document before it arrives. A filename alone cannot tell you which requirement it satisfies.

The boundary that matters Upload access is limited to the request. Format checks do not establish that the document is substantively correct.

Two paths: Standard flow and Replacement storage unavailable · 5 stages each

06

How it fits together

A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.

Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
  accTitle: How Project Collect works
  accDescr: A supplier sees the requested document checklist and uploads to an allowed item. Signal checks the request and file format, then saves the candidate version to customer storage. The checklist marks it received only after storage confirmation. A failed replacement stays pending and does not remove the prior accepted file. This collection architecture is proposed; receipt is not approval of document correctness.
  A(["Supplier<br/>Uploads a requested document"])
  B("Request checks<br/>Permission and file format")
  C("Customer storage<br/>Saves the submitted version")
  D{"File safely<br/>stored?"}
  E("Document checklist<br/>Marks this version received")
  X("Upload pending<br/>Keep any previous version")
  A -->|Requested item only| B
  B -->|Accepted format| C
  C --> D
  D -->|Confirmed| E
  D -->|Storage unavailable| X
  classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
  classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
  classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
  classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
  classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
  class A human;
  class B,C work;
  class D decision;
  class E result;
  class X exception;

07

The case study

File collection should preserve the identity of the request, not just receive a pile of attachments.

The problem

External file requests become email chains or shared folders. A received PDF may still lack the context needed to tell which requirement it satisfies or whether it replaces an earlier version.

The insight

Give each requested document an identity before a file exists, then accept uploads against that specific request.

The system

The proposal combines an expiring upload capability with named document slots. Upload validation, durable request IDs, and explicit replacement history keep each accepted file attached to its purpose. Drive could supply the storage boundary.

The rationale

A small collection flow can make supplier participation easier and reduce the manual work of sorting, renaming, and chasing incomplete documents.

Responsibilities

Document request
Named slots define exactly what is missing.
Upload boundary
Scoped access, validation, and duplicate protection.
File destination
Accepted versions attach to the correct project requirement.

The boundary

Upload permission does not grant folder browsing, access to other submissions, or authority to replace an unrelated project file.

The trade-off

Strict document slots improve completeness but need a clear route for unexpected supporting files. File validation can assess format and safety; it cannot prove that a certificate is substantively correct.

When it fails

The upload is repeated

Deduplicate request retries without assuming two files with the same name contain the same document.

A document is replaced

Create an explicit new version and preserve the previous accepted file until the replacement is confirmed.

Storage becomes unavailable

Keep the request incomplete and explain the retry path. Never label a document received before durable storage confirms it.

Evidence Design proposal · local demonstration uses synthetic data

08

On the design side

Collecting documents is a supplier problem before it is a file problem.

Suppliers

The roster, the search, the work and the close.

20 views