Trustworthy, Transparent, Scalable

Platform Overview

KLIQ AI (umbrella)
├── ShelfSignal (retail shelf monitoring)
└── AssetScan (physical asset inspection)
    ├── BuildingScan (facilities / NEN 2767, SFG20)
    ├── CollectorScan (collectibles / PSA, GIA, Sheldon)
    ├── VehicleScan (automotive / Hagerty, Manheim)
    ├── ArtScan (fine art / AIC standards)
    ├── MachineScan (industrial / ISO 10816, ISO 4628)
    └── InfraScan (infrastructure / FHWA NBI, NASSCO PACP)

The platform serves two audiences:

1. End users who use the reference apps (BuildingScan, CollectorScan, etc.) to inspect and grade physical assets.
2. Developers who use the SDK and API to build their own inspection verticals and integrate AI grading into their products.

Trustworthy by Design

1. Grading Standards, Not Black Boxes

Every grade the platform produces is anchored to a real-world, published grading standard. The system does not invent its own scores — it implements the exact scales that industry professionals already trust:

Why this matters: When a bridge inspector sees an NBI rating of 4 from InfraScan, they know exactly what that means — the same thing it means in every FHWA inspection report. There is no proprietary translation layer, no "AI confidence score" that requires interpretation. The grade speaks the language professionals already know.

2. Human-in-the-Loop by Default

AI grades are never final without human review. Every inspection follows a three-stage grading process:

Photo Capture → AI Grading → Human Review → Final Grade
                    │              │
                    ▼              ▼
              aiGrades        humanGrades
                    │              │
                    └──────┬───────┘
                           ▼
                      finalGrades

• aiGrades — generated by the CV pipeline (Gemini + YOLO verification)
• humanGrades — submitted by a qualified reviewer who can override any AI score
• finalGrades — the authoritative record. If human grades exist, they take precedence.

The system records both AI and human grades permanently. This creates an audit trail showing exactly where AI and human judgment diverged, enabling continuous model improvement and accountability.

const inspection = await tenant.inspections.get('insp_abc123');

console.log(inspection.aiGrades);    // What the AI said
console.log(inspection.humanGrades); // What the expert said
console.log(inspection.finalGrades); // The authoritative grade
console.log(inspection.status);      // "completed"

3. Grading Guide Descriptions — AI Transparency

The AI does not grade in a vacuum. Every grade value for every item type has a written grading guide that describes exactly what that grade looks like. These descriptions are:

• Publicly visible in the catalog registry (customers can read them)
• Injected into the AI prompt at grading time (so the AI uses the same criteria a human would)
• Editable by customers who can refine descriptions for their specific use case

// What the AI reads when grading a Pokémon card's centering
const guide = await kliq.catalog.types.gradingGuide('pokemon-base-set');

// Returns descriptions like:
// centering=10: "Perfect centering: 55/45 to 60/40 front, 75/25 back. No visible tilt."
// centering=9: "Near-perfect centering: 60/40 front, 90/10 back. Barely perceptible shift."
// centering=8: "Slight off-center: 65/35 front, 90/10 back. Noticeable under close inspection."

This means anyone can inspect exactly what criteria the AI uses and verify whether the grade makes sense. There are no hidden prompts or opaque model behaviors.

4. Multi-Model Verification

Critical grades are verified by multiple AI models:

1. Gemini Flash — fast identification ("What is this item?")
2. Gemini Pro — detailed grading with grading guide context ("What grade per attribute?")
3. Fine-tuned YOLO — independent visual verification ("Does the card corner look sharp or worn?")

When models disagree, the system flags the inspection for mandatory human review. Disagreement is treated as a signal, not an error.

Transparent by Design

1. Open Grading Schemas

Every grading schema is fully inspectable via the API. Customers can see:

• What attributes are being evaluated
• What scale each attribute uses
• How the overall grade is computed (weighted average, minimum, sum, pass-through)
• What weight each attribute carries

const schema = await kliq.gradingSchemas.get('gs_abc123');

console.log(schema.name);           // "PSA Card Grading"
console.log(schema.standard);       // "PSA"
console.log(schema.overallFormula);  // { type: "weighted_average" }
console.log(schema.attributes);
// [
//   { key: "centering", name: "Centering", weight: 1.0, type: "scale", config: { min: 1, max: 10 } },
//   { key: "corners",   name: "Corners",   weight: 1.0, type: "scale", config: { min: 1, max: 10 } },
//   { key: "edges",     name: "Edges",     weight: 1.0, type: "scale", config: { min: 1, max: 10 } },
//   { key: "surface",   name: "Surface",   weight: 1.0, type: "scale", config: { min: 1, max: 10 } },
// ]

There is no hidden logic. The formula, the weights, and the scales are all visible to every user.

2. Public Catalog Registry

The catalog is a curated, public dataset of item categories, types, and grading descriptions:

• 346 items across 6 verticals, ready to use
• 28 grading schemas implementing real-world standards
• 80 grading guide descriptions with detailed per-grade criteria
• Versioned and auditable — every change is tracked

Customers can use the public catalog as-is, extend it with private items, or build entirely custom catalogs. The public catalog serves as a transparent baseline that everyone can inspect and verify.

3. Full Audit Trail

Every action in the platform is recorded in an immutable audit log:

• Who performed the action (user ID, role)
• What changed (resource type, resource ID, action)
• When it happened (timestamp)
• What the state was before and after (previous state, new state)
• Whether it was a test or manual intervention

// Every inspection grade, schema change, and catalog edit is auditable
// GET /v1/tenants/:id/audit-events?resourceType=inspection&action=grade_submitted

4. Deterministic Grade Computation

The overall grade formula is not a neural network — it is a deterministic function that takes attribute scores and produces an overall grade using one of six defined methods:

Given the same attribute scores and formula, the same overall grade is always produced. This is verifiable, reproducible, and explainable.

Scalable by Design

1. Multi-Tenant Isolation

Every customer operates in a fully isolated tenant:

• Data isolation — all queries are scoped by tenantId. A customer can never see another customer's data, inspections, or catalog items.
• Configuration isolation — each tenant can have its own grading schemas, prompt templates, and catalog extensions without affecting others.
• Rate limiting — per-tenant rate limits ensure one customer's traffic does not degrade another's experience.
• Plan-based feature gating — tenants can be on different plans with different limits (max users, locations, inspections).

2. Vertical Extensibility

The platform does not hardcode domain knowledge. Instead, it provides a schema-driven framework that any vertical can plug into:

// A customer building their own "WineScan" vertical
const vertical = await kliq.verticals.create(tenantId, {
  slug: 'wine-scan',
  name: 'WineScan',
  description: 'Fine wine authentication and condition grading',
  brandColor: '#722F37',
});

const schema = await kliq.gradingSchemas.create(tenantId, {
  verticalId: vertical.id,
  slug: 'parker-100-point',
  name: 'Parker 100-Point Scale',
  standard: 'Robert Parker / Wine Advocate',
  overallFormula: { type: 'weighted_average' },
  attributes: [
    { key: 'aroma', name: 'Aroma/Bouquet', type: 'scale', config: { min: 0, max: 15 }, weight: 1.5 },
    { key: 'flavor', name: 'Flavor/Finish', type: 'scale', config: { min: 0, max: 20 }, weight: 2.0 },
    { key: 'overall_quality', name: 'Overall Quality', type: 'scale', config: { min: 0, max: 10 }, weight: 1.0 },
  ],
});

Adding a new vertical requires zero code changes to the platform. The grading engine, CV pipeline, inspection flow, and reporting all adapt automatically based on the schema configuration.

3. SDK-First Architecture

The platform is designed SDK-first: every feature is available through the API before it appears in any UI. This means:

• Reference apps are demos — BuildingScan, CollectorScan, etc. are built entirely with the public SDK. Anything they do, you can do.
• No vendor lock-in — your data, schemas, and catalog items are accessible via standard REST APIs with cursor-based pagination.
• Bring your own frontend — use our reference apps, modify them, or build from scratch. The SDK works with any framework (React, Vue, Svelte, mobile, backend).
• Webhook-driven integration — subscribe to events (inspection.completed, cv.job.finished) for real-time integration with your systems.

// The SDK is the same one our reference apps use
import { KliqClient } from '@kliq-ai/sdk';

const kliq = new KliqClient({ apiKey: process.env.KLIQ_API_KEY! });
const tenant = kliq.forTenant('t_your_tenant_id');

// Browse the public catalog
const categories = await kliq.catalog.categories.list({ vertical: 'collector' });
const types = await kliq.catalog.types.list('trading-cards');
const items = await kliq.catalog.items.list('pokemon-base-set');

// Run an inspection
const inspection = await tenant.inspections.create({
  verticalId: 'v_collector',
  catalogItemId: items.data[0].id,
  photos: [{ url: 'https://your-storage.com/card-front.jpg' }],
});

// Trigger AI grading
await tenant.inspections.grade(inspection.id);

4. Async CV Pipeline

The CV grading pipeline is fully asynchronous and horizontally scalable:

1. Submit — the inspection is created and photos are uploaded
2. Queue — the grading job enters a processing queue
3. Process — Gemini analyzes photos using the grading guide context
4. Verify — YOLO fine-tuned model provides independent verification
5. Complete — grades are recorded, webhook fires, inspection status updates

This architecture means:

• Grading jobs do not block the API
• The pipeline can scale horizontally by adding workers
• Failed jobs are retried automatically
• Long-running analysis (e.g., multiple photos, multi-attribute grading) does not time out

5. Public + Private Catalog Model

The catalog operates on a public registry + private extension model:

• Public catalog (maintained by KLIQ) — 346 items across 6 verticals with grading guides. Available to all tenants. Updated and versioned by the KLIQ team.
• Private items (maintained by each tenant) — customers add their own items that only they can see. Private items can reference public grading schemas or define custom ones.

This means the platform gets richer over time (more public items, more grading guides, more reference images) while each customer maintains full control over their proprietary data.

Security

Authentication

The platform supports three authentication methods:

• API Keys — for server-to-server integration. Keys are hashed with a salt, support rotation, and can be scoped to specific permissions.
• JWT Tokens — for user sessions. Short-lived (15 min) access tokens with long-lived refresh tokens. Tokens include tenant ID and role for authorization.
• OAuth 2.0 — for third-party integrations (coming soon).

Authorization

Role-based access control (RBAC) with a 5-level hierarchy:

Every API endpoint checks the caller's role before executing.

Data Protection

• All data encrypted in transit (TLS 1.3) and at rest (AES-256)
• Tenant data isolation enforced at the database query level (every query includes WHERE tenantId = ?)
• Comprehensive audit logging for compliance (GDPR, SOC 2)
• No training on customer data — your photos and grades are never used to train AI models for other customers

Summary

The KLIQ AI platform is not just infrastructure — it is an opinionated framework for building inspection and grading software that professionals can rely on, auditors can verify, and developers can extend.

Start building