Five-pillar architecture
Contracts, trust boundaries, lifecycle, failure, recovery and evidence requested per pillar.
Client Technical Assurance
Validate the architecture before you depend on it.
Qualified technical evaluators receive a revocable, client-confidential GitBook site and an immutable dated PDF snapshot tied to the exact architecture, claims and component versions under review.
AudienceCTO · CISO · architect
AccessRevocable private link
SnapshotImmutable + checksummed
ClaimsEvidence-levelled
Evaluation journey
Enough depth to complete technical due diligence.
The assurance experience is more detailed than the public publication but remains sanitised: representative declarations and contracts, never private repository links, credentials or exploitable client detail.
01
Architecture
Five pillars, trust boundaries, data flows and compatibility.
02
Controls
Identity, IAM, encryption, secrets, network and change control.
03
Evidence
Current evidence, limitations, NFRs, recovery and acceptance.
04
Ownership
Responsibilities, handover inventory and client operating authority.
Evidence ladder
Every claim exposes what it does—and does not—establish.
Structural checks are valuable, but they are not described as an accepted client production deployment. A later evidence level is earned only by the environment and acceptance it actually represents.
Founder-led experience is a separate evidence origin; it is not relabelled as a Substrada engagement.
Contents
The pack anticipates the hard questions.
Security and governance
Shared responsibility, identity, encryption, secrets, network controls and sensitive-data paths.
Deployment lifecycle
Readiness, controlled order, change control, objective acceptance and version compatibility.
Operational qualities
Availability, performance, reliability, security, operability and acceptance methods.
Evidence and limitations
Current evidence, release-scoped claims, known limitations and the evidence required next.
Handover
Component inventory, runbooks, access transition, enablement and client-owned operation.
Snapshot integrity
An issued version is never edited in place.
Each active evaluation receives a named access owner and expiry. Its PDF snapshot includes a manifest and checksums. Corrections produce a new version so a reviewer can always identify what they evaluated.
- Revocable share link named for the due-diligence process.
- Access owner and expiry recorded.
- Documentation commit and component versions pinned.
- Approved claim-set version included.
- Artifact hashes embedded in the snapshot manifest.
- Correction creates a new immutable version.
Qualified evaluation