Seven shared components provide decision-making, data, workflow orchestration, identity, agent tools, runtime configuration, and user experience. Business domains plug into those components with their own models, rules, workflows, and screens. Investments is one application of the platform; its financial features are not assumed to exist in every domain.
Step-by-step guides to investments features. Planned workflows are labeled.
Open tutorial →Step-by-step guides to legal intake features. Planned workflows are labeled.
Open tutorial →Step-by-step guides to career features. Planned workflows are labeled.
Open tutorial →Sky, the experience, sits at the center, because every component ultimately surfaces here. The other six orbit it, joined by the paths that data and identity travel. Hover a node to trace its connections; select any one to go deep.
Select any component to open its deep dive →
Cambium supplies intelligence and outcome-driven learning. Timber supplies models, persistence, and service discovery. Grove orchestrates configured workflows. Canopy establishes trusted identity, and each serving boundary enforces its permissions. Acorn calls permitted tools; Sky renders the configured experience. The diagram groups responsibilities, not network order.
Each component is a deep dive of its own: its role, the capabilities inside it, the facts that matter, and how it connects to the rest. Shared engine documentation lives with its component. Business features and examples live with their domain. Local implementation and planned work are labeled separately from deployed behavior.
The seven components are the platform. Domains are what it does with them. A domain is a single installed package that registers into the platform’s shared registries, one entry point per layer: models and services in the substrate, routes in the engine, tools in the agent, and widgets in the experience. Adding a domain edits no core code. Removing it is a no-op. Investing was the first domain to move onto this system, legal intake is the second, and career transition is the third, each sharing none of the others’ code, and each a different phase of the same cycle.
OakQuant runs many organizations on one platform. Tenants can nest: an organization can hold workspaces, and workspaces can hold teams. Two things flow through that structure in opposite directions. Shared configuration is inherited and reused down the tree, so a tenant defines only what it changes. Client data stays isolated, visible only up a tenant’s own parent line. The result is broad reuse with hard tenant boundaries.
A set of shared defaults sits at the root. Each tenant stores only what it changes and inherits everything else. Customize one setting; the rest comes from the defaults. A new tenant is a few overrides, not a fork.
A tenant sees its own data plus the data its parents share. It never sees a sibling’s data, another tenant’s data, or its children’s. Leaf tenants are fully isolated. The shared root holds configuration only, never client data, so nothing leaks across tenants by default.
An explicit oversight role can see an entire branch downward, for the admins and compliance reviewers who need it. Ordinary members stay bound to their own scope.
A user’s tenant is resolved server-side and minted into the token. The gateway forwards it as a trusted header. Every read is scoped to the tenant’s visible set, and every write is stamped to its owner, so a forged value never reaches the data.
OakQuant runs several businesses on one platform: investing, legal aid, and career, each shipped as its own installable domain. A ring-fence keeps every organization to exactly the capabilities it is entitled to. It holds in more than one place, so a single mistake in any one layer cannot expose another domain’s screens, endpoints, data, or code.
The home page and menu are composed only from the capabilities your organization carries. A contribution from a domain you do not have is never placed. If nothing resolves, you get a clear not-set-up home and a minimal menu with home, account, and sign out. You never land on another domain’s screen, because that screen is never built for you.
The same capability is checked again at each domain’s own endpoints, by a default guard every domain route carries. A request for a capability your tenant lacks returns a not-found, even if a screen were somehow reached. Access is denied by default and granted only by an explicit capability, so the gate on the data does not depend on the gate on the UI.
A domain ships as a separate package that the core never imports. Install it and its capability appears across the platform; leave it out and none of it exists in the build. One domain’s logic, prompts, and data model stay inside that domain, so what powers legal aid is not present in an investing-only deployment.
Provider credentials and model settings come from Ranger, the platform's secrets and configuration service. Authorized services receive them at runtime. Credentials are managed centrally and should not be committed to source code.
A reference photo conditions AI-generated images only for the person who uploaded it, and only after they opt in. The database stores a storage key, never the image bytes, and the feature is offered to a flow only when the person has a photo on file. Your face is used for you, by your choice, and nowhere else.
The tenant scope on the data, the capability gate on the UI, and the capability guard on the API are independent and all fail closed. New screens and new endpoints inherit the guards without opt-in, so a capability that should stay private stays private even when someone forgets to think about it.
Models, workflows, pages, forms, and limits are data. New capability = new configuration, not a new service.
The cheapest correct tier wins; payloads are distilled before a prompt; every model call is metered.
Identity is issued and verified in a single place; services trust a verified, forwarded user.