Oryn | Devpost

Inspiration

Most software releases never become watchable media. Release notes are useful, but turning them into a script, artwork, narration, music, and a polished video takes enough time and specialist work that only major launches receive that treatment.

AI can make this process faster, but it introduces a second problem: trust. Developer-relations, marketing, and legal teams need to know whether every claim came from the release notes, which provider produced each asset, whether a human approved it, and whether anything changed afterward.

Oryn was inspired by the idea that release media should be as traceable as the code it describes. A normal GitHub release should be able to produce a concise media package without giving up review, provenance, or accountability.

What it does

Oryn turns a published GitHub release into a reviewable release-media package:

The Edge service verifies the GitHub webhook signature, deduplicates the delivery, resolves the tag to an exact commit SHA, and captures a normalized release snapshot.
The Workflow service creates one idempotent run and coordinates script, image, narration, score, assembly, provenance, approval, and publication states.
The Generation service converts the release snapshot into a structured storyboard, hero image, voice-over, and optional score. Storyboard claims are validated against hashed source spans before the run can continue.
FFmpeg deterministically assembles the generated assets into a 1280×720 H.264/AAC video with pan-and-zoom motion, narration, score ducking, web fast-start, and media validation through ffprobe.
The dashboard lets an allowlisted reviewer inspect the run, preview artifacts, see provider attempts, approve or reject the result, retry failed stages, and request verification.
After approval, Oryn canonicalizes the provenance record with RFC 8785, binds the approval to its SHA-256 digest, signs it with Ed25519, and prepares the media and manifest for immutable publication.

Nothing is intended to publish automatically. Human approval is a hard boundary between generated drafts and the final release package.

How we built it

Oryn is a Dockerized monorepo with six focused Python services and a Next.js dashboard:

Edge: FastAPI ingress, GitHub release webhooks, GitHub OAuth, project and run APIs, and short-lived artifact access. Workflow: the authoritative run state machine, cost/deadline policy, retries, approvals, and fan-out/fan-in orchestration. Generation: versioned provider policies, normalized provider adapters, bounded retries and fallbacks, grounded storyboard validation, and modality-specific workers. Assembly: deterministic FFmpeg command construction, isolated temporary workspaces, SHA-256 input checks, and ffprobe validation. Provenance: candidate-manifest construction, RFC 8785 canonicalization, approval binding, Ed25519 signing, and tamper verification. Delivery: publication ordering, retention checks, B2 event-signature verification, deduplication, and notification adapters. Dashboard: Next.js, React, TypeScript, TanStack Query, and a generated API client for the review workflow.

The services communicate through versioned JSON contracts over RabbitMQ. PostgreSQL stores service-owned state, while transactional inbox/outbox patterns make repeated messages safe. Storage is behind an adapter so local development uses the filesystem and production can use Backblaze B2 through its S3-compatible API.

Challenges we faced

The hardest challenge was making a long, failure-prone media workflow safe to retry. Webhooks can be delivered more than once, message consumers can restart, providers can time out after accepting a paid job, and an assembly process can fail after writing only part of an output. We addressed this with stable idempotency keys, inbox/outbox records, explicit run states, bounded retry policies, content hashes, and a publication marker written only after the full package is verified.

Another challenge was preventing polished AI output from outrunning its source. Oryn keeps a normalized release snapshot and requires storyboard claims to reference hashed source spans. The approval is then bound to the exact canonical candidate-manifest hash, so changing an asset or claim after review invalidates finalization.

Media generation also creates practical cost and reliability constraints. Instead of making expensive text-to-video calls a requirement, the MVP uses a deterministic FFmpeg pan-and-zoom path and keeps true video generation as an optional extension. A versioned provider policy separates provider choice from workflow code and records each attempt for later diagnosis.

Finally, coordinating multiple independently developed services required frozen event schemas and strict ownership boundaries. Shared Pydantic contracts, service-specific database schemas, and contract tests kept the pieces compatible.

What we learned

We learned that provenance has to be part of the workflow from the beginning. Adding a hash at the end is not enough: trustworthy media needs source capture, claim grounding, provider evidence, deterministic artifact references, human approval, canonicalization, signing, and verification to agree on the same bytes.

We also learned that reliable AI orchestration is mostly systems engineering. Fallbacks are useful only when failure classes, deadlines, budgets, idempotency, and duplicate billing are handled explicitly. The same principle applies to storage: an upload is not complete until its size and digest have been read back and checked.

The deterministic local provider and filesystem backend were especially useful. They let us test the workflow, media assembly, and trust boundaries without spending provider credits or depending on network availability.

B2 and GenBlaze usage

Accurate answer for the current repository

Backblaze B2: Oryn includes an S3-compatible B2 draft-storage adapter used by the generation and assembly boundaries. Run-scoped keys hold storyboards, images, narration, score, generated evidence manifests, and the assembled MP4. Each upload stores SHA-256 metadata, reads the object back with HEAD, reuses an existing object only when its digest matches, and rejects conflicting content under the same key. The delivery boundary verifies signed B2 event notifications and deduplicates event IDs. Publication logic verifies every draft hash, enforces retention metadata, and writes a completion marker last. The default local Compose environment deliberately uses filesystem storage, and the concrete production B2 Object Lock publisher still needs to be wired and live-tested.

GenBlaze: Oryn has a versioned, modality-specific provider-policy layer, normalized adapter boundary, bounded retry/fallback behavior, deadline and budget checks, provider-attempt tracking, and a private evidence-manifest path for each generation step. However, the checked-in GenBlaze adapter is still a stub and the default build runs deterministic fake providers. A submission must not claim live GenBlaze usage until the SDK is integrated, exact model IDs are pinned, provider responses are normalized into the existing boundary, and an end-to-end live run succeeds.