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.
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.
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.
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?
Unrestricted white labeling is not included in the proposed partner model. Any co-branding, embedded offering, managed-service presentation, or use of the KontextOS name and marks requires express written authorization. KontextOS retains ownership and control of its core platform and reusable intellectual property unless a definitive agreement expressly states otherwise.
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, training, managed services, and ongoing support are outside the software price unless separately contracted. 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 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 PDA application and deployment package are now in early testing.
KontextOS is preparing to open a limited number of bounded, partner-supported PDA 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 PDA 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 PDA 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 PDA pricing describes the intended commercial positioning for limited pilots opening after early testing; it is not currently purchasable through online checkout. Persistent KontextOS remains planned and partner-dependent.
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.
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.
