Minimise
Provide only the generic text needed to explore the interaction pattern.
Swaves AI Labs · Safety and limits
Know what the public lab can observe, what it cannot know, and when to stop.
This page defines the visitor boundary for Labs. It explains suitable inputs, material limitations, expected handling, and the difference between public abuse controls and enterprise safety engineering.
- Suitable
- Generic, synthetic, non-sensitive scenarios
- Avoid
- Personal, confidential, regulated, credential, or customer data
- Verify
- Every factual or consequential output independently
02
01 · Data boundary
If information should not be public, it does not belong in a public experiment.
Use fictional names and generic scenarios. Remove personal identifiers, secrets, credentials, customer material, source code, internal incidents, unpublished financials, and regulated records.
Sanitise
Replace people, organisations, systems, locations, identifiers, and values with synthetic placeholders.
Stop
Do not proceed when the task depends on information you cannot safely disclose publicly.
03
02 · Interpretation
A coherent response can still be wrong, unsupported, or out of context.
The lab lacks your authoritative sources, policies, permissions, current operating state, and accountable domain review. Verify material content against trusted sources and qualified people.
Check claims
Validate names, numbers, dates, references, assumptions, and technical statements independently.
Check context
Confirm that advice fits the actual jurisdiction, policy, architecture, user, and time period.
Check consequence
Move consequential decisions to an authorised process with accountable human review.
04
03 · Public safety
Input limits and abuse checks are a boundary, not a production security architecture.
Public controls can constrain request size, volume, and automated abuse. They do not provide customer identity, tenant authorisation, private source governance, operational approval, or domain validation.
Public boundary
Limits, session checks, safe input guidance, and constrained interaction modes.
Enterprise boundary
Organisation identity, least privilege, source policy, approval, audit, and incident response.
Decision boundary
Workflow-specific evaluation and an accountable release decision based on representative evidence.
05
04 · Escalation
The safest lab behavior is often to stop and move the work to the right setting.
Stop when a request involves private data, protected systems, vulnerable people, professional judgment, active incidents, security testing, legal obligations, or actions with real-world effect.
Illustrative control record: public guardrails and production assurance are different layers.
Protected context
Use an approved enterprise environment with the required access and data controls.
Qualified judgment
Route professional or regulated decisions to an authorised person.
Active risk
Use established incident, safeguarding, emergency, or security response channels.
06
05 · Production boundary
Production safety is evidence that controls work in a defined operating context.
Enterprise delivery starts again with workflow risk, source authority, identity, action boundaries, evaluation, operator experience, incident response, and change control. Public lab behavior is not reused as production assurance.
Contextual risk
Assess affected users, decisions, data, actions, reversibility, and credible failure scenarios.
Tested controls
Exercise permissions, approvals, refusals, fallback, telemetry, containment, and recovery.
Accountable release
Name owners, thresholds, exceptions, evidence, review triggers, and suspension authority.
A lab result is a learning artifact, not a production recommendation. Production work starts with a separate risk, data, evaluation, and ownership review.
Open the experiments