Integrate / Product integration
Build neighboring products
The product family shares contextual sense resolution, comparison, evidence, and provenance. Applications add their own experience around these contracts; they should not create competing definitions of a sense or accepted evidence.
Available foundation#
| Product surface | Existing building blocks | Further work |
|---|---|---|
| Lens | resolve, compare, illuminate, reference lookup |
Standalone experience, Lore, broader interpretation coverage |
| Resolve | Argument review, typed candidate claim comparisons, evidence assessment | Validated crux detection and multi-person sessions |
| What You Mean? | Authored challenges and practice activities | Session state, invites, independent answers, comparison flow |
| Studio | Contextual resolution and source-aware observations | Permissioned ingestion, interpretation clustering, creator Notes |
| Write | Argument review, wording-based scope and strength comparison | Integrated revision editor and broader evaluation |
| Teams | Shared semantic API | Organization tenancy, role-based access, private term management |
| Perb | SDK and agent-scoped observation paths | Platform acceptance, correction evaluation, operational limits |
Resolve once, preserve the result#
Use the SDK response as the shared record of a resolution. Keep its sources, alternatives, review state, and available release identity. A product may present a shorter explanation, but should not discard uncertainty or convert a candidate into an accepted sense.
Treat capabilities as explicit#
Check the capabilities endpoint before enabling optional paths. Provider-backed inference requires account or key access and server configuration. A missing provider should produce a clear unavailable state; it should never quietly present a deterministic fallback as model inference.
Keep product data private#
Do not submit drafts, messages, or comments as observations by default. Explicit observation submissions have separate permissions and require review before permitted corpus use. Organizational isolation and authorization need implementation and adversarial tests before Teams can accept private multi-tenant data.
Keep claims distinct from senses#
The existing sense-comparison result is not a claim-equivalence or evidence-support verdict. Use compareClaims, analyzeArgument, and evaluateEvidence for their separate typed candidate results. The current deterministic checks are wording-based; wider claims about strength, scope, criteria, or evidence fit require product-specific evaluation.
Handle errors and retries#
Use SuperbError.status to distinguish unavailable services, invalid input, rate limits, and denied access. The SDK supports cancellation and a configurable timeout. Avoid blind retries on writes. Task answers are idempotent for the same answer; changing a stored answer returns a conflict.
Integration checklist#
- Exercise selected, unresolved, empty, invalid, and unavailable responses.
- Test unauthorized access and cross-account access for every private object.
- Keep all model credentials server-side.
- Verify source withdrawal and release access before displaying stored evidence.
- Keep generated explanations separate from accepted semantic records.
- Add a product-specific evaluation set before describing a new capability as validated.
The SDK guide documents implemented methods. Backend operations describes ingestion and release gates. Broader portfolio features remain development work rather than implied API promises.