Scope and boundaries
Clear review scope. Clear stopping points.
This page explains what a CapyraWorks review can reasonably cover, why repository-visible evidence is the default starting point, and where the interpretation intentionally stops.
What is reviewed
The boundary starts with visible artifacts.
CapyraWorks reviews the agreed repository-visible material made available for the engagement. This may include:
- Infrastructure-as-code, platform code, and supporting configuration repositories agreed in scope
- Service, deployment, workflow, policy-adjacent, and governance-relevant configuration visible in those materials
- IAM, access-control, and CI/CD configuration where it is present and relevant to infrastructure or governance evidence
- Repository structure, deployment definitions, module usage, and configuration evidence
- AI-context or payment-environment indicators only where they are visible, relevant, and agreed in scope
Access posture
Read-only or export-based by default.
- Read-only repository or organization-level access is preferred when direct access is used.
- Access should be temporary, limited to the agreed review scope, and removed after the engagement unless otherwise agreed.
- Production-console, live-service, runtime-system, and operational-control-plane access are not required by default.
- Client-supplied checked-out repositories or agreed source exports can be used when direct repository access is not preferred or permitted.
Deliberately bounded
Evidence-backed, not assurance-claiming.
Repository evidence can support careful interpretation, but it cannot by itself establish deployed reality, legal standing, audit conclusions, or security guarantees.
A CapyraWorks review does not provide:
- Penetration testing, exploit activity, runtime monitoring, or runtime topology reconstruction
- Formal audit opinions, legal opinions, compliance certifications, or security certifications
- Maturity, readiness, or control-effectiveness scoring
- A replacement for scanners, internal ownership, team judgment, or formal assurance work
- A guarantee of vulnerability absence, incident prevention, runtime security, or availability
- A claim that repository-visible evidence proves operating reality
When it helps
Useful when the next review question is still unclear.
CapyraWorks is most useful when the organization has repository-visible infrastructure or platform evidence, but needs a clearer way to turn that material into review questions, ownership conversations, and next-step decisions.
It is a good fit when:
- The question is about what visible artifacts can reasonably support
- A repository export or read-only review is the right starting point
- Stakeholders need to separate evidence, assumptions, and missing context
- Engineering, platform, security, or governance teams need a shared view of the same material
- The next step depends on validation by repository, platform, security, or governance owners
Client ownership
Validation and decisions stay with the organization.
A review can clarify what needs to be checked next. It does not take over the authority, context, or accountability required to confirm runtime state, choose remediation, accept risk, or make governance and legal decisions.
Client-side ownership remains essential for:
- Confirming whether observed repository evidence matches deployed reality
- Prioritizing remediation, acceptance, additional testing, or further evidence collection
- Assigning architecture, security, governance, legal, compliance, and operational decisions
- Maintaining evidence records and follow-up ownership after the review
Have a bounded repository-visible review question?
Contact CapyraWorks
