ASL Supervision — Source library
Public documentation snapshot: 2026-09-08
Prove the monitoring never went past the order.
Court-authorized device monitoring that records the authority it runs under and refuses anything outside it.
Prove the monitoring never went past the order.
Built for: Probation and parole departments monitoring agency-owned phones and PCs under a court's authority · Pretrial services and diversion programs that have to show a judge exactly what was collected, when, and under what order · Supervising officers carrying a caseload who get asked in a hearing to justify every data point they relied on · Agency administrators and counsel who own the disclosure language, the retention schedule, and the public-records answer
Prove the monitoring never went past the order.
The authorization is the product. Most monitoring tools install a capability and keep the paperwork somewhere else; here the order, its dates, its jurisdiction, the acknowledged notice, and the approved categories are the thing the collection is checked against, on every upload.
ASL Supervision exists because of this.
You are supervising someone under a court order, and part of that order covers a device the agency owns. So you put monitoring on it. Then, months later, a defense attorney asks a question you cannot answer cleanly: on the day this location record was captured, what exactly authorized it? Which order? Which paragraph? Was the order still in effect that week, or had it been stayed? Did the person get the disclosure, and which version of it? Who approved turning that category on? Most monitoring tools cannot answer any of that, because the authority lives in a paper file and the collection lives in a vendor console, and nothing connects the two. That gap is where cases fall apart and where agencies get sued. The tool collected whatever it was capable of collecting, from the day it was installed until somebody remembered to uninstall it. If the order was stayed on the ninth, the data kept flowing on the tenth, because nothing in the system knew the order existed. If the order covered location only, the tool still swept up browsing and app data, because that is what the product does by default. Now the whole collection is contested, and you are standing in front of a judge explaining a vendor's feature list. The other half of the problem is what these tools do to the people you supervise, and to your own officers. Products in this category sell keystroke capture, screenshots, and message reading, then hand your officer an automatic "violation detected" banner. That banner is not evidence and it is not a finding, but it looks like one, and once it is in a report it is very hard to walk back. Meanwhile the person on supervision has no clear idea what is being taken off a device they were told they had to carry, which is exactly the argument that gets an entire program challenged.
ASL Supervision exists because of this.
Out-of-scope data is refused before it is stored, not filtered out of a report afterwards. There is no copy of the unauthorized data sitting somewhere to be discovered later.
ASL Supervision exists because of this.
Suspension and revocation take effect at the point data arrives, so a stayed order stops collection on the next upload even though the device is still enrolled and still holds a valid credential.
ASL Supervision exists because of this.
The restraint is enforced by the release check and the tests, not just documented. The Windows collectors and the Android client are read for prohibited capabilities and the check fails if any are found, and negative tests prove that no-authority enrollment, unapproved categories, and post-suspension uploads are all rejected.
ASL Supervision exists because of this.
No automated violation finding exists anywhere in the product, and the human-review language appears in the officer portal, in the device app, and on the printed report.
ASL Supervision exists because of this.
One control plane covers supervised iPhones, supervised Android phones, and agency Windows PCs, instead of three consoles with three different privacy stories.
ASL Supervision exists because of this.
The deployment gates are published rather than buried. The agency approvals, device-management approvals, security review and operational testing a real rollout needs are written out as a checklist you can hand to counsel on day one.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Every case starts with a written authority
Before any device can send anything, a supervisor or administrator records the authority behind it: what kind (court order, supervision condition, participant agreement, or employer policy), the reference number, the jurisdiction, the exact start and end date and time, the notice version the person acknowledged and when, and who approved it. Approval takes a written reason. That record is the thing the monitoring runs on. No authority, no monitoring.
You choose the categories, not a vendor default
The authorization carries an explicit list of what may be collected — device health, location, geofence crossings, installed applications, usage totals, network destinations, and session activity. Leave a category off and the system will not accept it, even if a device tries to send it. Every case can be scoped down to the least you can defend, and the list of what you chose stays attached to the case.
Scope is checked three times, not once
A record with no active authority cannot produce an enrollment token. Activation checks the authority again. Then every single upload from every device is checked once more against its status, its dates, and its approved categories before anything is stored. Staying in scope is not a setting somebody has to remember to change; it is a gate the data has to pass on the way in.
Suspend or revoke and collection stops on the next upload
When an order is stayed, amended, or ends, a supervisor changes the authorization in the portal with a written reason. The next upload from that device is refused, even though the device is still enrolled and still holds a working credential. Revocation is permanent on purpose. A suspension can be lifted only while the original effective period is still running, so nobody can quietly restart monitoring on an order that has already run out.
A written list of what it will never do
No decryption of secure traffic, no screen scraping, no keystroke capture, no reading messages or another app's private files, no covert screenshots, no microphone or camera. This is a product requirement rather than a promise: the release check reads the Windows collector code and the Android client code looking for those capabilities and fails if it finds them, and the shipped tests prove the refusals actually happen at the point data arrives.
Signals point at evidence; they never declare a violation
A review item carries a low, medium, or high severity, a plain-language explanation, and a link to the underlying event. An officer opens the source, checks the case context, and writes a review note before acknowledging, and that note is kept. There is no automated violation finding in the product and no way to turn one on. Which conditions should raise an item for your caseload is defined with your agency during deployment; the release ships the queue, the review discipline and the record, not a vendor's idea of what counts as suspicious.
One caseload view across iPhone, Android, and Windows
Officers work from an installable portal showing the caseload, last contact, battery, open items, and the latest reported positions on a map, labelled as reported positions rather than continuous tracking. Device status is shown as device status, and the portal says outright that it does not establish compliance on its own. Exceptions surface first, so the review queue is the first thing you touch each morning.
Enrollment the person can see
An officer creates a one-time enrollment token that is good for thirty minutes, is bound to that specific authorization, and can only be used once. Supervised Android devices keep an ongoing status notification up the whole time they are enrolled. Agency PCs get a visible desktop status app that states in plain language what is collected and what is excluded. Nothing about the install is hidden from the person carrying the device.
Retirement that actually ends collection
When a case closes or a device comes back, an administrator or supervisor retires the device with a reason of their own words. The device receives a signed end-of-monitoring response, cancels its scheduled work, clears its stored queue and its credential, and shows the person that monitoring has ended. The retirement and the reason for it are written into the agency's record like any other sensitive action.
A tamper-evident record of every sensitive action
Sign-ins, authorization approvals and changes, enrollments, retirements, acknowledgements, report generation, and accepted device uploads are all appended to a running per-agency record, each entry linked to the one before it. Changing an earlier entry breaks the link. The portal recomputes the whole chain when you open the audit view and tells you where it broke, so an integrity problem is something you can see rather than something you have to assume away.
Monthly reports that show their own working
Pick a supervision record and a month and get a printable report plus a data file of the same content. It names the officer who generated it and when, lists each event type with its count and first and last timestamps, summarises review items by severity and status, lists the devices the events came from, and reprints the human-review notice. Categories the agency never authorized cannot appear, because data outside the approved scope was never stored in the first place.
Offline devices keep their place in line
A phone in a dead zone or a laptop closed for two days does not lose its events. Each client holds them in a protected, size-limited local store — up to two thousand events on Android and two thousand queued batches on Windows, uploaded no more than a hundred events at a time — and delivers them when the connection returns. Scheduled reporting restarts on its own after a reboot or an app update, and each upload is stamped and signed so a replayed request is rejected.
Network information that stops at the destination
Where a network category is authorized, what gets recorded is the destination side: the originating application, the hostname or address, the port, the direction, and byte counts where the platform provides them. Query strings and fragments are stripped before storage, and page contents or anything that would require decryption are outside the product entirely. It answers "this device contacted that service" and deliberately nothing more.
Roles that match how an agency actually works
Four roles — administrator, supervisor, officer, and auditor — with the agency boundary applied on every lookup, so one agency's records are not reachable from another's account. Approving a monitoring authorization is a supervisor or administrator action, separate from day-to-day officer work, which keeps scope decisions where an agency's policy usually puts them.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Surfaces and status.
Status as of 2026-09-02. The agency portal answered on 2026-09-02 and reported release 0.3.0; the sign-in page plus the caseload, alerts, reports, organization and audit views are all present, and responses carry a strict content policy and transport security. Deployment records for release 0.3.0-20260729034826 show a dedicated service behind HTTPS with automated certificate renewal, checksum-verified releases, a database backup taken before every switch, and automatic rollback. But no agency is using it: access is by agency account only with no self-serve sign-up, the live data holds zero supervised people, zero devices and zero monitoring authorizations, no signal rules generate review items from device data yet, and the product's own documents say not to load real supervision data until an agency's counsel, records and security reviews are complete. Deployed and answering is not the same as in service, so this is labelled in development rather than early access.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Supervision.
ASL Therapy
The same justice-involved caseload usually has a treatment side. ASL Therapy is practice management for the therapists and court-directed treatment programs an agency refers to, with court and standards-board reporting built around a documented human approval step. Different product, same insistence on a recorded human decision.
Outside Access
For agencies whose population moves between custody and community, Outside Access delivers research, documents and answers to people inside through the messaging channel they already have — useful for reentry planning that starts well before release.
Policy Lens
Agency policy, standards and statute questions come up constantly during supervision decisions. Policy Lens answers from a defined body of source material and links what it used, so a staff answer can be traced back to the text it came from.
ASL Municipal Utilities
Same buyer, different department. If your county or city is already evaluating ASL for a government workload, the utilities platform covers billing, service requests and accessible resident self-service with the same accountability approach.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-09-02 the agency portal answers, reports release 0.3.0, and serves the full caseload, alerts, reports, organization and audit surfaces with strict content and transport protections in place. The most recent product work was the 0.4.0 update prepared on.
Recent progress.
2026-07-31 it adds release signing for the Android client and brings every surface — service, Android app, Windows client, installer and portal — onto a single version, closing drift that had crept in between them. It is built, signed and tested but not deployed. The most recent platform-level change touching Supervision was a.
Recent progress.
2026-08-24 catalog review, which deliberately left the version unstated on the public site rather than publishing a number it could not evidence.
Recent progress.
Pricing for ASL Supervision is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
What does it cost?
Pricing is not published. It depends on how many supervised devices you run, which platforms you need, and how much of the deployment work — device-management setup, signing, and the legal and records review — your agency handles versus wants help with. Send a rough device count and the platforms in scope and you will get a real number rather than a per-seat sticker price.
We already have a monitoring vendor. Why switch?
Ask your current vendor to show you, for one specific data point from last month, which order authorized it, whether that order was in effect that day, which categories were approved, and who approved them. If the answer is a spreadsheet in someone's drawer, that is the gap. ASL Supervision keeps the authority and the collection in the same system and checks one against the other on every upload, which is exactly the part that gets contested in a hearing.
Is it actually ready, or would we be helping you finish it?
Honestly, some of both, and you should hear it plainly. The agency portal is deployed and running today, and the workflow — supervision record, monitoring authorization, enrollment, scope-enforced device reporting, review with a mandatory note, monthly reports and audit — is built and tested. What is genuinely ahead is a first agency deployment: your device-management setup, your legal and records review, testing on your hardware, and defining the signal rules that decide what raises a review item for your caseload, because the release does not ship a vendor's guess at those. We would rather say that than let you find it out during rollout.
How do we know it will not collect more than the judge allowed?
Because the allowed list is checked at the point the data arrives, not at the point it is displayed. Each event type maps to one of seven categories, and if that category is not on the authorization the upload is refused before anything is written down. There is also no code path at all for the things people worry about most — keystrokes, messages, screen contents, credentials, microphone, camera — and the release check fails if a prohibited capability turns up in a Windows collector or the Android client.
Does the product tell our officers when something is wrong?
It gives them a queue, a severity, an explanation and a link to the underlying event, and it makes them write a note before they can close an item. What it does not do is decide, on its own, that an event deserves attention — the release ships no automatic rule for that, and no automated violation finding, ever. Agencies differ enormously on what a geofence exit or a missed check-in means, so those rules get written with you and reviewed by your counsel rather than shipped as a default nobody signed off on.
What happens to our data if we stop paying or walk away?
Your records are yours and you should be able to leave with them. Reports come out as both a printable document and a plain data file at any time, so a case file can be exported without our help. The retention and deletion schedule is something your agency approves as part of deployment, and deletion is logged like any other sensitive action. Ask for the exit terms in writing before you sign anything — that is a fair thing to insist on with any vendor, us included.
How hard is it to move from what we have now?
The portal side is fast: create your agency's records, assign officers, approve authorizations. The device side is the real work, and it is device-management work rather than software work — supervised iPhones enrolled through your Apple enterprise program, Android devices enrolled from a factory reset as fully managed, Windows PCs installed by an administrator after you sign the package. Historical data from another vendor is not imported, and honestly you probably do not want data collected under a scope you cannot reconstruct.
Does it decide when someone has violated?
No, and it never will. Review items carry a severity, an explanation, and a link to the underlying event; an officer has to open the source and write a note before acknowledging. The notice that automated signals are evidence pointers for human review appears in the officer portal, on the device app, and on the printed report. An automated finding of violation is outside the product boundary on purpose, not by omission.
Does the person being monitored know it is there?
Yes, by design. The authorization itself records which version of the notice they acknowledged and when, and enrollment cannot happen without that. On Android an ongoing status notification stays up the whole time the device is enrolled; on Windows there is a visible desktop app listing what is and is not collected. There is no covert mode and no plan to add one — a program that cannot be explained to the person on it is a program that gets thrown out.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
No person or device has been enrolled yet. The service is running and the authorization-to-report workflow is complete end to end, but the first agency deployment is still ahead of us.
What should I know before I rely on it?
The review queue is built — severity, explanation, link to the source event, a mandatory review note, and an audit entry — but the release contains no rule that raises a review item automatically from incoming device data. The items you see in a demonstration are seeded. Deciding what should raise an item for your caseload is deployment work we do with you.
What should I know before I rely on it?
Session activity is one of the seven categories the service will enforce, but no shipped client collects it yet. It is scope you can withhold, not a feature you can switch on today.
What should I know before I rely on it?
Geofence crossings are an Android capability. The supervised iPhone client reports disclosed location and device health only; it does not monitor geofences.
What should I know before I rely on it?
On Android, installed-application inventory, usage totals, network destination information and SIM-change signals are all off in the app's own defaults. They only collect when your managed-device configuration turns them on, and usage totals additionally require Usage Access to be granted during managed setup.
What should I know before I rely on it?
Going live is gated on your side as much as ours: counsel signing off on the lawful basis for each category, an approved notice and device agreement, retention and public-records schedules, and trained human-review procedures. The product ships the machinery those reviews ask for, and the full checklist is published rather than hidden.
What should I know before I rely on it?
No criminal-justice information-system authorization is claimed. Your procurement and security teams determine whether your data falls in that scope and what obligations follow.
What should I know before I rely on it?
An independent security assessment has not been done yet. Everything verified to date was verified by us, and we say so rather than calling it an audit.
What should I know before I rely on it?
Sign-in today is per-agency accounts on the portal itself. Connecting it to your agency's own sign-on with phishing-resistant multi-factor is a deployment step, not something already wired up.
What should I know before I rely on it?
The supervised iPhone client needs your Apple enterprise program approvals and device testing before it can be installed, and its network-information feature specifically requires an Apple approval. It stays switched off unless your device policy turns it on.
Prove the monitoring never went past the order.
Prefer email? contact@autosecurelogin.com