Official implementation partners
OpenFactory is Apache-2.0 software that anyone may run, modify and sell. An OpenFactory Implementation Partner is a company that has shown, with evidence gathered from a live deployment, that it implements the platform according to the guidelines on this page. The name and marks are reserved for partners on this list.
Program version 1. The list is limited to five partners in the first year. The same requirements apply to every company, including companies affiliated with the maintainers.
Current partners
Partners admitted at the program's start were accepted on the basis of live deployments already in operation and submit their evidence packs within 90 days. "Evidence verified" shows the date of the last accepted pack.
| Partner | Country | Languages | Status | Evidence verified |
|---|---|---|---|---|
| Altiva.ai | Brazil | Portuguese, English | Partner | Pending |
| Castello Soft | Brazil | Portuguese, English | Partner | Pending |
Enquiries from prospective customers sent to partners@openfactory.digital are forwarded to listed partners in rotation by country and language.
What a partner must show
Admission is based on demonstrated work rather than an exam. There are no tiers and no fee in the first year.
1. One named practitioner
An engineer who has run OpenFactory on their own repository and on a real forge organisation, and who has completed the practitioner drill: a seeded deployment with known faults that the practitioner must diagnose and fix. The drill produces a practitioner pack.
2. One live customer deployment
A deployment in operation for a customer, with a deployment pack that passes the thresholds below. The customer confirms the deployment by email. The pack is anonymised; the customer is not named publicly.
3. Signed partner agreement
Follow the guidelines on this page. Report defects upstream. Do not maintain a divergent fork under the OpenFactory name. Limit claims about the platform to what the documentation and status page state. Handle customer data under a data processing agreement. Remove the marks within 30 days if delisted.
4. Contribution instead of a fee
One published case study per year, defects filed upstream with journal excerpts, and one documentation or code pull request per quarter.
Deployment pack thresholds
| Check | Threshold |
|---|---|
| Controls for the claimed profile | Every required control passes (see the guidelines) |
| Activity in the 90-day window | At least 20 jobs, at least half merged |
Parked as unknown | Below 10% of jobs |
| Cards in Needs Action | None older than 7 days at pack time |
| Box proofs | Current for every repository |
| Platform version | The current release or the one before it |
| Security controls | Panel not open; secrets file mode 0600; forge credential without workflows; box.env is an explicit allow list |
Evidence-based certification
The process is asynchronous. Evidence is gathered by a command that runs on the deployment, redacts identifying data, and writes a signed pack. Submissions are pull requests validated by automation. A maintainer merges a new partner's first submission after checking that the company exists and the agreement is signed. Later submissions from a listed partner merge automatically when validation passes.
Run the practitioner drill
On the practitioner's own deployment. The drill seeds a project with known faults, the practitioner fixes them, and the command records what passed.
openfactory certify practitioner --out practitioner.tgz
Gather the deployment pack
On the customer's deployment, run by the customer's operator or by the partner with the
customer's recorded consent. The command runs the platform's own diagnostics
(preflight, doctor, env check,
box status, conformance), reads configuration controls and
90 days of aggregate outcomes, redacts, and signs. --dry-run prints
everything the pack will contain before anything is written.
openfactory certify deployment --partner <slug> --profile standard --dry-run openfactory certify deployment --partner <slug> --profile standard --consent "name, role, date" --yes --out deployment.tgz
Verify locally, then submit
openfactory certify verify runs the same checks as the submission
automation, so the result is known before submitting. Submit by pull request to the
partners repository, under partners/<slug>/: the partner record, the
signed agreement, the practitioner pack, the deployment pack. The customer sends the
confirmation email to partners@openfactory.digital.
Listing and renewal
On merge the partner appears on this page with the verification date. A listing lapses if no valid deployment pack is accepted within six months. Partners may schedule the command from the worker so renewal needs no manual step.
What a pack contains
- Pass or fail per control, for the claimed profile.
- Aggregate outcomes: jobs run, merged, parked by class, medians for cost and time to pull request, oldest Needs Action age.
- Platform version, provider kinds, proof status per repository.
- A redaction log and the partner's signature.
What a pack never contains
- Source code, ticket text, pull request bodies or commit messages.
- Organisation, repository, project or person names. These are replaced by pseudonyms derived from a per-pack random salt.
- URLs, hostnames, email addresses or any credential.
The certify command is specified in
openfactory-core issue #356
and is being built.
Until it ships, a pack is assembled by hand from the same diagnostic commands, following
the pack specification in that issue. The command's source is public, so a customer can
read what it collects before running it.
Implementation guidelines
Partners follow these on every implementation described as an OpenFactory implementation. The deployment pack checks the ones that can be read from the deployment.
| Area | Requirement | Checked by the pack |
|---|---|---|
| Qualification | Do not start without a test command that runs on a clean clone, a route from the deployment to the model provider, a supported forge, and reviewers who will read the pull requests. | No |
| Scope | Start with one project under merge_policy: human and a pilot of 10 to 20 tickets with a spend cap. No auto merge in the first 30 days. Declare risk: high on authentication, billing, migrations and infrastructure. | Merge policy, risk declarations |
| Disclosure | Before the design is agreed, give the customer in writing what the platform does not do, as published in the status page. | No |
| Credentials | A forge App or token with the documented permissions only and never workflows. Secrets in .env.compose at mode 0600, started with --env-file. Panel never open on a reachable host. box.env as an explicit allow list. No partner credentials on the customer's deployment. | Yes |
| Quality floor | Every repository declares validate.test; the security gate is declared or inherited; noisy gates are advisory, never removed. | Yes |
| Forge settings | Branch protection on the default branch: pull request required, linear history, force push disabled, auto-merge enabled. Required checks run on every pull request. | Yes |
| Proof before spend | Every repository's box is proven and a rehearsal is run before the first real ticket. | Proof status |
| Ownership | The customer reviews and merges every proposal. The partner never merges into a customer repository. | No |
| Hand-over | The customer receives a runbook and can operate the deployment without the partner: diagnostics, parked cards, upgrades, backup and restore. | No |
| Operation | Parked cards are answered within the support terms agreed with the customer. Cost is reviewed against a budget. | Needs Action age |
| Currency | The deployment runs the current release or the previous one. Security fixes are applied within 10 business days. | Version |
| Upstream | Defects are reported with journal excerpts and the version. Fixes are proposed upstream before being shipped to a second customer. No divergent fork under the name. | No |
| Claims | Public material about the platform links to the documentation and status page rather than restating them. Nothing is described as available that the status page lists as not built. | No |
Verification after listing
- A deployment pack every six months, or the listing lapses.
- One pack per partner per year is read in full by a maintainer.
- Customer complaints to partners@openfactory.digital are investigated within 30 days.
Revocation
- Misrepresenting what the platform does: immediate delisting.
- A pack that fails thresholds, or a substantiated complaint: probation and a maintainer reviewing the next engagement; delisting on a second finding.
- Delistings are recorded on this page for one year.
Becoming a partner
- Email partners@openfactory.digital with the company name, website, countries and languages served, the practitioner's name, and a one-paragraph description of the live deployment.
- Receive the partner slug, the agreement text and the partners repository link.
- Run the practitioner drill and gather the deployment pack as described above.
- Open the pull request. Ask the customer to send the confirmation email.
- Listing follows the merge.
What is not part of this program yet: individual certifications, partner tiers, a conformance mark for builds and hosted services. These are planned for when the partner list grows and will be announced here.