Live values
Every value on this page is read out of the compiled @raybot/object-model package at build time.
None of it is transcribed.
Why this page exists
A documentation site that merely describes a type package will drift from it. The description is prose; the package is code; nothing connects them, so a renamed export leaves the prose quietly wrong.
This site imports the package instead. The ModelValue component holds a typed table of model
exports, so:
- Renaming or deleting an export breaks
npm run typecheck, which CI runs on every push. - Referencing an unknown key throws during static site generation, which fails the build.
Drift becomes a build error rather than slow rot. That is the entire justification for building the package rather than leaving it as loose source — see the build decision below.
Identity
| Field | Value |
|---|---|
| Agent id | 4de4ada9-ad61-4c22-a0d0-a0bd1c189f4e |
| Schema name | Default_Raybot_vyN1Rz |
| Environment id | Default-6b104499-c49f-45dc-b3a2-df95efd6eeb4 |
| Environment name | Cypherdyne |
| Model | Claude Sonnet 4.6 |
These come from RAYBOT.identity. See Identity for how the values were captured and
why most of them are immutable after the first save.
Observed limits
| Constant | Value | Where it was observed |
|---|---|---|
ICON_MAX_BYTES | 102400 bytes (100 KB) | A 512 px PNG at 195.8 KB was rejected; 256 px at 53.8 KB was accepted. |
SKILL_NAME_MAX_LENGTH | 64 | maxLength on skill-name-input. |
SKILL_DESCRIPTION_MAX_LENGTH | 1024 | maxLength on skill-description-input. |
MICROSOFT_IQ_MIN_SKU | basic | Free-tier knowledge bases never appear in the picker. |
SEARCH_API_VERSION | 2025-11-01-preview | The only API version exposing /knowledgeBases. |
EVAL_MAX_CONVERSATION_PAIRS | 6 | Import ceiling on the evaluation test set. |
EVAL_REFERENCE_MAX_LENGTH | 1000 | Reference-answer length ceiling. |
Each of these is a limit that was hit during the build, not a limit read from documentation. See Agent, Skills, Knowledge, and Evaluation for the surrounding context.
Counts
| Collection | Count |
|---|---|
| Workflow node types | 13 |
| Workflow trigger types | 4 |
| Coral areas | 8 |
| Runbook phases | 7 |
The workflows designer module the node types were captured from is
s01-workflow-designer/22.19.1. See Workflow for the per-node capture
pattern, and Coral surface for the area taxonomy.
The build decision
Three options were on the table for the package.
| Option | Verdict |
|---|---|
| Source-only | Rejected. Simplest to set up, but nothing stops the docs and the types from diverging. |
| Built and imported | Chosen. tsc emits dist/ with declarations; the site imports from it; drift fails the build. |
| Published to npm | Rejected. There are no external consumers, so a release process would have nothing on the other end of it. |
The build is wired so it cannot be skipped. The root prebuild and pretypecheck scripts each build
the package first, so npm run build and npm run typecheck are both self-sufficient from a clean
checkout — including in CI, which runs them in that order.
What this does not prove
Importing the package proves the site and the types agree. It does not prove either one matches the live product. That guarantee comes from a different mechanism: every constant traces to a captured screenshot, a recorded network request, or a DOM audit row, and the confidence model records how strongly each fact is supported.
A value can be perfectly consistent across the package, the schemas, and this page while still being stale relative to Coral, which ships continuously. The re-audit phase exists precisely because that happened — Monitor was renamed Analytics between the original build and the audit.