Start with the system that actually runs.
Veklom documentation follows the same rule as the runtime: no synthetic success paths. Begin with identity, move through bounded authority, execute through the real backend, and inspect the evidence that remains.
Enter Capability OS
Sign in through Identity and open your workspace. Login establishes identity; it does not grant execution authority by itself.
Run live Activation
Discover a capability from Authority, request a bounded lease, prove a real denial, execute the allowed operation, then inspect persisted evidence.
Inspect runtime truth
Observe Execution, Identity, Authority, Connections and Evidence from the public proof and machine surfaces without synthetic health state.
Integrate machines
Use machine-readable discovery surfaces and VLink/MCP connection primitives without treating connection identity as execution authority.
Know which plane owns which responsibility.
The architecture is intentionally separated. A connection plane should not mint authority. A recovery plane should not become root automation. A health endpoint should not become consequence proof.
Raw surfaces are part of the product.
Claims, conformance, evidence indexes, OpenAPI, MCP manifests and the live runtime probe are exposed as machine-oriented surfaces so automated systems do not need to scrape a marketing page to understand Veklom.
If a guide cannot prove it, it should not say it.
Deployment details, legal alignment, live service state and consequence evidence are all scoped independently. Documentation is not allowed to promote an intended architecture into a verified runtime claim.
Read conformance →