What it proves
A starter pattern gets more reusable when the first run leaves one stable artifact behind instead of forcing every downstream component to reinterpret the same input.
OCI Functions starter patterns
oci-fn-file-manifest-writer is the clearest example of a starter repo leaving behind one compact handoff artifact instead of repeating raw event parsing downstream.
This guide exists because many event-driven examples stop at the trigger. The repo pushes one step further: turn a messy inbound batch into a manifest a later worker can actually consume.
Why this repo carries the track
A short site-side guide before the proof layer on GitHub.
Why it matters in this track
It extends the OCI Functions starter pattern from routing and validation into batch handoff design. The point is not only to receive an event, but to leave a compact contract artifact for the next step.
What survives the first run
The manifest is the artifact. It captures totals, file groups, and extension summary in a stable JSON shape a downstream job can reuse.
What the first useful success looks like
oci-fn-file-manifest-writer as a first useful success, not only a demo.
The first useful run is a manifest that another system could read immediately. That makes the starter repo feel like a real boundary pattern instead of only a trigger demo.
Use this when an event-driven workflow should condense a file batch into one compact handoff for a queue worker, reconciliation job, or downstream ingest step.
python3 - <<'PY'
import json
from func import build_manifest
payload = json.load(open('sample-event.json'))
print(json.dumps(build_manifest(payload), indent=2))
PY{
"generated_at": "2026-05-05T16:03:11.575412+00:00",
"file_count": 5,
"groups": {
"claims": 2,
"finance": 2,
"images": 1
},
"extensions": {
"csv": 2,
"json": 2,
"png": 1
}
}Where it routes next
Builds a compact manifest from inbound file batches so downstream jobs can consume one stable handoff artifact.