API
Versioned operations through the public gateway when a hosted capability belongs in the runtime path.
Pramaan Capabilities · APIs and Builder Kit
Stop rebuilding
the same primitives.
Consume governed application capabilities through an API, SDK, MCP tool, embed, CLI, or agent skill—without reimplementing the baseline controls each time.
The product underneath
One capability. Generated for humans and agents.
A curated manifest and recipe produce the SDK, types, MCP surface, skill, docs, OpenAPI, fixtures, and examples. CI executes every example against a sandbox before a release can claim freshness.
Foundation implemented locallyFirst demand-pulled capability comes next
Builder Kit
Choose the integration surface, not a different product.
The same capability code and contract project into each surface. Channel differences are eligibility, configuration, assurance, support, and commercial terms.
SDK
Typed, generated client slices pinned to a capability contract and release policy.
MCP
Separate build-time and runtime tools with different keys, scopes, and effect boundaries.
CLI + skills
Activate a capability, seed fixtures, install agent guidance, and prove a passing sandbox example.
Embed
Hosted UI surfaces for flows that need a secure browser boundary and consistent safe defaults.
Mandatory baseline
Controls are underneath every capability.
A consumer cannot waive the platform baseline. Stronger assurance is added per capability without pretending the whole platform is universally “enterprise ready.”
- Tenant and application lineage
- Credential custody
- Authentication and authorization
- Idempotent mutation identity
- Operational audit and events
- Metering and spend controls
- Jurisdiction and processing authority
- Declared postconditions
Where Pramaan sits
Control plane by default. Runtime path when selected.
Pramaan does not need to proxy every request. Delivery and maintenance can remain out of band, while hosted capabilities use the gateway and kernel for governed runtime effects.
Delivery control planeBuild-time
Human→Loop→Agent worker→Repo + CI/CD
Pramaan coordinates change. It does not intercept every application request.
Hosted capability pathRuntime · when selected
Customer app→Gateway→Kernel→Provider
Hosted capabilities use Pramaan's governed runtime and credential custody.
Direct provider pathRuntime · default where appropriate
Customer app→Installed adapter→Provider
Loop monitors the integration and prepares a tested change when the contract moves.
The adapter truth
“Self-maintaining” does not mean “no redeploy.”
Whether an implementation can change invisibly depends on where the adapter runs. Pramaan makes that boundary explicit instead of turning every upgrade into the same marketing claim.
| Mode | Request path | When a dependency breaks | Customer deploy |
|---|---|---|---|
| Hosted capability | App → Pramaan → provider | Pramaan can replace an internal provider adapter without a customer redeploy when the public capability contract is unchanged. | Usually no |
| Generated SDK | App → Pramaan API | A server-side adapter may change invisibly. A client contract change remains versioned; compatible SDK updates follow the release policy. | Only for client change |
| Installed adapter | App → provider | A breaking provider change requires code. Loop prepares and tests the smallest PR; the customer approves and deploys it. | Yes |
Integrate deliberately