ServiceMatch by SwipeLeft AI · Ask

Ask an engineer’s question. The answer gets published.

Not a contact form and not a chatbot. Submit a real question about how ServiceMatch works — identity resolution, classification, CSDM cascade, how a decision gets recorded — and the answer is published on this page with the sources it came from, where anyone can check it.

Including the questions we decline. What a system refuses to answer tells you as much as what it will.

Try it first

A live ServiceMatch you can use, then ask about.

A full ServiceMatch deployment over a synthetic estate — 313 devices, four discovery sources, 44 governed classification rules and 130 recorded decisions. Run the pipeline, change a rule, read the decision ledger, export. It is a working system, not a video.

Each visitor gets their own copy. Your sidebar shows a session code; quote it in the form below and the answer can refer to what your session actually did — the records your run blocked, the rule you changed — rather than answer in general.

Open the demo

Login demo@swipeleft.ai / demo

The estate is synthetic: no customer’s data, in any form. The login is a gate against random traffic, not a secret. A limited number of sessions run at once; if they are all in use you will be told, and can leave an email to be notified. Sessions are reset on a schedule, so nothing you do persists past the day.

Submit a question

One question at a time, as specific as you can make it. Specific questions get answers worth publishing; broad ones get a link to the docs. If you used the demo, mention your session code in the question.

Answers are published every weekday, usually within one business day. We answer a selection, not everything — and we will say so rather than leave a question hanging.

How this works

  1. 1

    You submit a question.

    It lands in a list we read. Nothing is answered automatically and nothing is published on arrival.

  2. 2

    A draft answer is prepared with its sources.

    The draft is written by Claude, Anthropic’s AI, working from our published documentation and our own decision records — the same records the product keeps. Every claim is tied to a source before it goes any further.

  3. 3

    A person reviews and authorizes it.

    Someone here reads the draft, checks every claim against its source, and either authorizes publication or does not. Nothing reaches this page without that step, and the published entry names who authorized it.

  4. 4

    The answer is published here, with its sources.

    Question, answer, sources, the date it was asked and the date it was published. Permanent and linkable, so it can be checked and quoted.

Why publish them at all? Because an answer nobody can check is a sales claim. Publishing the question, the answer and the source — and keeping it there — is the same discipline the product applies to a CMDB: the record is the product, and a record you cannot audit is worth very little.

Published answers1

Classification

How many classes are in the estate?

On the demo estate — the synthetic Vantrex environment, 313 devices across four discovery sources — records land in ten ServiceNow CI classes: cmdb_ci_laptop, cmdb_ci_computer, cmdb_ci_desktop, cmdb_ci_mobile_device, cmdb_ci_linux_server, cmdb_ci_vm_instance, cmdb_ci_ip_switch, cmdb_ci_ip_router, cmdb_ci_ip_firewall and cmdb_ci_wap_network. Laptops dominate, as you would expect of an end-user estate.

A further 78 records sit in a review bucket rather than in any class. Those are records where classification did not reach a confident answer, and the system holds them for a person instead of forcing them into the nearest class. That is deliberate: an ambiguous device surfaced for review is a decision waiting to be made; the same device quietly filed under cmdb_ci_computer is a wrong record nobody will find.

The number is not a property of the product. The estate’s 44 governed classification rules target exactly those ten classes, so the class set is a consequence of the rules in force — and changing a rule is a recorded decision, with an author and an authority, not an edit. Your own estate would produce a different set, shaped by your sources and your rules.

Sources

Asked 10 November 2026 · published 10 November 2026 · reviewed and authorized by James Bockrath

What we don’t answer here

Published up front, so nobody spends a question finding out. Each one says what to ask instead.

Who our customers are
We never name a customer on a public surface, in any industry, at any stage.
Ask about the pattern rather than the account — the pattern is the part that transfers.
Pricing and commercial terms
Packaging depends on who operates the deployment and what is in scope, so a number here would be wrong for most readers.
That one is a conversation, not a published answer.
Our security posture in detail
What we publish about our own security is a disclosure decision taken on its own merits, not a side effect of answering a question.
Ask what the deployment model is — single-tenant, in the customer’s own tenant — which is published.
Scoring weights, rule bodies, and the prompts behind them
The configuration of a running deployment belongs to the customer who owns it, and our own authoring internals are not the product.
Ask how the mechanism works and what governs a change to it. That is documented, and it is the more useful answer.
Roadmap and unreleased work
We would rather be held to what is running than to what is planned.
Ask whether something works today. If the answer is no, you will get a no.
Anything about your own estate
We cannot see it, and an answer that guessed at it would be worthless.
Ask what the system would need in order to tell you — that is answerable, and it is usually the real question.

Want the mechanism rather than an answer to one question? The documentation describes how each stage works, and the design principles say what we hold to and why.