Skip to content
Septiva

Evidence

Inspect the work.

Septiva argues for evidence before scale. That standard should apply to Septiva first. Below is real internal work, published as artifacts rather than claims.

Real internal work

Internal build record — Septiva.com

This site was built with the model it describes. The record below is the same shape we use in engagements: problem, decisions, build, evidence, next decision.

Problem
Septiva needed a public surface that explains an unfamiliar delivery model to enterprise and public-sector buyers, holds up to procurement and security review, and can change as the positioning sharpens — without a rebuild each time.
Decisions
A server-rendered application rather than a page builder, so routes, metadata, and accessibility are owned in code. Copy held in a shared typed content module separate from layout, so language can change without touching structure. One reusable visual system rather than per-page graphics. No analytics, no fabricated evidence.
Build
A server-rendered site of typed routes, a shared typed content module, a component library of accessible SVG and CSS system states, and a semantic colour system expressed as design tokens rather than per-component values.
Evidence
Once the site existed, the weaknesses were legible in a way no document had made them: sections that repeated each other, a commercial path that was hard to find, industry pages that swapped nouns instead of naming constraints. Each was corrected against the working artifact, not a plan.
Next decision
Enquiries are handled by email today: the engagement form validates in the browser and composes a message to a published address. Nothing is transmitted to a Septiva server or stored. A submission pipeline gets built when volume justifies it — the same threshold we ask clients to apply.

No client engagements, outcomes, metrics, or testimonials are published here. What appears on this page is Septiva's own internal work and one clearly labeled illustrative example.

Technical artifacts

Decisions written down while they were being made.

adr-001

ADR-001 — Content separated from layout

Accepted
Context
Positioning on a new category changes faster than structure. Copy embedded in components makes every language change an engineering change.
Decision
Core site copy lives in one typed content module that route components read from. Some page-specific copy still sits in its own route file, so the separation is a strong default rather than an absolute rule.
Consequence
Language can be revised in one place and propagates everywhere. The cost is indirection: a reader of a page component cannot see the words without opening the content module.
adr-002

ADR-002 — One visual system, many states

Accepted
Context
Each page wanted its own diagram. That path produces a set of unrelated figures and no recognizable language.
Decision
Compression, convergence, evidence, decision, and transfer are expressed as states of one reusable system, rendered as accessible SVG and CSS rather than images.
Consequence
Pages feel related and the assets stay text-selectable, themable, and light. Individual pages give up bespoke illustration.
adr-003

ADR-003 — No fabricated evidence

Accepted
Context
The fastest way to look established is invented logos, metrics, and case studies. It is also the fastest way to fail diligence.
Decision
Publish only claims that can be defended: no client names, no delivery statistics, no testimonials, no invented scale. Illustrative material is labeled as illustrative.
Consequence
The site carries less social proof than competitors. It carries nothing that collapses under a question.
artifact-004

Integration map — current state

Current
Context
What this system actually touches, stated plainly.
Decision
Server-rendered routes; the engagement form validates in the browser and composes an email to a published address, transmitting nothing to a Septiva server; no submission database, no analytics or tracking services, no advertising trackers, no customer data at rest.
Consequence
Diligence questions about data handling on this site have a short and verifiable answer. Anything beyond it would need to be built and disclosed.
artifact-005

Accessibility and motion strategy

Applied
Context
Interactive system diagrams degrade badly for keyboard users, screen readers, and anyone with reduced-motion preferences set.
Decision
Interactive system states are reachable by keyboard and labeled for assistive technology; diagrams carry a text equivalent or visible text labels; motion is suppressed when the operating system requests reduced motion.
Consequence
Visuals carry meaning without becoming the only route to it. Some animated transitions never run for some visitors — by design.

Illustrative example

A large assumed commitment, re-shaped as proof before scale.

Illustrative example. Not client work, not a historical engagement, and not a projection of outcomes.

  1. The assumed commitment

    A multi-year programme to replace a system of record, priced and approved as one decision, with the first working software late in the schedule.

  2. The smaller proof

    One bounded workflow inside that programme — the part staff perform manually today — built as working software against the existing system of record.

  3. The evidence

    What real use makes knowable: whether the integration assumption holds, whether the workflow is understood correctly, what the work actually costs, and where the risk really sits.

  4. The next decision

    Continue at a larger scale, change the approach, or stop — on evidence produced by working software rather than by a document.

Build SprintFoundryTrust

The first move

Bring one important problem and inspect the working method.

Challenge SeptivaRun a Build Sprint