Evaluate the operating system behind the product claim.
A serious evaluation should connect the governed surface, customer authority, runtime decision, record, evidence boundary, dependencies, and exit path. Ask for the exact deployment—not the category story.
01
Governed scope
—Which candidate outputs or agent actions are actually evaluated?
—Which runtime, model route, environment, users, and projects are included?
—Which surfaces are current, preview, simulation, planned, or unsupported?
02
Policy authority
—Who supplies and approves policy?
—How are reviewed inputs compiled, versioned, activated, and changed?
—What remains human judgment, and what can the system decide automatically?
03
Operating outcomes
—What do APPROVED, RESTRICTED, and ESCALATED mean in this deployment?
—What happens when policy, extraction, identity, integration, runtime, or evidence is unavailable?
—How are exceptions, fallback, rollback, and shutdown handled?
04
Records and evidence
—What record is created for each supported decision path?
—What policy, reason, time, scope, review, and trace context is available?
—Where are records stored, how long are they retained, and what can be exported?
05
Identity and access
—How do operator sessions differ from programmatic project credentials?
—How are projects, roles, memberships, and reviewer authority scoped?
—How are access changes and administrative actions recorded?
06
Integrations and dependencies
—Which systems are governed runtimes and which are downstream integrations?
—What data flows in each direction and through which credentials?
—What happens when a dependency, webhook, storage service, or trace system fails?
07
Security, privacy, and support
—Which hosting, data, subprocessors, retention, residency, and security terms apply?
—Who supports incidents, policy errors, integration failures, and reviewer operations?
—Which statements are public context and which are contractual commitments?
08
Commercial and exit terms
—What determines software and service scope?
—Which environments, users, volumes, integrations, support, and professional services are included?
—How are data, records, policy artifacts, and integrations exported or retired?
Procurement red flags
01
A product label is used as proof without a declared evidence scope.
02
Policy sources, customer approval, and change authority are unclear.
03
A runtime, integration, and observability system are treated as the same category.
04
Failure states are hidden behind a single coverage or readiness score.
05
Preview screenshots or simulations are presented as customer outcome evidence.
06
Standards references are presented as certification or guaranteed compliance.
07
The buyer cannot identify how to restrict, pause, export, or exit the deployment.
Scalebotics and Sable
Software access and professional services are separate commitments.
Sable product access depends on the supported governed surface and deployment requirements. Scalebotics services may include briefing, Discovery, Readiness, Deployment, or Assurance. A proposal should identify which work is software, which is professional service, who participates, and what evidence or result is expected.