Commercial Engine
Assessment, lead, qualification, booking, proposal and engagement flow.
Boundary: Public/commercial application
TINLANCE / ENGINEERING EVIDENCE
A public architecture map with a claim-to-evidence boundary.
This is a public abstraction of platform responsibilities and trust boundaries. It is not a production topology, customer environment, or infrastructure disclosure.
01 / ARCHITECTURE MAP
Connected layers.
Explicit boundaries.
The system is intentionally not presented as a single linear runtime. Commercial, delivery, API, security, evaluation, execution, knowledge and productization boundaries interact through defined control relationships.
Status: Implemented
Customer Workspace
Tenant-scoped customer delivery and evidence surfaces.
Boundary: Authenticated customer application
Automation
Workflow execution and orchestration boundary.
Boundary: Application workflow layer
API Platform
Central API surface for platform capabilities and contracts.
Boundary: API/application boundary
MCP Gateway
Controlled MCP/tool boundary with authorization-aware execution.
Boundary: Protocol/tool trust boundary
AI Security Gateway
Identity, tenancy, authorization, policy, risk, approval, output and audit controls.
Boundary: Security/trust plane
Evaluation Platform
Evaluation and regression authority for AI behavior and release decisions.
Boundary: Evaluation/control plane
Agent Runtime
Bounded agent execution with identity, approvals and runtime evidence.
Boundary: Execution boundary
Knowledge / RAG
Knowledge and retrieval authority with explicit scope boundaries.
Boundary: Knowledge/data boundary
AI Sales Engineer
Grounded technical discovery and product information surface.
Boundary: Public product/discovery application
Revenue Intelligence
Commercial and revenue intelligence layer.
Boundary: Internal commercial data layer
Proprietary Knowledge Moat
Governed intelligence derived from approved delivery evidence.
Boundary: Private knowledge layer
Consulting → Software
Pattern-to-playbook-to-productization feedback loop.
Boundary: Productization strategy/control layer
The downward sequence is a reading order, not a claim that every module is a runtime dependency of the next. Cross-links and control relationships are listed below.
02 / CONTROL RELATIONSHIPS
Architecture as evidence.
These relationships describe public responsibility boundaries without exposing private infrastructure.
Commercial Engine
Commercial context becomes tenant-scoped delivery context.
Customer Workspace
Customer delivery uses the API boundary.
API Platform
Sensitive AI capabilities cross the security control plane.
AI Security Gateway
Protected execution is evaluated before release/promotion.
Evaluation Platform
Evaluation gates agent runtime behavior.
Agent Runtime
Agent execution consumes scoped knowledge/retrieval.
Knowledge / RAG
Grounded knowledge supports technical discovery.
AI Sales Engineer
Commercial discovery can feed governed revenue intelligence.
Revenue Intelligence
Approved delivery/commercial evidence informs the private knowledge layer.
Proprietary Knowledge Moat
Evidence informs reusable patterns and productization.
Automation
Automation operates through the application/API boundary.
MCP Gateway
MCP tool access remains subject to security controls.
API Platform
FDE API provides the domain execution boundary.
FDE
FDE API routes into the domain-oriented FDE platform.
THREATFADE
ThreatFade is a distinct security product and public engineering evidence source; it is not a Tinlance subsystem.
03 / EVIDENCE TAXONOMY
Know what the status means.
Status is not decoration. It describes the strength and scope of evidence behind a claim.
Status: ImplementedExists in the current implementation.
Status: TestedCovered by automated or reproducible tests demonstrating the stated behavior.
Status: ValidatedSupported by documented validation beyond ordinary implementation or unit testing, with scope stated.
Status: ExperimentalImplemented for research or evaluation; production suitability has not been established.
Status: PlannedIntentionally identified for future implementation and not currently implemented.
Source code
A defined evidence source used to scope technical claims.
Automated test
A defined evidence source used to scope technical claims.
E2E test
A defined evidence source used to scope technical claims.
Benchmark
A defined evidence source used to scope technical claims.
Synthetic evaluation
A defined evidence source used to scope technical claims.
Independent validation
A defined evidence source used to scope technical claims.
Production evidence
Reserved for actual production evidence; repository tests alone do not qualify.
Research
A defined evidence source used to scope technical claims.
Documentation
A defined evidence source used to scope technical claims.
Architecture
A defined evidence source used to scope technical claims.
Security verification
A defined evidence source used to scope technical claims.
04 / PUBLIC REPOSITORIES
Inspect the implementation.
Only public repositories are linked. Private platform repositories and internal implementation details are intentionally excluded.
ThreatFade
Open-source security engineering evidence.
FDE Mastery
Public FDE platform engineering evidence.
ENGINEERING → ASSESSMENT
Public architecture meets the real environment.
Use a technical assessment to establish environment-specific workflow, architecture, security constraints, evidence and outcomes.