TINLANCE / PRODUCTS

Products with explicit evidence boundaries.

Each product has a clear identity, public/private boundary and evidence status. A repository or test result is never presented as customer proof.

PUBLIC / OPEN COREStatus: Validated

ThreatFade

Problem: Adversarial activity can intentionally become less observable.

Capability: Evidence-first detection and investigation for signal reduction, including C2 quieting, LOTL fade and GNSS interference scenarios.

Evidence scope: Early MVP test population; not a universal detection-accuracy claim.

Limitation: Historical experimental result for the documented population; it does not establish universal current accuracy, enterprise production performance, certification, or customer deployment.

PUBLIC / ENGINEERING PLATFORMStatus: Tested

FDE Mastery

Problem: AI workflows need domain contracts, controls and evidence rather than model/API experiments alone.

Capability: A reusable FDE platform spanning eight first-class domains with identity, authorization, policy, durable workflows, evaluation, observability and controlled high-impact actions.

Evidence scope: Repository-level engineering and contract evidence; not proof of eight production deployments.

Limitation: Engineering evidence does not establish customer production deployment, customer outcomes, or independent assurance.

PRIVATE / M0 IN PROGRESS

Tinlance Agent Platform

Problem: Governed agent execution needs generic security and execution primitives without giving models implicit authority.

Capability: A private proprietary control substrate. Public implementation details are intentionally limited while the foundation is being built.

CAPABILITY REGISTRY

What is actually implemented.

The public capability surface is derived from a machine-readable registry. Engineering status and commercial availability are kept separate, and each customer-visible capability carries an evidence reference.

IMPLEMENTEDTESTEDCOMMERCIAL

Technical Assessment

Structured technical assessment lifecycle from intake through evidence-backed findings and customer workspace delivery.

Limitations: Automated evidence collection is bounded by the configured assessment and FDE services.

SOURCE_CODE

Repository implementation metadata and schema

IMPLEMENTEDTESTEDCOMMERCIAL

Customer Workspace

Tenant-scoped project workspace for assessments, findings, evidence, reports and remediation delivery.

Limitations: Access requires authenticated organization membership and applicable commercial entitlement.

SOURCE_CODE

Customer workspace persistence and tenancy model

IMPLEMENTEDTESTEDCOMMERCIAL

FDE Automation

Governed FDE workflow execution with policy, retry, observability and controlled external-service boundaries.

Limitations: FDE execution depends on the configured FDE API and enabled provider/model integrations.

CI_RUN

FDE automation schema and CI verification

IMPLEMENTEDTESTEDCOMMERCIAL

API Platform

Authenticated, tenant-aware API surface with scoped idempotency and operational controls.

Limitations: Public API availability is limited to documented endpoints; internal routes remain private.

SOURCE_CODE

API route surface and idempotency controls

IMPLEMENTEDVALIDATEDEXTERNAL_PRODUCT

ThreatFade Engineering

Evidence-first security engineering for ThreatFade as a distinct product developed by Tinlance.

Limitations: ThreatFade is a separate product. This registry records the relationship and does not imply Tinlance owns every ThreatFade commercial state.

DOCUMENTATION

Public ThreatFade capability/evidence manifest

Machine-readable capability registry

THREATFADE ↔ TINLANCE

Separate product.
Clear relationship.

ThreatFade is a distinct security product developed by Tinlance. Tinlance provides the engineering context; ThreatFade keeps its own product identity and public repository.

PUBLIC PROPERTIES

Inspect both sides of the relationship.

Explore the public ThreatFade product and repository, or return to Tinlance for the broader engineering and FDE platform context.