Skip to main content
TX
TENTEX Systems • Decisions • Reliability
LEARN

Tentex glossary

Plain-English definitions for the terms you now see across Run Specs, Studio, Console, and the pack system. No vague SaaS language. Just what the term means and why it matters.

TERMS
Run Spec Run Specs
The execution blueprint behind a run. It defines the system, outcome, channel, audience, thresholds, and next-step logic.
Expand
Why it matters
The Run Spec removes ambiguity before work starts. It turns a vague idea into an executable test.
Where you'll see it
Run Specs page, Studio inputs, and Console run context.
Studio Studio
The generation and execution layer where you build the working output for a run.
Expand
Why it matters
Studio turns the Run Spec into usable execution assets instead of loose ideas.
Where you'll see it
Studio page and pack-specific execution systems.
Console Console
The operating layer where signals are logged, evidence is reviewed, and decisions are made.
Expand
Why it matters
Console is where execution becomes measurable. It is the decision surface for Go, Iterate, or Kill.
Where you'll see it
Console page and operator layer.
Decision Engine Console
The rules layer inside Console that interprets evidence against thresholds.
Expand
Why it matters
It keeps decisions tied to evidence rather than emotion or guesswork.
Where you'll see it
Console decision panel and Next Action surface.
Thresholds Signal + Validation
The criteria that determine whether a run advances, tightens, or stops.
Expand
Why it matters
Thresholds make the run measurable. They tell you what counts as enough signal.
Where you'll see it
Run Specs, Console, and decision logic panels.
Go / Iterate / Kill Signal + Validation
The three core run outcomes: advance, tighten the test, or stop the run.
Expand
Why it matters
This is the main decision system in Tentex. It keeps execution moving and prevents overbuilding.
Where you'll see it
Console decision state, Run Specs, and pack execution loops.
Promotion Flow Console
The step that advances a validated run into the next pack or execution layer.
Expand
Why it matters
A successful run should move forward, not sit idle. Promotion turns validated learning into the next working system.
Where you'll see it
Console promotion panel and run timeline.
Blueprint Studio
A preview of the system structure before full execution access is unlocked.
Expand
Why it matters
It shows the shape of the system and helps the user understand what the full run produces.
Where you'll see it
Studio preview mode and blueprint panels.
Preview Mode Studio
A limited view where the user can inspect the blueprint and execution shape before purchase or unlock.
Expand
Why it matters
It lets users understand the system without exposing the full locked output.
Where you'll see it
Studio locked systems and pack previews.
Primary Output Studio
The main generated execution asset for the selected system and outcome.
Expand
Why it matters
This is the working asset the user actually uses to run the system.
Where you'll see it
Studio output panel.
Run Plan Studio
The practical execution sequence for using the generated output in the real world.
Expand
Why it matters
The run plan turns output into action. It tells the user what to do next.
Where you'll see it
Studio supporting outputs and execution systems.
Signal Signal + Validation
Evidence from reality — replies, bookings, sales, objections, or no-signal.
Expand
Why it matters
Signal prevents overbuilding. It shows what is actually happening in the run.
Where you'll see it
Console logging, Signal Sprint, and Money Pack.
Evidence Console
The logged summary of what happened during a run.
Expand
Why it matters
Evidence creates an execution trail. It keeps the run grounded in what really occurred.
Where you'll see it
Console signal logging and decision memory.
Timeline Console
The chronological trail of signals, decisions, and lifecycle events for a run.
Expand
Why it matters
The timeline explains how the run reached its current state.
Where you'll see it
Console timeline column.
Decision Memory Console
The preserved record of prior Go, Iterate, Kill, and promotion states.
Expand
Why it matters
Decision memory stops the system from losing important learning between runs.
Where you'll see it
Console memory section.
Learnings carried forward Console
The key evidence that moves with a run when it advances to the next system layer.
Expand
Why it matters
Validated signal should compound. Carrying learnings forward makes the next run stronger.
Where you'll see it
Console promotion flow and run advanced events.
System Systems
A repeatable way to get an outcome. Think: steps + inputs + outputs, not vibes.
Expand
Why it matters
Systems make results more predictable and improve over time.
Where you'll see it
Every pack, especially Signal Sprint and Starter Bundle.
Workflow Systems
A specific system you run for one job, such as creating a micro-offer or collecting social proof.
Expand
Why it matters
Workflows turn vague goals into executable actions.
Where you'll see it
Studio system picker and pack structures.
Run Studio
One execution pass of a system.
Expand
Why it matters
Running creates signal. Planning alone does not.
Where you'll see it
Studio execution output and Console.
Prompt Studio
The structured instruction generated for the selected system and outcome.
Expand
Why it matters
A good prompt is not inspiration. It is an operator-grade input that creates a usable output.
Where you'll see it
Studio generated prompt panel.
Outcome Studio
What the system is supposed to produce.
Expand
Why it matters
You do not use AI just to generate text. You generate a concrete outcome.
Where you'll see it
Studio outcome selector and Run Spec.
Artifact Systems
A tangible output you can use, ship, or track.
Expand
Why it matters
Artifacts prove the system was actually run and make the result reusable.
Where you'll see it
Starter Bundle, Money Pack, and Studio outputs.
Micro-offer Offers
A small, tightly scoped offer with one clear outcome.
Expand
Why it matters
Micro-offers are fast to ship and fast to validate.
Where you'll see it
Starter Bundle and Money Pack systems.
Offer Offers
A clear promise + deliverable + price + timeframe.
Expand
Why it matters
Offers turn interest into measurable action.
Where you'll see it
Starter Bundle and Money Pack.
One-Pager Offers
A single-scroll page that explains the offer, proof, price, and CTA.
Expand
Why it matters
It is fast to build, fast to test, and easy to improve.
Where you'll see it
Starter Bundle and Money Pack outputs.
CTA Offers
The next action you ask for — reply, book, buy, or download.
Expand
Why it matters
A vague CTA kills signal because the next step is unclear.
Where you'll see it
One-pagers, DMs, emails, and checkout steps.
SOP Automation
A step-by-step operating procedure for doing the work reliably.
Expand
Why it matters
SOPs make delivery consistent and easier to automate or delegate.
Where you'll see it
Automation Vault.
Automation Automation
A workflow that runs with little or no manual effort once the manual system is proven.
Expand
Why it matters
Automation removes drag, but only after the underlying system works.
Where you'll see it
Automation Vault.
Observability Automation
Knowing when a system breaks, why, and what needs to happen next.
Expand
Why it matters
Without observability, automations fail silently.
Where you'll see it
Automation Vault blueprints.
Logging Tracking + Metrics
Recording inputs, outputs, timestamps, and status.
Expand
Why it matters
Logs make debugging and improvement possible.
Where you'll see it
Automation Vault, trackers, and Console evidence.
Metric Tracking + Metrics
A number that proves progress, like reply rate, booking rate, or conversion.
Expand
Why it matters
Metrics turn decisions into math.
Where you'll see it
Money Pack, Console, and Automation Vault.
Scorecard Tracking + Metrics
A simple table where signals are recorded and reviewed.
Expand
Why it matters
A scorecard converts activity into evidence and decisions.
Where you'll see it
Signal Sprint, Money Pack, and execution trackers.
Definition of Done Tracking + Metrics
A binary finish line. Either complete or not complete.
Expand
Why it matters
It forces closure and prevents vague 'almost done' work.
Where you'll see it
Operator manuals, run plans, and SOP modules.
Kill Rule Signal + Validation
A threshold that stops a run when results are too weak.
Expand
Why it matters
It protects time, energy, and confidence.
Where you'll see it
Signal Sprint, Money Pack, and Console kill states.
Money Loop Signal + Validation
A repeatable loop that turns actions into replies, bookings, or sales, then into the next better action.
Expand
Why it matters
It keeps execution moving without overbuilding.
Where you'll see it
Signal Sprint and Money Pack execution loops.
Sprint Systems
A short, time-boxed run where you ship one thing and measure one main signal.
Expand
Why it matters
Sprints build momentum and force learning speed.
Where you'll see it
Signal Sprint, Money Pack, and Studio systems.
Funnel Offers
The path from attention to conversation to sale or conversion.
Expand
Why it matters
A clearer funnel produces better signal from the same effort.
Where you'll see it
Money Pack outreach, checkout, and delivery flows.
USING THIS PAGE
The glossary now reflects the current Tentex model: Run Specs define the run, Studio generates and executes, and Console evaluates evidence to decide whether the run should Go, Iterate, or Kill.