Understand trust model
Review deterministic allow/block logic before interpreting runtime status.
View Trust ModelOperational Doctrine Library
Start Here: use the same decision language before you touch runtime access.
What happened: teams used different words for the same risk, so approvals and escalation paths drifted. CTL docs map every claim to policy, evidence, and decision outcomes so both operators and architects can act from the same source.
Follow this order to reduce rework and trust confusion
Validate runtime contracts
Confirm declared scope, capability gates, and signer requirements.
Read Runtime ContractsRequest launcher access
Submit access after trust and contract review to avoid blocked requests.
Request Launcher AccessHow CTL Thinks
Policy-first execution flow with human consequences
Define contract scope
What happened: scope is declared (platform-native vs portfolio-only) before any trust claim is accepted.
Resolve identity & entitlement
Human consequence addressed: fewer escalations from unclear permissions. Capability is computed from signed policy + license state.
Gate signed artifacts
Decision outcome: release is blocked when artifact provenance fails, allowed when signer and gate checks pass.
Emit replayable audits
Operational outcome: each allow/deny event can be replayed during incident review and governance audits.
Deterministic control-plane with explicit evidence
- What happened: identity and entitlement are resolved by declared policy, not local guesswork.
- Decision outcome: signed artifact and release gates determine allow/block before runtime exposure.
- Operational outcome: decisions remain auditable and replayable under on-call pressure.
Boundaries that prevent trust confusion
- No black-box approval language without policy traceability.
- No unrestricted local trust path around capability gates.
- No arbitrary launcher shell executing unsigned runtime paths.
Start Routes
Choose your entry path
Different responsibilities need different first steps, but the same trust model. Choose your route and follow it in order.
Operator path: reduce ticket loops first
Junior action: start with trust-state checks, then run capability-gate validation before escalation. Architect rationale: standardized operator flow lowers variance in incident handling.
/docs/start-routes/operator-runtime
Platform owner path: control scale through contracts
Junior action: verify contract scope and gate thresholds before rollout changes. Architect rationale: explicit contracts prevent trust sprawl across expanding product lines.
/docs/start-routes/platform-owner
Security reviewer path: challenge decisions with evidence
Junior action: inspect policy input, signer chain, and final decision log together. Architect rationale: replay-grade evidence keeps compliance and safety reviews defensible.
/docs/start-routes/security-reviewer
Docs Index
Canonical Entry Tracks
Every entry below answers the same chain: operational state, consequence, explicit evidence, decision outcome, and operational improvement.
Boundary brief before any runtime assumption
What happened: ownership and integration were mixed. CTL makes CTK platform-native scope and portfolio-only boundaries explicit before execution.
/docs/start-here/overview
Identity and entitlement decision model
Human consequence: fewer unclear permission escalations. Shows how actor context turns into allow/block outcomes with policy evidence.
/docs/platform-concepts/runtime-model
Trust-state lifecycle and denial reasons
What CTL made explicit: denial cause, policy version, and signer context. Operational outcome: disputes can be replayed, not debated.
/docs/trust-safety/decision-lifecycle
Runtime contract requirements for CTL-native scope
Decision outcome: integration is allowed only when scope declaration and capability obligations are complete and verifiable.
/docs/runtime-contracts/scope-declaration
Release gate rules with evidence thresholds
Human consequence addressed: fewer late rollbacks. Explains when release is blocked, when allowed, and which evidence justifies each state.
/docs/governance-release/gate-policy
Policy IDs, event schema, and replay catalog
Architect-facing rationale: shared schema keeps trust analytics scalable and consistent across product and audit surfaces.
/docs/reference/policy-catalog
Next Action
Move from reading to controlled execution
Junior action: complete Start Here and Runtime Contracts, then request launcher access. Architect rationale: this sequence preserves trust consistency as usage and team count grow.