How PMT works
How PMT works: token, signal, visible state
PMT has one basic pattern: a source determines an outcome or condition, sends a small GET or POST signal using a scoped token, and PMT makes the received state available in the webapp or through API readback.
Source → signal → view
- A source determines an outcome or condition.
- It sends a small GET or POST signal.
- PMT accepts the signal for processing.
- Received states can become visible.
- If an expected signal stops arriving, absence is visible too.
Meaning stays at the edge.
Three practical ways to send a signal
Different users start in different places. The PMT model stays the same.
Deploy a starter check
Use a transparent predefined check where one already fits. A Windows starter check can create an ordinary scheduled task and send a selected outcome.
Use a plugin or external check
For web work, a WordPress plugin or external site check can report a selected condition without turning PMT into a site-management platform.
Send your own signal
Use curl, PowerShell, Bash, an app, a gateway, a device, a cron job, a hosted service or any source that can make a simple HTTP request.
What a signal contains
A PMT signal is deliberately small. It normally includes only what is needed to place and show the result.
tkn— token showing where the signal belongsstn— station, system, site, source or devicesens— the question or check being reportedval— the received state or valuetag— optional short grouping label
If a signal needs a long explanation to be useful, it is probably the wrong signal.
No inventory to build first
You do not need to model the whole environment before sending a signal.
When a valid signal is received and shown, the station and signal can become visible without a separate setup step.
- choose one question
- send one signal
- view the received state
- then decide whether it deserves to repeat
Cadence becomes meaningful after a signal repeats.
Outcome first. Value second. Absence last.
PMT works with three signal forms. They should be understood in this order.
1. Explicit outcome
A source sends a state such as OK, act soon, act now, complete, fault or unknown. The source decides which state applies. This is the primary PMT pattern.
2. Value as condition
A source sends a value such as disk space, temperature, voltage, latency or water level. It is useful when the value is tied to a condition someone would act on.
3. Expected signal absent
If a signal is expected and does not arrive, that absence is visible as a safety condition. PMT does not infer the cause.
Cadence comes from repeated signals
A single test signal asks: can this source report?
A repeated signal asks: is this condition still being reported?
The webapp can use repeated signals and configured rules to make stale or missing expected signals visible. If the source reports irregularly, absence rules are less useful until the expected pattern is clear.
Browser view, NOC view, API or CLI
PMT is not only a page to look at. Received signal data can be viewed in the browser, used on mobile, shown on an operations screen, or read back through API/CLI access.
- browser and mobile-ready webapp
- project and token scoped views
- combined views where access is granted
- API/CLI access for your own tools
Same model, different sources
This page should make sense whether the source is a server, backup job, website, WordPress plugin, pump controller, sensor gateway or research station.
MSPs
A customer backup, scheduled job, branch system or external check reports a selected outcome.
Admins
A script, scheduled task, service check or system job sends the result it already knows.
Web agents
A WordPress plugin, site check, SSL/DNS check, backup job or email-path check reports a selected condition.
Beyond IT
A device, gateway, controller, sensor or process reports a state or value that someone can act on.
A practical first signal
Good first signals are narrow and actionable.
- a backup sends its result
- a scheduled task reports completion
- a website check reports reachability
- a WordPress plugin reports a selected condition
- a disk check reports capacity condition
- a temperature check reports range condition
- a remote device sends a check-in
Do not start by building a dashboard. Start with one condition that matters.
What PMT does not do
- discover systems
- collect everything
- diagnose causes
- model environments
- manage devices or content
- run commands remotely
- replace specialist tools
- act as a compliance archive
PMT makes received conditions visible. Your existing tools and judgement decide what happens next.
Where check definitions fit
Predefined checks should be inspectable. A good check definition explains what question it answers, what each value means, what it does not know, where it can mislead, and when not to use it.
One useful test
Ask this before adding a signal:
If this state became visible, would someone do something different?
If the answer is no, PMT is probably the wrong place for it.
Get your signal
Choose one source. Send one signal. Replace the test with something real.