Skip to main content

External Helpifyr Boost Onboarding

Use this page when an external or adjacent partner needs one exact admissible onboarding packet instead of a loose pile of orientation links.

Download the canonical packet​

The markdown pack explains the review model in plain language. The JSON template gives three ready-to-copy request bodies for oss-repository, proprietary-service, and hybrid. Submit only one chosen variant object, not the wrapper file.

When to use this page​

  • You are onboarding a partner-operated boost or adjacent tool into the Helpifyr review path.
  • You need one exact packet of mandatory deliverables before Fabric can treat the request as reviewable.
  • You must explain the difference between orientation docs and the actual admission request.

Boost preparation flow​

Step 1: Choose the correct integration model​

integration_model is always required. Leaving it empty or omitting it is malformed and should fail closed.

ModelUse it whenMandatory evidence
oss-repositorythe boost is openly published and a public repository is part of the agreed integrationOSS inventory document plus OSS inventory verify entrypoint
proprietary-servicethe boost is privately operated and no public repository is part of the integrationproprietary verification with non-sensitive evidence reference
hybridthe boost mixes public repository surfaces with a closed or hosted coreboth OSS inventory evidence and proprietary verification

Step 2: Prepare the mandatory packet​

What the partner must return​

  • one canonical manifest_document with stable identity, capability class, runtime kind, lifecycle stage, version, and release channel
  • one knowledge_extension_manifest_v1 when the boost produces, consumes, or extends governed knowledge, context-graph, model-selection, or memory surfaces
  • one docs entrypoint with the relevant tool-profile, integrations, capabilities, API, and OSS inventory surfaces
  • explicit producer declarations for every Fabric-owned contract family the tool publishes
  • explicit consumer declarations for every Fabric-owned contract family the tool consumes
  • compatibility posture, lifecycle posture, and verify metadata
  • readiness and live-evidence targets that can be read back without guessing
  • one completed dry-run payload based on the canonical template

What the dry-run payload must say​

  • who the tool is, what capability class it belongs to, and which runtime kind it uses
  • which release channel and lifecycle stage the partner is asking to admit
  • which contract families the tool produces and consumes
  • whether the boost participates in semantic knowledge projection, context assembly, episodic memory, external-connector onboarding, or physical-world observation only
  • where the reviewer can find compatibility posture, verify entrypoint, and live readiness targets
  • which known boundaries, exclusions, or fail-closed conditions already apply

Public-safe dry-run declaration​

A public reader should be able to reconstruct the expected request shape from this page alone. The minimum declaration set is:

  • tool identity: tool name, owner, runtime kind, and capability class
  • lifecycle request: requested stage, release channel, and intended promotion target
  • contract usage: produced families, consumed families, and any known restricted families
  • verification: exact verify command or entrypoint, plus the readiness or live surfaces to read back
  • boundaries: exclusions, unsupported modes, rollout limits, and any fail-closed conditions already known

Step 3: Fill the packet without drift​

Identity and classification​

  • use one stable id, tool_key, and human-readable tool name
  • choose exactly one canonical capability class
  • keep runtime_kind, version, release_channel, and lifecycle posture aligned with the real runtime

Docs and evidence​

  • point docs_entrypoint to the public overview a reviewer should start from
  • include tool profile, integrations, capabilities, API, and compatibility surfaces
  • for OSS or hybrid boosts, include the OSS inventory path and the repo-local verify command
  • for proprietary or hybrid boosts, provide proprietary_verification with a non-sensitive evidence reference

Contracts and verification​

  • declare which Fabric contract families are produced and which are consumed
  • if the boost touches governed knowledge, declare the exact ontology, producer, consumer, and extension manifests instead of describing them only in prose
  • if the boost needs admitted model choice, declare the expected model-binding posture and the provider or residency restrictions that apply
  • provide one repeatable verify_entrypoint
  • provide readiness surfaces and one live verification target another reviewer can read back

Knowledge and extension onboarding​

If the boost wants to participate in the semantic platform, the onboarding packet must make that explicit.

Minimum additions:

  • knowledge_extension_manifest_v1
    • extension type, bounded context, fact classes, relation classes, sensitivity, deletion strategy, and degraded mode
  • producer and consumer manifests
    • what the boost publishes, what it reads, and which Fabric-owned families remain read-only
  • authority posture
    • whether the boost is authoritative, reviewed, extracted, inferred, or recommendation-only for each fact family
  • model posture
    • the admitted model profile or provider family the boost expects, without assuming one hardcoded LLM identity
  • verification posture
    • exact replay, readback, and post-merge verify surfaces

Do not submit a semantic or memory-aware boost as if it were only a generic API connector. The review packet must show how knowledge, context, deletion, and fail-closed behavior are governed.

Step 4: Run the self-check before submission​

Use the completed payload against the admission dry-run surface before sending the packet onward.

ResultMeaningRequired action
200 readythe request is well-formed and admissiblesubmit the packet
200 ready-with-followupsthe request is admissible but still has warningsclear the warnings where possible
200 blockedthe payload is structurally valid but semantically not admissiblefix the blocking findings first
422the payload is malformedfix the structure, missing fields, extra fields, or secret-like evidence

Common fail-closed cases​

  • omitting integration_model
  • omitting knowledge_extension_manifest_v1 when the boost claims semantic knowledge, memory, or context-assembly participation
  • mixing OSS inventory fields into a proprietary-service body
  • omitting proprietary_verification for proprietary or hybrid boosts
  • putting a token, password, API key, or connection string into evidence_ref
  • declaring a capability class or contract family that does not match the canonical Fabric vocabulary
  • assuming one specific LLM name is mandatory instead of declaring an admitted model capability or profile
  • claiming readiness surfaces that another reviewer cannot actually read back
  • presenting physical-world or external SaaS action authority as if information access alone granted execution authority

Review order​

  1. Send the canonical admission pack and dry-run template.
  2. Ask the partner to return the completed template plus linked artifacts and evidence.
  3. Validate the payload against the admission schema and governance surfaces.
  4. Execute the partner verify entrypoint and read back the declared readiness surfaces.
  5. Record the verdict in Fabric and open downstream adoption work only after the evidence is complete.

Do not use these as substitutes​

  • API Surface Map is orientation help, not the admission contract.
  • Build an Integration is the journey page, not the review packet.
  • product API or compatibility pages can support evidence, but they do not replace the Fabric-owned dry-run request.

Public packet summary​

  • one onboarding brief that states scope, capability, runtime, and explicit non-goals
  • one dry-run payload that declares identity, lifecycle, producer and consumer usage, and verify targets
  • one semantic-extension declaration when the boost touches knowledge, model selection, or context assembly
  • one evidence bundle that points reviewers at the exact docs, compatibility posture, and readback surfaces
  • the authoritative review contract still remains Fabric-owned, but a public reader should understand the packet from this page alone

Verification​

This page is working when a partner can download the packet, choose the correct request mode, return the dry-run payload in the right shape, add the semantic-extension declaration where required, and understand that Fabric remains the admission verdict owner.

Next paths​