CTK Education Layer: from runtime signals to trusted operational decisions.

1. Start Here

Core idea, category boundary, and first outcomes.

2. How CTK Thinks

Central reasoning lifecycle from signals to replayable operational memory.

3. Mental Model

How CTK reasons from evidence to decisions.

4. Understanding Decisions

Why CTK blocked, allowed, or downgraded a decision.

5. Reading the Desktop

How to read Timeline, Signals, Incidents, and Safety Gate states.

6. Replay & Incident Analysis

Deterministic replay flows and confidence transitions.

7. Runtime Modes & Connectors

Observation scope for local, Docker, cloud, and cluster runtimes.

8. Trust & Safety

Local-first boundaries, access model, and safety policy.

9. Walkthroughs

Operational stories with actionable operator outcomes.

10. Terminology

Semantic foundation for replayable operational decisions.

11. Incident Stories

Case studies with contradiction and outcome.

What is Core Trail Kit?

Core Trail Kit is deterministic operational intelligence: it turns conflicting runtime signals into replayable, confidence-scored decisions.

• • One shared operational truth per evidence state
• • Clear reason for every allowed or blocked action
• • Replayable decision lineage for postmortems and handoffs

CTK in 5 minutes

Attach workspace context, detect services, build topology, generate timeline moments, then replay how decisions were adjudicated.

• • You see why a contradiction exists
• • You see confidence evolution over time
• • You see whether Safety Gate should block action

From signals to trusted decisions

Most tools show logs, metrics, or traces separately. CTK connects them into one reasoning chain and emits operator-safe conclusions.

• • Signals are not treated as isolated alerts
• • Conflicts are modeled as contradictions
• • Actions are risk-aware by default

What CTK is NOT

CTK is not a black-box AI incident bot, not an ingest-priced observability clone, and not an autonomous production mutation agent.

• • No hidden action logic
• • No blind auto-remediation
• • Evidence before recommendation

Operational Truth

Definition: The current state CTK can defend with explicit evidence right now.

Why this exists: Teams need one trusted conclusion, not competing dashboards.

Traditional gap: Signal surfaces disagree but tooling rarely commits to one narrative.

CTK handles it: CTK adjudicates final posture from evidence quality, contradictions, and confidence.

Scenario: Health check is green while queue lag and runtime latency degrade.

Desktop view: Appears as adjudicated state in Timeline, Replay Chain, and Recommendations.

Related: Evidence Ledger • Truth Adjudication • Confidence Evolution

Evidence Ledger

Definition: Structured record of all observed runtime evidence used in decisions.

Why this exists: Operators must audit why CTK concluded something.

Traditional gap: Most incident notes lose source quality and ordering.

CTK handles it: Each decision points to evidence records with freshness and source context.

Scenario: A blocked restart links to stale probe + fresh latency evidence.

Desktop view: Visible as supporting evidence under Timeline moments and replay steps.

Related: Operational Memory • Deterministic Replay

Contradiction Detection

Definition: Modeling of conflicting signals that cannot be trusted equally.

Why this exists: Green probes can hide real runtime degradation.

Traditional gap: Conflicting telemetry is treated as noise instead of risk.

CTK handles it: CTK creates contradiction objects that reduce confidence and influence gates.

Scenario: Runtime throughput drops while readiness remains healthy.

Desktop view: Shown in Analyze surfaces, timeline chains, and consistency findings.

Related: Confidence Evolution • Safety Gate

Confidence Evolution

Definition: Continuous trust score changes based on evidence quality and conflict pressure.

Why this exists: Incident risk changes faster than static severity labels.

Traditional gap: Most tools show severity but not trust drift.

CTK handles it: Confidence rises with corroboration, drops with stale or conflicting evidence.

Scenario: Confidence falls 0.82 -> 0.41 while contradiction persists.

Desktop view: Displayed as confidence chips, trend transitions, and gate inputs.

Related: Evidence Ledger • Safety Gate • Truth Adjudication

Truth Adjudication

Definition: Deterministic resolution step that emits final operational posture.

Why this exists: Teams need action-ready conclusions during pressure.

Traditional gap: Operators manually arbitrate competing signals with no traceable logic.

CTK handles it: CTK evaluates evidence + contradiction + confidence and commits one state.

Scenario: Service marked degraded despite healthy endpoint due to runtime conflict.

Desktop view: Appears in Replay chain final nodes and recommendation context.

Related: Operational Truth • Deterministic Replay

Deterministic Replay

Definition: Re-openable chain: evidence -> contradiction -> adjudication -> decision.

Why this exists: Postmortems must explain exactly why actions happened.

Traditional gap: Chat + screenshots cannot reconstruct causal order.

CTK handles it: CTK stores stable replay chains for every key timeline decision.

Scenario: Blocked action later becomes allowed after confidence recovery.

Desktop view: Timeline card opens reasoning modal with full chain.

Related: Operational Memory • Decision Trust Layer

Safety Gate

Definition: Policy layer that blocks unsafe actions when trust is weak.

Why this exists: Fast actions under weak evidence can worsen incidents.

Traditional gap: Recommendation lists rarely encode action risk.

CTK handles it: Gate checks confidence, freshness, and contradiction state before allowing action.

Scenario: Unsafe restart blocked until stale topology evidence is refreshed.

Desktop view: Shown as allowed/review/blocked state with reason in replay and recommendations.

Related: Confidence Evolution • Contradiction Detection

Operational Memory

Definition: Shared replayable incident and decision history across shifts.

Why this exists: Without memory, every shift re-discovers root causes.

Traditional gap: Context reset at handoff causes repeated mistakes.

CTK handles it: Timeline moments persist decisions, evidence states, and rationale.

Scenario: Night shift replays day shift contradiction before acting.

Desktop view: Timeline, incidents, and replay panels show memory continuity.

Related: Deterministic Replay • Evidence Ledger

Topology Delta

Definition: Confidence-aware change tracking of service relationships over time.

Why this exists: Runtime drift often starts in dependency changes.

Traditional gap: Many tools show static topology snapshots with weak delta meaning.

CTK handles it: CTK highlights changed/removed/added entities and confidence movement.

Scenario: Consumer dependency edge disappears, contradiction pressure rises.

Desktop view: Topology Tree and Delta Details expose relation-level confidence shifts.

Related: Relationship Confidence • Contradiction Detection

Decision Trust Layer

Definition: Combined model of evidence quality, contradiction pressure, and action safety.

Why this exists: Operators need to know if a recommendation is safe right now.

Traditional gap: Action advice is often binary and context-free.

CTK handles it: CTK scores trust dynamically and surfaces risk posture before action.

Scenario: Recommendation visible but blocked because confidence remains low.

Desktop view: Trust badges, confidence labels, and gate outcomes in Analyze + Timeline.

Related: Safety Gate • Confidence Evolution • Operational Truth

CTK is not

• • Another metrics dashboard
• • A black-box AI incident bot
• • Autonomous production mutation
• • An ingest-priced telemetry SaaS clone
• • Generic monitoring software
• • AI magic without evidence lineage

CTK focuses on

• • Deterministic reasoning
• • Replayable evidence
• • Confidence-aware operations
• • Contradiction visibility
• • Safety-gated actions
• • Shared operational memory

Why did CTK block a restart?

Scenario: Health checks were green, but queue latency and throughput degraded under load.

Contradiction: Service appears healthy by probe but behaves degraded in runtime behavior signals.

Confidence: 0.82 -> 0.41

Decision: Safety Gate blocked restart recommendation.

Operator meaning: Do not act on health checks alone; refresh evidence and inspect replay before disruptive actions.

Why did confidence drop?

Scenario: Incident pressure rose while one evidence source stopped refreshing.

Contradiction: Signal freshness and behavior quality diverged, reducing trust in current posture.

Confidence: 0.74 -> 0.58

Decision: Recommendations moved from allowed to review state.

Operator meaning: Confidence drop means slower, safer action until trust is restored.

Why did CTK create a contradiction?

Scenario: Service marked healthy while incident pressure and latency trend escalated.

Contradiction: Status signals and behavior signals disagree materially.

Confidence: High -> Medium

Decision: Contradiction node created and propagated into recommendations.

Operator meaning: CTK prevents false certainty by modeling conflict directly.

Why was a recommendation allowed?

Scenario: Lag pressure reduced after fresh corroborating evidence arrived.

Contradiction: Prior contradiction cleared with aligned fresh evidence.

Confidence: 0.63 -> 0.84

Decision: Safety Gate allowed lower-risk remediation action.

Operator meaning: Allowed does not mean automatic; it means trust threshold is now satisfied.

Why did topology confidence change?

Scenario: A dependency edge disappeared during deploy and reappeared later.

Contradiction: Observed topology and expected topology were temporarily inconsistent.

Confidence: 0.77 -> 0.52 -> 0.73

Decision: CTK downgraded relation trust until evidence stabilized.

Operator meaning: Treat topology confidence shifts as runtime risk indicators, not UI noise.

Why is evidence marked stale?

Scenario: A mapped provider log stream stopped sending updates.

Contradiction: Stable status claims continue while key diagnostic source is stale.

Confidence: 0.69 -> 0.49

Decision: CTK added freshness penalty and moved actions toward review/blocked.

Operator meaning: Restore source freshness before trusting high-impact recommendations.

Why is service configured but inactive?

Scenario: Service exists in workspace config but has no active observation evidence.

Contradiction: Configured intent and observed runtime activity are misaligned.

Confidence: 0.61 -> 0.43

Decision: CTK raises consistency finding and gates risky actions.

Operator meaning: Confirm runtime is actually running before treating config as truth.

How to read Timeline

What you see: Moments, primary event, supporting evidence, confidence state, and action branch.

Read order: Start from newest primary event -> contradiction notes -> confidence -> action outcome.

What matters first: First focus on blocked/review decisions; they carry highest operational risk.

Ignore unless deep debugging: Ignore deep supporting nodes unless you are debugging decision quality.

How to read Replay Chains

What you see: Deterministic causal chain from evidence ingestion to final operational decision.

Read order: Evidence -> Contradiction -> Adjudication -> Safety Gate -> Final.

What matters first: First verify contradiction and confidence transitions before reviewing recommendations.

Ignore unless deep debugging: Ignore low-impact supporting events during rapid incident response.

How to read Topology Tree

What you see: Service/entity relationships with confidence and delta direction.

Read order: Inspect changed/removed edges first, then stable edges.

What matters first: First focus on edges touching the impacted runtime path.

Ignore unless deep debugging: Ignore low-confidence inferred edges unless they intersect incident path.

How to read Relationship Inspector

What you see: Edge-level confidence trend, relation evidence, and historical updates.

Read order: Check relation status -> confidence movement -> evidence freshness.

What matters first: First validate whether relation drift maps to runtime symptom.

Ignore unless deep debugging: Ignore unchanged relation metadata during active outage triage.

How to read Recommendations

What you see: Action suggestions with confidence, contradiction context, and safety state.

Read order: Read risk context before action text.

What matters first: First focus on blocked/high-risk recommendations to understand guardrails.

Ignore unless deep debugging: Ignore lower-priority suggestions during critical incident containment.

How to read Incidents

What you see: Pressure-classified runtime anomalies tied to affected services.

Read order: Severity + confidence + contradiction posture, then detailed evidence.

What matters first: First isolate incidents with low confidence and high pressure.

Ignore unless deep debugging: Ignore stale/resolved incident cards in live response windows.

How to read Signals

What you see: Coverage quality, freshness posture, missing diagnostics, and signal class health.

Read order: Availability -> quality -> freshness -> critical missing signal.

What matters first: First remediate missing high-impact diagnostics (logs/health/runtime gaps).

Ignore unless deep debugging: Ignore cosmetic low-noise metrics when contradiction is active.

How to read Safety Gate badges

What you see: Allowed / Review / Blocked action readiness with reason metadata.

Read order: Badge state -> reason -> confidence trend -> required operator step.

What matters first: First resolve why block/review occurred; do not bypass.

Ignore unless deep debugging: Ignore optimistic action text when badge state remains blocked.

How to read confidence labels

What you see: Trust score labels mapped to evolving evidence quality and conflict pressure.

Read order: Current confidence -> change direction -> contradiction + freshness contributors.

What matters first: First inspect recent confidence drops before taking disruptive actions.

Ignore unless deep debugging: Ignore absolute confidence number without transition context.

Already Running mode

What CTK observes: Existing runtime process/service signals without re-launching workloads.

What CTK does not modify: Does not auto-restart, reconfigure, or mutate running services.

Required permissions: Local runtime read access for mapped services and evidence sources.

Data flow: Runtime signals -> Evidence Ledger -> Contradiction + Confidence -> Timeline/Replay.

Security boundary: Workspace-scoped observation only.

Typical use case: Attach CTK to already running environments for immediate reasoning.

Limitations: Quality depends on available runtime signal mappings.

Start with Toolkit mode

What CTK observes: Processes/services launched through Toolkit startup flow.

What CTK does not modify: Not a CI/CD replacement or long-running process orchestrator.

Required permissions: Local execution rights for configured workspace startup commands.

Data flow: Toolkit launch context + runtime signals feed deterministic timeline.

Security boundary: Bound to local workspace session context.

Typical use case: Controlled local boot with immediate evidence baseline.

Limitations: Covers workloads started via Toolkit flow only.

Docker connector

What CTK observes: Container health, status, logs, and mapped service runtime behavior.

What CTK does not modify: Does not become your Docker orchestrator or deployment manager.

Required permissions: Docker context read access scoped to mapped workloads.

Data flow: Container signals are normalized into service-level evidence lineage.

Security boundary: No automatic host-wide crawling outside mapped services.

Typical use case: Containerized local/runtime systems requiring contradiction-aware reasoning.

Limitations: Coverage follows explicit service mapping quality.

Kubernetes connector

What CTK observes: Mapped cluster service/pod signals, logs, and relationship drift evidence.

What CTK does not modify: Does not replace kubectl/Helm or cluster operations.

Required permissions: Scoped kube context permissions (namespace/selector aware).

Data flow: Cluster runtime evidence is converted into workspace decision lineage.

Security boundary: Only mapped cluster scope is observed.

Typical use case: Service contradictions across k8s runtime behavior and probes.

Limitations: Requires explicit mapping for meaningful confidence.

AWS connector

What CTK observes: Mapped cloud runtime evidence (health endpoints, logs, runtime status).

What CTK does not modify: No infrastructure provisioning or mutation by default.

Required permissions: Provider-profile scoped access to mapped resources.

Data flow: AWS evidence enters local CTK reasoning chain via connector mappings.

Security boundary: Workspace service mappings constrain account visibility.

Typical use case: Local-connected reasoning for cloud-hosted services.

Limitations: Coverage depends on configured resource mappings and freshness.

Azure connector

What CTK observes: Mapped Azure runtime diagnostics and service-level health evidence.

What CTK does not modify: Does not act as deployment or infra control layer.

Required permissions: Scoped provider profile access for mapped resources.

Data flow: Azure signals are transformed into deterministic confidence-aware decisions.

Security boundary: No tenant-wide observation by default.

Typical use case: Cross-service contradiction and drift analysis in Azure-hosted runtimes.

Limitations: Requires explicit mapping for each critical service.

GCP connector

What CTK observes: Mapped GCP runtime logs/status/health evidence.

What CTK does not modify: Not a cloud operations replacement.

Required permissions: Scoped project/resource access via mapping profile.

Data flow: GCP evidence -> local CTK evidence ledger -> adjudicated decisions.

Security boundary: Only configured scope participates in analysis.

Typical use case: Operational truth for multi-service GCP environments.

Limitations: Unmapped services remain outside confidence model.

SSH / remote runtime model

What CTK observes: Mapped host/process-level runtime evidence where connector is enabled.

What CTK does not modify: Not a remote automation agent.

Required permissions: Host access scoped to explicit connection mappings.

Data flow: Remote runtime evidence is streamed into local-first reasoning session.

Security boundary: Connection and service mapping define strict observation boundary.

Typical use case: Legacy host-level services not exposed through orchestrators.

Limitations: Coverage varies by host instrumentation and mapping depth.

Local-first architecture

CTK reasoning is anchored in your local session context before cloud scale concerns.

No cloud agent required

CTK does not require always-on external mutation agents to produce decisions.

Workspace-scoped intelligence

Evidence and decisions are scoped to active workspace mappings, not global blind crawl.

What data stays local

Connector configuration, local execution context, and session-level reasoning remain local-first.

What data may sync

Configured metadata and selected organizational state can sync for shared memory workflows.

Provider access model

Provider profiles and mappings define exact resource boundaries for observation.

Evidence retention model

Timeline moments and replay chains preserve auditability of key operational decisions.

Read-only vs action-capable behavior

CTK observes by default; action pathways are explicit, confidence-aware, and safety-gated.