Architecture Decision Records (ADRs)
A log of every architecturally significant decision - context, alternatives considered, decision, consequences. Format per Nygard (2011). Stored in the client's repository; the ADR log is the architecture.
Architecture,
written down.
Abstract
Kanopus is a technical practice. We help companies design software, security, and systems architectures that outlast their first version, and we ship the documentation that lets the team that inherits the work understand why it is the way it is. We are not an agency, not a body-shop, and not a staffing function. We are a small group of senior engineers who do considered work for a small number of clients.
Fields
Software
Cybersecurity
Embedded
Computer Vision
Frontier
§ 1
The Practice
What we do, who
we do it with.
Kanopus exists to do one thing well: produce technical architecture and documentation that holds up under engineering review. We are engaged as architects, advisors, or implementation supervisors, not as vendors of headcount. Our engagements are bounded, named, and reviewed.
§ 1.1 | Who we work with
Companies building real systems.
Founders shipping their first production system. Engineering leaders who inherited a codebase and need to make sense of it. Operators who need a defensible architecture for a regulator, a board, or an acquirer.
§ 1.2 | How we engage
Bounded, reviewed, documented.
Every engagement starts with a written scope. Every engagement ends with documented artifacts the client owns. We do not bill by the hour for open-ended retainer arrangements - we deliver against named deliverables.
§ 1.3 | What we decline
Work we cannot do well.
Pure staffing. Body-shop arrangements. Work outside our named fields. Engagements where the client is not present to review the work. We say no often. The discipline of saying no is what lets us say yes well.
§ 2
Deliverables
The artifacts
we ship.
Kanopus engagements result in written, reviewed artifacts, not just access to engineers. The deliverables below are produced in the disciplines we practice. Each is reviewed against a standard the client can audit.
System Design Documents
RFC-style design documents per major system component. Includes goals, non-goals, capacity model, alternatives considered, and migration plan where relevant.
Threat Models
STRIDE, PASTA, or LINDDUN as the methodology fits. Trust boundaries identified; threats enumerated; mitigations mapped; residual risks documented for explicit acceptance.
Component & Interface Diagrams
Component architecture, sequence diagrams, and API contracts. Drawn to a standard the client's engineers can extend without us.
Compliance Mappings
Controls mapped to ISO/IEC 27001:2022 Annex A, NIST CSF 2.0, DPDP Act 2023, or sector-specific frameworks. Audit-ready, not aspirational.
Implementation Runbooks
Operational procedures for deployment, rollback, incident response, and routine maintenance. Written to be runnable by the on-call engineer at 3am.
Post-Implementation Review
A written review 90 days after handover: what worked, what we got wrong, what should change. Honest because it has to be useful.
§ 3
A Figure
A typical engagement,
drawn.
We talk about architecture, so here is one. The diagram below shows the lifecycle of a typical Kanopus engagement, from the initial scoping conversation through to the post-implementation review. The shape varies by engagement; the discipline does not.
Fig. 3.1
Lifecycle of a typical Kanopus engagement1. Each phase produces written artifacts owned by the client. The review loop is iterative2; the post-implementation review at +90 days is non-optional.
¹
Engagement shapes vary. A pure architecture review may compress §2 and §3; a greenfield system may extend them across several months.
²
"Iterate until correct" is not a euphemism for "iterate until time runs out." Each review iteration is named, scoped, and reviewed against the prior version.
§ 4
Engagement
How to begin
a conversation.
Engagements begin with a conversation, not a brief. Write to us with what you are building, what concerns you about it, and the rough horizon you have in mind. We reply within two working days, usually with three or four questions and an honest assessment of whether we are the right team for the work.
We are deliberately a small practice. We take a small number of engagements at a time, and we do not take work outside our named fields. Defence and aerospace engagements are undertaken only where legally permitted under Indian export control law and subject to applicable licences, registrations, and government approvals - including SCOMET where relevant.
If we agree on shape and scope, the engagement proceeds against a written contract that names the deliverables, the review cadence, and the cost. We do not work on milestone payments tied to "best effort." We work on deliverables - produced, reviewed, accepted.
If we are not the right team, we will say so plainly. There are excellent technical consultancies and product engineering firms in India and elsewhere; we will often recommend one of them. Saying no honestly is not bad for business - it is how the practice keeps its standard.
Contact
Write to us
[email protected]