How we work with you
Most of this starts with a folder nobody has had time to open. Here is what happens from there.
What we need from you
Your data in whatever state it is actually in. Not tidied up first. We would rather see the file names that changed halfway through the season and the three weeks where a recorder's battery went flat, because that is what we will be working with anyway.
One person who can answer questions about how it was collected and what the strange bits mean. A few hours of their time across the first weeks, not a full-time secondment.
A question worth answering. "Which of our sites still have rockjumpers calling, and has that changed since the fire" is something we can work with. "Do something with AI" is not.
How it runs
- A conversation and a look at your data. No cost. It sometimes ends with us telling you that you do not need us, or that the open tools will do it as they stand.
- A small scoped piece with a defined output. You find out how we work, and we find out what the data is really like, before either of us commits to anything large.
- The build. Run in the open, with your team able to watch it happen rather than waiting for a delivery date.
- Handover. It running on your side, your people able to operate it, and documentation written for somebody who was not in the room.
What you pay for
Engineering time. There is no licence fee, no charge per recorder, and no annual renewal that climbs once you depend on it.
Whatever is already in the library, you get. Your money goes to the part that does not exist yet, built around your recorders, your species list and the noise you actually have, and you have it working first.
What gets built for you joins the library afterwards, which is why the parts you are getting for nothing were paid for by somebody before you.
Who runs it afterwards
By default, you do. We set your team up to host and operate it yourselves, with the code open and the data in your hands. If Ceder disappears, nothing switches off.
Some teams have nobody to run it, and we would rather help than let that be the reason it does not happen. Then we operate it for you, on cloud infrastructure in your organisation's name. You own the account and the data. We hold the access we need to keep it running, and you can take the keys back or move the whole thing elsewhere whenever you want.
Either way the data is yours, it is not pooled with anyone else's, it is not used to train anything unless you ask us to, and the exit path is written into the agreement rather than promised in a conversation.
What happens when we stop
It carries on being maintained, because the code is open and other organisations are running the same thing. A contractor cannot offer you that. When they move on, their system stops where they left it.
If you want changes later, you can call us, or you can call somebody else, or your own people can make them. Nothing about the code requires us.
How Ceder stays alive
Paid engineering is what funds this, deliberately rather than by default. Grants can bridge an early stage and may well bridge ours, but grant funding ties the work to funding cycles rather than to the organisations using it, and this field is full of systems that stopped being maintained the month the money ran out.
The licence
Everything we build is released under the Apache License 2.0, code and model weights alike. In plain terms: when we are finished, you carry on running it. You can change it, give it to someone else, or hand the whole thing to another contractor, and you never owe us anything for continuing to use it.
We also do not ask anyone to sign their copyright over to us. That is deliberate, and it is the part that actually guarantees the rest. It means no single party, Ceder included, is ever in a position to take this work closed.