Enterprises are writing down their standards and mapping their systems so AI agents can work inside them. Publish your product as a product pack, the patterns for integrating with it as a Steering pack, or deliver the implementation. Your work reaches the IDE and the PR gate of every org that adopts it.
| Secure API design · Steering pack | v3.1 · 142 orgs |
| Northwind Identity · Product pack | v2026.09 · 97 orgs |
| Most-cited Lens · NS-AUTH-02 | 38% of findings |
Illustrative mock. Partner name and figures are fictional sample data. The partner program is forming: terms, tiers and the builder kit are proposed, not final, and no partners are listed yet.
Before they let agents do more, engineering organisations are putting their rules and their systems in one place. That creates demand that rkito alone will not fill, and shouldn't.
Teams want security, compliance, cloud and domain standards already turned into policies and yes-or-no Lenses.
Your role: publish the standard you are known for as a Steering pack.
Every enterprise architecture includes vendor products. Agents need to know those products' APIs, UI components and data models as well as they know internal systems.
Your role: publish a product pack and the integration patterns that go with it.
Writing an org's first Steering Ledger and committing its baseline architecture is real work, and most teams want help.
Your role: deliver rkito implementations and turn your methods into reusable packs.
Pick the track that matches what you sell. Many partners join more than one, for example a consultancy that also publishes its own patterns.
Security firms, compliance specialists, cloud vendors, framework authors
Your standard, applied by default.
Developer tools, catalogs, API platforms, data and observability vendors
Agents integrate your product the right way.
Systems integrators, architecture consultancies, platform engineering firms
Lead the move to agentic engineering.
Maintainers, foundations, practitioner communities
Your project's conventions, followed by agents.
Your customers' agents are already writing integrations with your product, often from outdated docs. Publish two packs and every customer org that installs them gets your product in its architecture and your guidance in its rules.
Your product as an external system in the customer's ledger, with the interfaces their systems depend on.
Your recommended integration code patterns and best practices, resolved into Lenses the IDE and the PR gate enforce.
kind: product-pack name: northwind-identity publisher: northwind-security version: 2026.09.0 system: type: external category: identity-provider interfaces: ui: [login-widget, mfa-prompt] api: ./openapi/identity-v4.yaml events: ./asyncapi/identity-events.yaml data_models: [User, Session, Factor] scenarios: - id: sign-in-with-mfa guide: ./scenarios/sign-in-with-mfa.md uses: [POST /v4/sessions, mfa-prompt] - id: rotate-refresh-tokens guide: ./scenarios/rotate-refresh-tokens.md companion_steering: northwind-identity-patterns
Illustrative mock. File format is proposed, not final.
When a customer iterates on a design with Claude, options that misuse your product are flagged against your patterns before anyone writes code.
Scenarios and patterns reach Claude Code, Cursor and every MCP agent in customer orgs.
The PR gate catches misuse, such as a skipped signature check, before it reaches production.
When you ship a new API version or deprecate an endpoint, each customer gets a Change Intention listing exactly which of their systems are affected.
Learn which scenarios customers build and which Lenses fail most, so you know where your docs and APIs need work.
Illustrative mock. Northwind is a fictional partner.
Every listing type plugs into the same ledgers, so whatever you ship shows up consistently in the IDE, in agent sessions and at the PR gate.
| Listing type | What it contains | Ledger | IDE / agent | PR gate |
|---|---|---|---|---|
| Steering packStandards and content | Policies, best practices, patterns and the Lenses they resolve to | |||
| Integration pattern packTechnology | A Steering pack for one product: integration code patterns, best practices and the Lenses that check them | |||
| Product packTechnology | Your product as an external system: UI components, API definitions, data models, events and integration scenarios | |||
| Lens packStandards and content | Stand-alone yes-or-no checks that extend an existing pack | |||
| Architecture connectorTechnology | Reads systems, interfaces, API specs or data models from a source and proposes ledger changes | |||
| Agent or IDE integrationTechnology | Brings approved decisions and current architecture into design sessions in a coding agent or editor, then keeps implementation within the approved scope | |||
| SkillAny track | Governed instructions for a system type, bundled with the Lenses that apply to it | |||
| Gate integrationTechnology | Runs the Continuous Design Audit in another CI system or code host | |||
| Workflow appTechnology | Connects design reviews, Change Intentions and findings to ticketing, chat and change management |
Most technology and content partners go from approval to a published listing in a few weeks. Services partners certify in parallel with their first customer engagement.
Tell us your track and what you plan to build or deliver.
Identity check, partner agreement and a short intro call.
Sandbox org, builder kit and a named partner engineer.
rkito reviews your listing against the certification standard.
Signed release, listing page, versioning and changelog.
Adoption analytics, co-marketing and tier upgrades.
Timelines shown are proposed targets.
Enterprises let Lenses block pull requests and shape what agents write. That only works if every listing is predictable, scoped and accountable. The same standard applies to rkito's own listings.
Certification is repeated for every major version. Minor versions go through automated checks.
Every Lens returns the same yes-or-no verdict on the same input, across the test suite you ship with the pack.
Listings propose changes through a Change Intention. Nothing auto-approves or writes to a ledger directly.
Connectors declare exactly what they read. No write access to customer repositories.
Every version is signed with your publisher key, pinned per org and upgradable through review.
Product pack API definitions match your published, versioned spec, and every scenario runs against your sandbox.
Each Lens carries a rationale and a reference, so reviewers see why a finding was raised.
A listing page, a mapping guide for system categories and at least one worked example.
Hosted connectors complete a security review. Required for Premier.
Packs live in a repository, carry their own tests and ship through a CLI. You get the same review, versioning and release discipline your customers expect from their own code.
name: secure-api-design publisher: northwind-security version: 3.1.0 applies_to: categories: [public-api, partner-api] artifacts: - policy: NS-AUTH title: Every public endpoint authenticates callers lenses: - id: NS-AUTH-02 question: Does each new route declare an auth scheme? rationale: docs/auth.md#schemes - best_practice: NS-VER title: Breaking changes ship behind a new version path tests: ./fixtures # required for certification
$ rkito pack init secure-api-design created rkito-pack.yaml, fixtures/, docs/ $ rkito pack test 31 lenses · 248 fixtures determinism pass (3 runs, 0 verdict changes) schema pass rationale pass (31 of 31 linked) $ rkito pack publish --channel review signed with key northwind-2026 submitted for certification · ticket PR-0192
Illustrative mock. File format and CLI commands are proposed, not final. The builder kit is not available yet: request it with the application form.
Tiers are earned through certified listings, customer adoption and delivered implementations. Every tier keeps the same certification standard.
| RegisteredStart building | VerifiedListed and certified | PremierStrategic partner | |
|---|---|---|---|
| Requirements | |||
| Agreement | Accept partner terms | Identity verified | Joint business plan |
| Listings | None required | One certified listing | Three certified listings or ten delivered implementations |
| Enablement | Optional | One certified builder or consultant | Five certified people |
| Benefits | |||
| Sandbox org | Included | Included | Multiple sandboxes |
| Marketplace | Community listings | Verified badge, free and paid listings | Featured placement and collections |
| Analytics | Basic installs | Adoptions and Lens evaluations | Full console and data exports |
| Go to market | None | Partner directory, co-marketing kit | Co-sell, deal registration, joint launches |
| Support | Community forum | Partner engineer during certification | Dedicated partner manager, roadmap previews |
Proposed tier structure for discussion. Requirements and benefits are not final.
You own what you build. We handle distribution, billing and trust.
No program fee at any tier. Sandbox orgs are included.
Charge per org for Steering packs and connectors. rkito bills the customer and pays out your revenue share monthly.
Enterprise customers buy your listing on their existing rkito contract, without a new vendor review.
You keep ownership of your content and code. Customers license it for use inside rkito.
Registered partners get sandbox access as soon as the application is accepted. We reply to every application.
No. Installing a listing opens a Change Intention in the customer's org. Their architects review each policy, Lens and mapping, and can edit or reject any of it. Adoption analytics show you which parts customers keep, which is useful feedback for your next version.
The product pack describes what your product is: its UI components, API definitions, data models, events and integration scenarios. It lands in the customer's Architecture Ledger as an external system. The Steering pack describes how to integrate with it well: code patterns, best practices and the Lenses that check them. It lands in the Steering Ledger. Publish them together so agents get both the facts and the guidance.
Yes, provided you have the right to use the standard's content and you credit it on your listing. rkito maintains official packs for several widely used standards, so a partner pack should add depth, a specific domain or an interpretation that customers can't get from the official one.
The proposed target is ten business days from submission for a first listing, and faster for new versions. Listings that ship with a complete Lens test suite move through review quickest.
Steering packs, Lens packs and Skills are published as signed artifacts and run inside rkito, so there's nothing to host. Connectors and workflow apps can run inside rkito or as your own hosted service. Hosted services complete a security review.
No. You can publish the same expertise elsewhere. Premier partners agree a joint business plan, but that doesn't restrict where else you work.
Orgs keep the version they have pinned. We notify them and mark the listing as unmaintained, and nothing changes in their ledgers without their review.
