Found while writing the www.objectos.ai how-to on migrating a legacy internal system (objectstack-ai/www.objectos.ai#91, PR objectstack-ai/www.objectos.ai#147). Filed unassigned. Not fixed there: that card's file surface is one new blog directory in a different repository.
content/docs/configure/data-sources.mdx carries a section titled "Roadmap: in-product External Datasource Federation" which tells the reader the capability does not exist yet:
A richer, turn-key federation experience is in active design under ADR-0015 (status: Proposed). Planned, not yet shipped:
Measured on objectstack origin/main @ 7cbe705b, every one of the four "planned, not yet shipped" bullets is shipped:
| Doc bullet |
State on origin/main |
"A schemaMode (managed / external / validate-only)" |
SchemaModeSchema in packages/spec/src/data/datasource.zod.ts |
"An external binding sub-record on objects" |
ObjectExternalBindingSchema in packages/spec/src/data/object.zod.ts, wired as external on ObjectSchema |
"An os datasource introspect / validate CLI" |
packages/cli/src/commands/datasource/{introspect,validate,list-tables}.ts |
| "Boot-time and write-time safety gates … plus a Studio wizard" |
ADR-0015 §5.2 external-validation-plugin; the double opt-in write gate; ADR-0062 R7 records the runtime "Sync objects" wizard as shipped |
ADR-0015's own status line now reads "Accepted — backend/REST/CLI implemented; Studio UI + extra dialect drivers pending", and ADR-0062 (Accepted 2026-06-22) supersedes its runtime half and lists R1, R4, R5a-d, R6, R7, R9, R10 as shipped. The monorepo ships a full user-facing guide for the feature at content/docs/data-modeling/external-datasources.mdx, whose headline is the opposite of this page's: "declare an external datasource and it is visible, auto-connected, validated at boot, and queryable — with no application code."
A second, separate claim on the same page
Line 88 states:
There is no defineDatasource() helper. A datasource is just a Datasource object you place in the datasources array
That helper is exported: packages/spec/src/data/datasource.zod.ts:816 declares export function defineDatasource(config: z.input<typeof DatasourceSchema>): DatasourceParsed, re-exported through packages/spec/src/data/index.ts. The monorepo's own federation guide uses defineDatasource in its first code block. The plain-object form the page describes still works, so this is a wrong denial rather than a broken example — but an author who reads it will hand-write the longer form and will not find the helper the sibling docs use.
Why it is worth a card
These two claims fail in the direction that costs the most: they tell a reader a capability is absent. Someone evaluating whether ObjectOS can sit on their existing production database reads this page, concludes the safety gates they need are a roadmap item, and leaves. The feature they wanted has been shipped and documented for months, one repository over.
The staleness is also self-concealing — nothing on this page is broken, so no gate fires and no reader reports it. It is only visible to someone who happens to read both this page and the monorepo docs for the same surface, which is how it surfaced here.
Shape of the fix
Not prescribed, because there is a scope question worth deciding deliberately: whether this page should describe the shipped federation surface itself, or link to the monorepo's data-modeling/external-datasources guide and keep only the connect-and-model overview it does well. The second is smaller and avoids two pages drifting apart again. Either way the "Roadmap" heading and the defineDatasource denial go.
Re-check
git -C objectstack show origin/main:docs/adr/0015-external-datasource-federation.md | head -3
git -C objectstack grep -n 'export function defineDatasource' origin/main -- packages/spec/src
git show origin/main:content/docs/configure/data-sources.mdx | sed -n '85,95p;230,250p'
Related: the sibling claim in the extend-existing-systems-with-ai blog post is filed separately in the www.objectos.ai tracker.
Generated by Claude Code
Found while writing the www.objectos.ai how-to on migrating a legacy internal system (objectstack-ai/www.objectos.ai#91, PR objectstack-ai/www.objectos.ai#147). Filed unassigned. Not fixed there: that card's file surface is one new blog directory in a different repository.
content/docs/configure/data-sources.mdxcarries a section titled "Roadmap: in-product External Datasource Federation" which tells the reader the capability does not exist yet:Measured on
objectstackorigin/main@7cbe705b, every one of the four "planned, not yet shipped" bullets is shipped:origin/mainschemaMode(managed/external/validate-only)"SchemaModeSchemainpackages/spec/src/data/datasource.zod.tsexternalbinding sub-record on objects"ObjectExternalBindingSchemainpackages/spec/src/data/object.zod.ts, wired asexternalonObjectSchemaos datasource introspect/validateCLI"packages/cli/src/commands/datasource/{introspect,validate,list-tables}.tsexternal-validation-plugin; the double opt-in write gate; ADR-0062 R7 records the runtime "Sync objects" wizard as shippedADR-0015's own status line now reads "Accepted — backend/REST/CLI implemented; Studio UI + extra dialect drivers pending", and ADR-0062 (Accepted 2026-06-22) supersedes its runtime half and lists R1, R4, R5a-d, R6, R7, R9, R10 as shipped. The monorepo ships a full user-facing guide for the feature at
content/docs/data-modeling/external-datasources.mdx, whose headline is the opposite of this page's: "declare an external datasource and it is visible, auto-connected, validated at boot, and queryable — with no application code."A second, separate claim on the same page
Line 88 states:
That helper is exported:
packages/spec/src/data/datasource.zod.ts:816declaresexport function defineDatasource(config: z.input<typeof DatasourceSchema>): DatasourceParsed, re-exported throughpackages/spec/src/data/index.ts. The monorepo's own federation guide usesdefineDatasourcein its first code block. The plain-object form the page describes still works, so this is a wrong denial rather than a broken example — but an author who reads it will hand-write the longer form and will not find the helper the sibling docs use.Why it is worth a card
These two claims fail in the direction that costs the most: they tell a reader a capability is absent. Someone evaluating whether ObjectOS can sit on their existing production database reads this page, concludes the safety gates they need are a roadmap item, and leaves. The feature they wanted has been shipped and documented for months, one repository over.
The staleness is also self-concealing — nothing on this page is broken, so no gate fires and no reader reports it. It is only visible to someone who happens to read both this page and the monorepo docs for the same surface, which is how it surfaced here.
Shape of the fix
Not prescribed, because there is a scope question worth deciding deliberately: whether this page should describe the shipped federation surface itself, or link to the monorepo's
data-modeling/external-datasourcesguide and keep only the connect-and-model overview it does well. The second is smaller and avoids two pages drifting apart again. Either way the "Roadmap" heading and thedefineDatasourcedenial go.Re-check
Related: the sibling claim in the
extend-existing-systems-with-aiblog post is filed separately in the www.objectos.ai tracker.Generated by Claude Code