Applied software and automation
Black Swan Photo
Architecture · Active 2026 · Last verified 2026-07-18
Problem
Teams that need to process large image collections must first assemble object storage, upload APIs, queues, workers, scheduling, isolation, result storage, metering, and delivery infrastructure before they can run the algorithm that creates value.
Product
Black Swan Photo is being developed as an API-first photo compute platform combining persistent image storage, scheduled processing jobs, structured results, and metered asset delivery. The underlying storage, execution, and result-management substrate is working; the multi-tenant control plane, public API, metering, and billing layer are the next commercial milestone.
Intended user
Developers, photographers, researchers, and small media teams that need repeatable processing across image collections without building the surrounding storage and execution platform.
Thesis
Computation should move to the customer's persistent collection. A developer should be able to store images once, submit or schedule a job, retrieve reproducible results, and pay for the storage, compute, and delivery consumed.
Request flow
- 01Create collection
- 02Upload or import assets
- 03Submit job
- 04Execute curated algorithm
- 05Store immutable result
- 06Deliver generated assets
- 07Report measured usage
Architecture
The planned architecture separates a control plane — accounts, API keys, collections, job definitions, scheduling, quotas, billing, metering, audit records, webhooks — from a data plane: object storage, ingestion, job queues, sandboxed workers, scratch space, generated assets, and CDN delivery.
The data plane reuses the storage and job-execution substrate already implemented for the personal-archive platform this product grew out of. The control plane, meaning the customer-facing account, API-key, metering, and billing layer, has not been built yet; it is architecture, not implementation.
Every job is planned to produce an immutable execution record: account/organization, collection, input selection, algorithm identifier and version, parameters, submitter, requested schedule, execution environment, start and completion time, resource use, generated assets, structured results, logs, failure information, and billed usage. This is a schema decision made now so reproducibility, billing, and debugging don't have to be retrofitted later.
Evidence
Working substrate
- Provider-neutral archive storage across filesystem, S3, and S3-compatible providersImplemented
- Containerized job execution, validated locallyValidated locally
- Containerized job execution, validated in AWS (S3-backed archive, EC2 workers)Validated in AWS
- Immutable, versioned result catalog (PostgreSQL)Implemented
- Non-destructive review workflow (keep/reject/highlight, multi-level undo)Implemented
SaaS product under development
- Accounts, authentication, and API keysPlanned
- Collections and job APIs (immediate and scheduled)Architecture defined
- Curated algorithm registry, webhooks, usage metering, billing, spending controls, and CDN deliveryPlanned
Commercial model
Black Swan Photo is intended to use transparent, usage-based pricing. Customers will pay for persistent image and derivative storage, compute consumed by processing jobs, and CDN delivery or network transfer. A future platform tier may include baseline usage, scheduling, concurrency, and support. No rates or tiers are set yet.
- Usage reporting
- Job-level cost attribution
- Budget alerts
- Spending limits
- Storage-retention controls
Open assumptions
- Whether curated, versioned algorithms are sufficient for early customers, or whether customer-defined workloads are needed sooner than planned.
- Pricing granularity customers will find legible: separate storage/compute/delivery meters versus a simpler platform tier.
- Isolation and cost-control requirements once workloads are customer-triggered rather than founder-triggered.
Next milestone
Process a real collection through the complete commercial workflow: authenticated upload, durable storage, queued execution, immutable results, resource metering, generated-asset delivery, and a test invoice.
Future direction
The first commercial release will execute curated, versioned algorithms controlled by Black Swan Group. Customer-defined Python workloads may be introduced later through resource-limited, network-restricted sandboxes. Arbitrary code execution raises tenant-isolation, data-exfiltration, and resource-abuse risks that are not solved by Version 1's scope; the public job API is designed so customer-defined workloads can be added later without changing the underlying resource model.
Partnership
Black Swan Group is interested in early design partners, developers or small teams with a real image-processing workload, willing to help validate the API resource model before broader access opens.