Who is the KontextOS partner program for?
KontextOS is exploring relationships with consultancies, managed service providers, systems integrators, technology providers, industry specialists, and associations that can introduce customers, support implementation, or deliver services arising from organizational diagnostic findings.
Partner status, benefits, commercial rights, protected opportunities, and delivery responsibilities exist only when granted by a definitive written agreement. Public descriptions of prospective partner paths are invitations to discuss a relationship, not automatic appointments or offers of exclusivity.
What role can a partner play?
Depending on the applicable agreement and customer authorization, a partner may introduce KontextOS, help qualify an opportunity, support a bounded pilot, prepare a customer-controlled environment, install and configure the software, facilitate an engagement, interpret approved findings, deliver remediation, integrate systems, train users, provide support, or incorporate authorized KontextOS work into a broader managed service.
For an overview of these opportunities, visit the Partners page.
The customer is ordinarily intended to administer its own diagnostic cohort. A partner's role should be defined by the customer engagement and must not create unnecessary access to customer-controlled diagnostic information.
PDATA itself has a training role: approved courses can teach participants, collect authorized organizational context, support diagnostics, or combine training and discovery. Partner-led workshops, facilitation, custom instruction, and change enablement remain separately scoped professional services. The initial pilot package uses Intro to Applied AI for one defined diagnostic; the planned signed course lifecycle is intended to support additional approved courses and compatible revisions but is not currently implemented.
How does KontextOS complement an existing AI-readiness assessment?
A partner's assessment may evaluate AI maturity, governance, systems, skills, use cases, and implementation priorities. KontextOS examines whether the organizational context supporting those decisions is complete, consistent, representative, and trustworthy.
The intended KontextOS workflow is asynchronous and customer-controlled. It produces customer-reviewed, evidence-linked candidate findings and reusable contextual assets that can reveal conflicting perspectives, undocumented knowledge, unclear ownership, policy-practice gaps, hidden dependencies, and unsupported assumptions. Those outputs can strengthen the basis for a partner's strategy, roadmap, implementation, or managed-services work.
Does KontextOS replace billable discovery?
KontextOS may replace some manual discovery activity, particularly when a provider already sells interview- and workshop-intensive assessments. Its commercial purpose is to make structured discovery faster, more repeatable, and practical across more accounts or business units, while identifying legitimate downstream needs in strategy, data, integration, security, governance, workflow redesign, training, change management, and managed services.
For the broader opportunity facing IT services providers, read The connected economy has a resilience problem.
Whether KontextOS increases total partner revenue, margin, account coverage, and customer continuity has not yet been proven through partner deployments. Initial pilots should measure discovery labor, time to findings, implementation conversion, downstream revenue, gross margin, additional service opportunities, account expansion, recurring work, participation, completion, and any displaced discovery revenue.
Which partner rights may be available?
The following roles are contemplated but are not automatic:
-
Referral: A definitive agreement may authorize referral fees, commissions, renewal participation, or temporary protection for a qualified and actively developed opportunity.
-
Resale: Resale may be authorized in a commercial schedule, but it is not the default customer-contracting model.
-
Implementation: A partner may separately compete for and contract with the customer to provide installation, integration, remediation, training, support, and related professional services.
-
Facilitation: A partner may coordinate participation, administer courses, facilitate review workshops, interpret customer-approved results, and support decisions when the customer requests those services.
-
Sponsorship: A partner or association may sponsor a pilot, evaluation, member program, or adoption initiative under specifically negotiated terms.
-
Managed services: A partner may deliver governance, support, remediation, or context-maintenance services around KontextOS. Bundling platform access, reselling it, or presenting it under a partner brand requires express authorization.
The applicable agreement must define compensation, customer contracting, branding, data access, support obligations, and any referral, resale, bundling, facilitation, or managed-services authority.
Are account protection, territories, exclusivity, or customer work guaranteed?
No such right is automatic. A definitive agreement may provide temporary, conditional protection for a named opportunity, market segment, or territory. Any protection should depend on agreed activity and performance milestones and remain subject to customer choice, existing relationships, legal restrictions, and the agreement's duration and termination terms.
A partner may receive an opportunity to propose implementation or follow-on services, but the customer chooses its provider. Diagnostic findings must never be altered, suppressed, delayed, or exaggerated to manufacture services revenue.
Can KontextOS be white-labeled?
Yes, for qualified partners under a definitive written agreement. KontextOS offers three client-facing branding levels:
-
Referral partner: KontextOS branding remains client-facing while the provider introduces prospective clients.
-
Co-branded partner: The provider markets and delivers a KontextOS-enabled service under an approved identity such as “Partner Name, powered by KontextOS.” This is the standard partner model.
-
Private-label partner: The partner's brand may be primary, while KontextOS is disclosed contractually and wherever else required. This level is reserved for strategically committed partners that assume greater responsibility for sales, delivery, and client support.
Private-label rights are not automatic. KontextOS would ordinarily evaluate the partner's client base or distribution capacity, trained sales and support personnel, service and quality controls, privacy and cybersecurity practices, escalation process, willingness to provide structured feedback, and a meaningful annual, volume, or implementation commitment. Approval may be limited, suspended, reduced, or withdrawn based on performance, compliance, customer service, commercial commitment, and strategic fit.
Every level permits only the claims, marks, templates, product descriptions, domains, and configurations approved in the applicable agreement. A partner may not claim ownership of KontextOS, remove required legal or accessibility notices, imply unauthorized exclusivity or agency, or create an independently maintained product fork. KontextOS retains its platform, methodology, assessments, training system, standard materials, improvements, and reusable intellectual property.
Approved configurations may include logos, colors, terminology, domains, templates, and client-facing communications, provided they preserve usability, security, accessibility, maintainability, legal compliance, and product integrity.
Under a co-branded or private-label arrangement, the partner may manage the primary commercial relationship, but the agreement must allocate contracting, billing, onboarding, first-line support, technical escalation, compliance, service continuity, and the distinction between partner services and KontextOS obligations. Client data remains the client's; the agreement must also define access, processing, security, retention, export, deletion, portability, and incident-response responsibilities.
Who administers the customer cohort?
The customer is intended to define the diagnostic scope, select participants, establish evidence permissions and privacy conditions, monitor participation, and supervise review. KontextOS personnel and partner personnel are not ordinarily required to administer the cohort or receive the underlying sensitive evidence.
A customer may separately engage a qualified partner for facilitation or administration. That service must be authorized and scoped, and the resulting access must follow least-privilege, purpose-limited, and customer-controlled requirements.
What customer information may a partner access?
A partner may access only the information necessary for its authorized responsibilities. Installation should generally be limited to infrastructure requirements, configuration parameters, installation assets, technical health checks, installation status, and sanitized diagnostic logs.
Installation does not inherently require access to the customer's scope, participant identities, organizational structure, responses, evidence, findings, reports, or AI interactions. The customer should manage passwords, tokens, API keys, and encryption keys whenever practical. Any unavoidable privileged access should be temporary, purpose-specific, securely handled, logged, and revoked after the work is complete.
After authorized work ends, the partner should retain no customer content or deployment assets except limited operational records required by contract or law. Later break-fix or upgrade access should require separate customer authorization.
What training and certification requirements apply?
The exact curriculum, certification criteria, completion deadlines, renewal requirements, and review cadence have not been finalized. A definitive partner agreement may require personnel to complete current KontextOS training, maintain product knowledge, and obtain or retain certification for particular sales, technical, privacy, implementation, facilitation, industry, or service-delivery roles.
Until a certification program and agreement are in effect, a prospective partner should not represent itself or its personnel as KontextOS-certified.
What quality standards would a delivery partner follow?
A delivery partner would be expected to follow the current KontextOS brand, security, privacy, responsible-AI, implementation, and quality requirements; use approved materials and current diagnostic definitions; maintain applicable professional and regulatory standards; disclose conflicts; preserve the accuracy and independence of findings; and report material complaints, security incidents, legal demands, or suspected misuse through defined channels.
Final quality-control procedures, audit rights, review cadence, remedies, and escalation obligations must be stated in the definitive agreement and applicable delivery documentation.
Who provides customer support?
Responsibilities depend on the contracted scope. KontextOS maintains the platform under the applicable customer agreement. A partner remains responsible for its separately contracted consulting and implementation services, including staffing, subcontractors, deliverables, warranties, regulatory compliance, and service support.
Installation, integration, remediation, custom or facilitated training, managed services, and ongoing support are outside the software price unless separately contracted. These services are distinct from approved courses licensed for delivery through PDATA. No response-time, resolution-time, uptime, escalation, service-credit, or other service-level commitment should be assumed unless it appears in a signed agreement.
What parts of KontextOS are available today?
KontextOS can demonstrate its course-led diagnostic and training method, fictional-data Organizational Simulation, evidence-to-findings workflow, human-review concepts, organization-scoped access, and simulated Executive Dashboard. The simulation is the current hosted offering and does not accept real organizational evidence. The PDATA application and deployment package are now in early testing. Its expandable signed course lifecycle is specified but not currently implemented.
KontextOS is preparing to open a limited number of bounded, partner-supported PDATA pilots using real organizational evidence. Pilot participation will require a verified customer-controlled environment, a supported release configuration, written responsibilities and success measures, and definitive commercial terms. The PDATA is not generally available and has no direct online checkout. Persistent KontextOS remains planned and partner-dependent. A prospective partner must not represent early testing, expected pilot availability, production support, security validation, commercial activation, or continuing operations as general production availability.
What are the minimum customer-environment requirements for a PDATA pilot?
Exact CPU, memory, storage, operating-system, and container-runtime minimums remain an internal release decision and must be validated before a partner scopes infrastructure. The current provisional baseline is one dedicated, customer-provided Linux virtual machine or server with persistent encrypted storage, customer-managed backup and recovery, HTTPS, an approved hostname and DNS configuration, required ports, reliable time synchronization, and network access for authorized participant and administrator browsers.
The customer must designate a qualified administrator and select one KontextOS-approved AI provider and model. An approved external provider requires customer-controlled credentials and explicitly permitted outbound access to its endpoint. A local model requires a separately supported runtime and model-specific compute capacity; a GPU is required only if the selected local model configuration requires one. Kubernetes, enterprise identity-provider integration, and source-system connectors are not prerequisites for the initial single-server pilot.
Before committing to a pilot, the partner and customer must complete the KontextOS preflight for architecture, resources, storage, certificates, network and proxy constraints, AI data flow, backup, installation access, support, teardown, and data destruction. A partner must not quote infrastructure or promise compatibility until KontextOS identifies the supported release configuration in writing.
What would an initial partnership look like?
Early partnerships should be bounded pilots rather than national or unrestricted rollouts. A pilot should define the customer profile, use case, customer count, deployment configuration, duration, responsibilities, data-access boundary, support model, commercial terms, success measures, and conditions for expansion.
The pilot should test installation and removal, backup and recovery, model behavior, customer control, privacy, human review, finding traceability, delivery responsibilities, support escalation, customer value, willingness to pay, and partner economics. Commitments should follow verified pilot evidence rather than precede it.
Is KontextOS ready for national or association-wide delivery?
Not yet. Exploratory conversations and bounded evaluations are appropriate, but a national distribution, endorsement, sponsorship, or broad member-delivery proposal would be premature until KontextOS has repeatable real-customer delivery, documented security and recovery evidence, a delivery-capable partner, defined training and quality controls, reliable partner administration, truthful commercial terms, sufficient support capacity, and referenceable customer value.
An association conversation should clearly distinguish research or a pilot from endorsement, regulatory approval, guaranteed outcomes, or authorization for national delivery.
What commercial terms are established?
The free Organizational Simulation is organization-scoped and available through a reviewed request. Published PDATA pricing describes the intended commercial positioning for limited pilots opening after early testing; it is not currently purchasable through online checkout. The Standalone Course Builder is under active development, with a bounded pilot rollout expected imminently. It is priced at $1,995 per end-user author for the first year, with an introductory first-year price of $1,495; additional partner or end-user authors are $750 for the first year. Each SCB author license renews at $199 per year after the first year. An active Authorized Partner receives its first trained SCB author license at no separate charge. Persistent KontextOS remains planned and partner-dependent at $7,950 for the first year, with a targeted $5,950 first-year competitive-conversion price where authorized, and $499 per year thereafter.
The commercial model separates software from services: KontextOS defines software pricing, while a partner independently scopes and prices its professional services. Commissions, discounts, conversion arrangements, referral fees, renewals, account protection, exclusivity, territories, demonstration allowances, payment timing, clawbacks, training benefits, support obligations, and other program terms remain subject to a definitive agreement.
How should a prospective partner proceed?
A prospective partner should begin with a discovery discussion about its customer relationships, industry expertise, technical and service capabilities, potential pilot customers, delivery capacity, and the specific contribution it is prepared to make. Neither the discussion nor access to demonstration materials creates partner status or commercial rights.
To start the conversation, use the partner contact form.
Important notice
This FAQ describes the current partner direction and contemplated roles. It is not a partner appointment, reseller authorization, license, service-level agreement, offer of exclusivity, or guarantee of pilot selection or general product availability. Only a definitive written agreement can grant partner rights or establish binding responsibilities.
