Project Separation
Separate customers, sites and branches at source
Use PMT projects to keep customer, site, branch or operational signal groups separated by token and responsibility. Combine selected read views where access permits without merging projects or creating a shared control plane.
Project model
Start with one account and one project. Add projects only where separation is useful.
Account
Commercial and recovery anchor.
Project
Customer, site, branch, or signal group.
Token
Scoped send or read access for that project.
How project separation works
Keep data separated at the point where signals are issued. Combine only the read views you deliberately choose.
Use project-specific send tokens
Signals should use the send token for the project they belong to. A customer, site, branch, or operational group can report into its own project.
Share scoped read access
Read access can be limited to selected projects. Share the project view needed without exposing the wider account.
Combine selected views
The webapp can use selected read tokens to show more than one project together. Combined views expose only what those read tokens allow.
When to use another project
Add a project when separation changes how you manage access, responsibility, or operational view.
- another customer
- another branch or site
- a distinct internal system group
- a web estate that should not mix with server checks
- a non-IT operational use that needs its own boundary
- a collaborator or customer who should see only one project
Do not add projects just to create the appearance of broader coverage.
Keep the same PMT discipline
A new project does not change PMT’s role.
Each project still depends on selected signals sent from the edge. The sender owns the result meaning. PMT makes received states available and can make missing expected signals visible in the operator surface.
1 project
1 first signal
1 reason to keep it separate
Useful separation patterns
The same account/project/token model can fit different users without changing the product.
MSPs
One project per customer, or per customer site where branch separation matters. Combine selected read views for operations.
Admins
Separate production, branch, lab, or service groups when access or operational ownership differs.
Web agents
Use projects for client sites, hosting groups, WordPress estates, or web checks that should remain apart.
Beyond IT
Use separate projects for equipment, gateways, sensor groups, or operational processes where signal meaning is domain-specific.
Scoped tokens keep access narrow
Projects use tokens for sending and reading signals. A token should have the scope and purpose needed for the job.
- send tokens let sources report into the project
- read tokens let selected views consume project data
- PIN or expiry controls may apply depending on the token
- tokens can be rotated or revoked when needed
Public examples should treat tokens as secrets. Use environment variables or protected storage where practical.
Combined views are read paths
A combined view is not a merged tenant and not a shared control plane.
It is a selected read path. The webapp can show signals from more than one project when the relevant read tokens are supplied.
That helps an operator see related projects together while still keeping project-specific send paths and access decisions separate.
What project separation does not do
- does not discover systems
- does not create estate-wide inventory
- does not diagnose causes
- does not add remote control
- does not make PMT a compliance archive
- does not guarantee delivery, storage, or display of every signal
Projects help organise selected signals. They do not make PMT a system model.
What to avoid in names and refs
Project labels, station names, tags, and client refs should be useful without becoming a data dump.
- do not put passwords or API keys in names
- avoid sensitive personal data
- avoid long descriptions where a short stable label will do
- use stable identifiers that will still make sense later
Send the outcome you need. Keep unnecessary data out of the signal layer.
Add a project
Use this when an existing account needs another customer, site, branch, or signal group.
Use your own checks
Send selected outcomes from scripts, jobs, apps, websites, devices, or operational processes.
How it works
Review the signal model: source decides, signal reports, PMT makes received states visible.
Add a project when separation matters
Use the existing account reference.
Use the primary signup email.
Create a separated place for selected signals to report.