| name | haipipe-end |
| description | Run any Stage 6 endpoint work: routes intent to the right specialist across Fn-type, artifact-verb, develop-target, and deploy-target axes. Use for designing inference Fns, packaging Endpoint_Sets, training a build, local inference tests, or deploying anywhere. Trigger: endpoint, deploy, develop, train, package, inference Fn, MetaFn, TrigFn, PostFn, Src2InputFn, Input2SrcFn, /haipipe-end. |
| argument-hint | [target_or_fn_or_verb] [args...] |
| allowed-tools | Bash, Read, Grep, Glob, Skill |
| metadata | {"version":"0.1.2","last_updated":"2026-07-08","summary":"Run any Stage 6 endpoint work."} |
Skill: haipipe-end (orchestrator)
User-facing entry for Stage 6.
Routes across four axes:
1. Fn-type axis meta | trig | post | src2input | input2src
-> per-Fn-type specialist (one skill per type)
2. Artifact axis package | test | profile | dashboard | review (overall)
-> haipipe-end-endpointset
3. Develop axis develop <target> where target is one of
sagemaker | databricks | local
-> haipipe-end-develop-<target>
PRODUCES the Endpoint_Set (build side)
4. Deploy axis deploy <target> where target is one of
sagemaker | databricks | local | mlflow
-> haipipe-end-deploy-<target>
SERVES the Endpoint_Set (serve side)
The develop and deploy axes share targets but operate on different lifecycle phases of the same artifact: develop BUILDS, deploy SERVES.
/haipipe-end -> cross-scope dashboard (artifact + develops + deploys)
/haipipe-end <fn-type> [verb] -> per-Fn-type specialist
/haipipe-end <artifact-verb> [args] -> endpointset specialist
/haipipe-end develop <target> <args> -> develop specialist
/haipipe-end deploy <target> <args> -> deploy specialist
/haipipe-end <target> <verb> [args] -> develop or deploy (verb decides; default: deploy summary + soft-ask)
/haipipe-end "<natural language>" -> infer axis, dispatch
/haipipe-end overview | explain [question] -> handled inline (cross-cutting)
Specialists
PER-FN-TYPE (5)
haipipe-end-meta MetaFn — model metadata lookup
haipipe-end-trig TrigFn — trigger detection
haipipe-end-post PostFn — response formatting
haipipe-end-src2input Src2InputFn — record → wire payload
haipipe-end-input2src Input2SrcFn — wire payload → record
ARTIFACT-AS-WHOLE (1)
haipipe-end-endpointset Endpoint_Set lifecycle: package, test, profile, review, dashboard
PER-TARGET DEVELOP (3) BUILDS the Endpoint_Set
haipipe-end-develop-sagemaker AWS SageMaker Pipeline (wraps platforms/platform-sagemaker-training/)
haipipe-end-develop-databricks Databricks Job ⚠️ deferred (repo platforms/platform-databrick-training/ exists; wiring + Lesson-15 reconciliation pending)
haipipe-end-develop-local local sequencer (delegates to /haipipe-nn modelset + endpointset package)
PER-TARGET DEPLOY (4) SERVES the Endpoint_Set
haipipe-end-deploy-sagemaker AWS SageMaker (wraps platforms/platform-sagemaker-inference/)
haipipe-end-deploy-databricks Databricks Model Serving (wraps platforms/platform-databrick-inference/)
haipipe-end-deploy-local local self-hosted (Flask / FastAPI / Docker)
haipipe-end-deploy-mlflow MLflow registry + serve ⚠️ deferred (no platform repo)
Fn-type Keyword Map
MetaFn, model metadata, model card, meta -> meta
TrigFn, trigger, gate, condition, trig -> trig
PostFn, response format, post-process, post -> post
Src2InputFn, record-to-payload, serialize, src2input -> src2input
Input2SrcFn, payload-to-record, deserialize, input2src -> input2src
Artifact verb map (for endpointset)
package, build artifact, run pipeline, scaffold endpoint set -> endpointset (package)
test, smoke test, local test, run inference -> endpointset (test)
review (overall, no fn-type) -> endpointset (review)
dashboard, status, what's there -> endpointset (dashboard)
Develop verb keyword map (selects the develop axis)
develop, build endpoint_set, train, training pipeline,
RegisterModel, model package group, build artifact (cloud) -> develop axis
Note: bare package stays on the artifact axis (endpointset).
The develop axis is for running training infrastructure (SageMaker Pipeline, Databricks Job, local nn-modelset run) that PRODUCES an Endpoint_Set.
Develop target keyword map
sagemaker (with develop verb), aws training, ModelPackageGroup -> develop-sagemaker
databricks (with develop verb), Databricks Job, Unity Catalog
(training context) -> develop-databricks
local (with develop verb), local training, dev box build -> develop-local
Deploy target keyword map
sagemaker, aws, ECR, model.tar.gz -> deploy-sagemaker
databricks, unity catalog, model serving -> deploy-databricks
local, flask, fastapi, localhost, dev server -> deploy-local
mlflow, mlflow registry, mlflow serve, pyfunc -> deploy-mlflow
Develop verb map (forwarded as args to develop-* specialist)
develop <target> <config> -> develop (full build)
test <config> -> local-system / local-docker test
monitor <execution_id> -> tail pipeline / Job / local logs
teardown <execution_id> -> stop run, optional registry cleanup
review <execution_id_or_arn> -> audit completed run
Deploy verb map (forwarded as args to deploy-* specialist)
deploy <target> <endpoint_set> -> deploy
test <endpoint_id> -> test live endpoint
monitor <endpoint_id> -> tail logs / metrics
teardown <endpoint_id> -> stop endpoint, cleanup
review <endpoint_id> -> audit deploy config
Routing Logic
Step 1: Parse $ARGUMENTS.
Step 2: Detect axis (priority order, first match wins):
a) Fn-type keyword present? -> Fn-type axis
b) Develop verb present + target? -> Develop axis
c) Develop verb alone (no target) -> ASK target
d) Deploy verb 'deploy' present + target? -> Deploy axis
e) Deploy verb 'deploy' alone (no target) -> ASK target
f) Target alone (no develop/deploy verb)? -> Deploy ref-only summary (default)
+ soft-ask: "did you mean develop?"
g) Artifact verb (package/test/profile/dashboard)? -> Artifact axis
h) Verb 'review' alone, no <id>, no fn-type -> Artifact axis (review-overall)
i) Verb 'review <id>' -> Deploy axis (review live deploy)
-> resolve target from local registry
j) 'overview' / 'explain' -> INLINE (umbrella reads ref/0-overview.md)
k) No args -> CROSS-SCOPE DASHBOARD (parallel fan-out)
Step 3: Dispatch:
Fn-type axis -> Skill("haipipe-end-<fn-type>", args="<verb> <rest>")
Artifact axis -> Skill("haipipe-end-endpointset", args="<verb> <rest>")
Develop axis -> Skill("haipipe-end-develop-<target>", args="<verb> <rest>")
Deploy axis -> Skill("haipipe-end-deploy-<target>", args="<verb> <rest>")
Step 4: Capture the specialist's structured tail (status / summary /
artifacts / next), present to user. If status != ok, stop chaining.
Target-alone disambiguation (rule f)
When the user types just a target (e.g.
/haipipe-end sagemaker), default to the deploy ref-only summary (more common ask) and append a single clarification line:
[deploy-sagemaker ref-only summary here]
→ if you meant the build side, run: /haipipe-end develop sagemaker [args]
This keeps the common path zero-friction while making the develop side discoverable.
Cross-Scope Dashboard (no-arg case)
When invoked with no arguments, fan out in parallel and concatenate tails:
Skill("haipipe-end-endpointset", args="dashboard") # what's packaged
Skill("haipipe-end-develop-sagemaker", args="dashboard") # SageMaker training pipelines + ModelPackages
Skill("haipipe-end-develop-local", args="dashboard") # local develop registry
Skill("haipipe-end-deploy-sagemaker", args="dashboard") # live on SageMaker
Skill("haipipe-end-deploy-databricks", args="dashboard") # live on Databricks
Skill("haipipe-end-deploy-local", args="dashboard") # running locally
# develop-databricks and deploy-mlflow excluded while deferred
The 5 per-Fn-type specialists are NOT included in the no-arg dashboard (they'd repeat the same artifact-level info).
For per-Fn-type status use /haipipe-end-endpointset review.
Inline Modes (umbrella handles itself, no dispatch)
/haipipe-end overview and /haipipe-end explain [question]:
- Read
ref/0-overview.md (Stage 6 architecture, inference pipeline, YAML).
- If the question references a specific Fn-type, also read that
specialist's
ref/concepts.md for context.
- Answer directly. Cite which ref docs informed the answer.
These run inline — no Skill() call.
Disambiguation Rules
- Multiple Fn-types in one request -> ASK which (or dispatch sequentially).
develop without target -> list 3 develop targets (sagemaker/databricks/local), WAIT.deploy without target -> list 4 deploy targets, WAIT.- Target alone, no verb -> deploy ref-only summary + soft-ask "did you mean develop?"
test <id> ambiguous (which target?) -> look up id in target registries first
(develop registries first if id looks like a Pipeline ARN).review ambiguous (artifact vs deploy
vs develop) -> presence of Pipeline ARN / Job run id → develop
presence of endpoint id → deploy
absence of any id → artifact (review-overall)- Multi-target deploy / develop -> dispatch sequentially. Don't run in parallel —
failures become confusing.
Guardrails — inference Fn authoring (apply to ALL 5 Fn-types)
FN-1 A NAME THAT DOES NOT RESOLVE MUST RAISE.
Every inference Fn looks names up: arms in the model output, columns in a
source frame, fields in a payload. The house style has been to substitute a
default — a membership filter that drops the name, `safe_get(row, name,
default)`, a `format_date` that falls back to `datetime.now()`. Each turns a
wrong name into a PLAUSIBLE VALUE with no error, so the defect ships looking
healthy and can sit in production for months.
Four instances found in one session (SMSR4, 260807):
PostFn 'progressFeedback' absent from 40 arms -> list shrank 3->2
-> `salience` served on 6,513/6,513 live requests
Src2InputFn 7 column names absent from every source frame -> dateOfBirth
became a constant, zipCode null, dates became now()
-> 371 of 1995 vocab slots blank, 18.6% of model input
repro check any-score-vs-any-score, different arms, 100x scale apart
-> could not fail, caught none of the above
Author with an explicit split: a DECLARED read raises, an OPTIONAL read
yields None. Name the missing entries in the exception message.
FN-2 FORK, NEVER EDIT A SHARED Fn. Count the manifests first:
find . -name manifest.json | xargs grep -l '"<FnType>": "<name>"'
Nine manifests shared the SMSR4 PostFn and nine shared its Src2InputFn. The
PostFn's list was still CORRECT for SMSR3, so an in-place fix would have
broken a working endpoint. Name the fork for what makes it different, dated:
`R4sms_10o40_ArmGreedy_v260807` follows `R3sms_9o20_ArmGreedy_v250922`.
Note the asymmetry: a fork is mandatory when the original is right for
someone else, and merely SAFER when the bug is wrong for everybody — in the
latter case still fork, then migrate the others deliberately.
FN-3 An Fn is inherited across ROUNDS. The vocabulary underneath it (arm set,
column names, payload schema) changes between rounds while the Fn does not.
Before reusing an Fn for a new round, diff the round's vocabulary against
every name the Fn hardcodes. This is the single highest-yield check in
Stage 6 and it is 10 lines of Python.
FN-4 VERIFY WITH A ROUND-TRIP GATE, and prove the gate bites first.
The endpoint must reproduce the model's OWN prediction for the packaged
examples — served arm, argmax, and every per-arm score. Run it against the
known-broken build BEFORE the fixed one; if it passes the broken build, the
gate is what is broken. See haipipe-task GATE-1 and the reference impls in
`-src2input`'s roundtrip section.
Specialist Return Contract
Every specialist emits a tail this orchestrator parses:
status: ok | blocked | failed
summary: 2-3 sentences on what was done
artifacts: [paths, endpoint ids, URLs, ARNs]
next: suggested next command
Files Owned by This Umbrella
ref/0-overview.md Stage 6 architecture + inference pipeline + YAML conventions
(read by all 5 per-Fn-type children for context)
ref/deploy-overview.md shared cross-target deploy ref (read by all 4 deploy specialists)
fn/fn-design.md SHARED design procedure — read by all 5 per-Fn-type children
when handling `design`. Each child supplies its own concepts.md.
These files are SHARED — children read them via ../haipipe-end/....
Each child also has its own scope-specific ref/concepts.md.
