Model boundary
A model may draft, classify, retrieve, compare, test, or explain. Its output remains a candidate until another authority accepts it.
Security and trust
Secure claims need evidence, not adjectives.
Serapis is designed so fluent output cannot quietly become authority. Models produce candidate work; bounded mechanics, identity, evidence, and named people determine whether an effect is eligible.
Core boundaries
Separate what creates evidence from what grants authority.
These principles guide the product. The exact controls, deployment profile, and evidence required for a customer environment remain part of the written engagement and customer approval process.
Deterministic gate
Versioned mechanics evaluate bounded predicates and return 0, 1, or UNKNOWN; persuasive language cannot override the result.
Fail-closed unknown
Missing, contradictory, stale, inapplicable, or unverifiable evidence holds visibly rather than being treated as a pass.
Scoped identity
The requested action, evidence producer, evaluator, reviewer, and authorizer remain distinguishable roles with bounded scope.
Receipt boundary
The exact candidate, sources, rule revision, result, identity, decision, and effect travel as one inspectable record.
Customer boundary
Customer-selected models, keys, data, rules, compute, and authority remain inside the approved profile and portable-exit agreement.
Federal assurance
Map to the exact system, revision, and authority.
Standards guide evidence work; they are not product badges. Serapis can help structure a bounded evidence path, but it cannot certify a contractor, grant an authorization, or accept risk for the customer.
System-scoped status
CMMC status belongs to a specific contractor information system and contractual requirement. Evidence, gaps, owners, assessment dates, and affirmations must remain bound to that scope.
Revision-aware mapping
Current CMMC evidence uses Revision 2 while NIST has published Revision 3. Catalogs and mappings must identify the exact revision instead of blending requirements.
Inputs for customer authority
Continuous evidence, traceable releases, control gates, and risk views can support an authorization workflow. ATO and cATO decisions remain with the designated Government authorization authorities.
Claim ceilings
Every stage says exactly what its evidence supports.
A screen that works is evidence of a screen. It is not proof of a live connector, operational suitability, or continuing authority.
Describes intent
Marketing explains the design, team, and proposed path. It is not a security attestation, binding proposal, or proof of customer deployment.
Shows interaction
Synthetic records can prove the visible workflow and receipt pattern. They have no customer-system or mission effect.
Tests the real seam
Customer-authorized access and acceptance criteria establish whether identity, data mapping, rules, usability, and deployment fit the selected environment.
What a production claim needs
Authority follows evidence.
Production use is deployment-specific. It requires the customer’s approved architecture, security review, identity and access design, data handling boundary, operational procedures, testing, and acceptance.
Serapis will not infer those approvals from a successful demonstration or from controls that exist in another environment.
AI providerCustomer-selected within the approved profile; replaceable without becoming decision authority.
Keys and secretsCustomer-controlled handling and storage depend on the approved deployment.
Data storesCustomer-selected systems remain sources of record; Serapis does not require ownership of the operational picture.
RulesNamed, versioned, inspectable, and attributable to customer authority.
ExitSource, configuration, evidence, receipts, and operating knowledge are covered by the agreed replacement boundary.
Customer custody
Trust includes the ability to replace us.
The replacement test is architectural: can the customer preserve its facts, decisions, rules, and operating history if a model, cloud, database, or Serapis itself changes?
Where portability is limited by a selected dependency, that limitation should be visible before adoption—not discovered during exit.
This public site
A deliberately small public surface.
The public marketing pages do not host product authentication, customer data, an application API, operational connectors, analytics pixels, advertising trackers, or a contact form.
Email links open the visitor’s own mail client. Hosting and security providers may process ordinary request data required to deliver and protect the site.
Challenge the boundary
Ask us to show the evidence behind the claim.
If a capability cannot be demonstrated or bounded yet, the right answer is UNKNOWN and a concrete path to learn—not a stronger adjective.