Add the first internal developer platform reference pack

README.md

@@ -1,2 +1,13 @@
 # tcs-reference-architectures
 Reference architectures and implementation guides from TATA Consulting Services
+
+## Current assets
+
+- `architectures/internal-developer-platform/` - initial internal developer platform reference pack
+- `docs/architecture/` - rendered architecture diagrams
+- `docs/meeting-minutes/` - bootstrap planning notes and follow-up actions
+
+## Initial backlog
+
+- #1 Draft internal developer platform reference architecture
+- #2 Define architecture review template and acceptance criteria

architectures/internal-developer-platform/README.md

@@ -0,0 +1,28 @@
+# Internal developer platform reference architecture
+
+This starter reference architecture packages the minimum set of platform capabilities that a consulting team can tailor for a client-specific internal developer platform engagement.
+
+## Goals
+
+- Standardize service onboarding and golden paths
+- Centralize software catalog metadata and ownership
+- Provide self-service infrastructure workflows with policy guardrails
+- Establish observability, cost, and security review checkpoints
+
+## Core components
+
+| Capability | Suggested component |
+| --- | --- |
+| Developer portal | Backstage |
+| Continuous delivery | Argo CD |
+| Infrastructure orchestration | Crossplane and Terraform |
+| Event-driven autoscaling | KEDA |
+| Secrets and identity | Cloud-native secret manager plus SSO |
+| Observability | Metrics, logs, and traces with centralized dashboards |
+
+## Delivery phases
+
+1. Foundation: identity, source control standards, environments, and guardrails
+2. Platform services: catalog, templates, delivery automation, and observability
+3. Golden paths: standardized service blueprints for key workloads
+4. Adoption: scorecards, office hours, and operating model handoff

architectures/internal-developer-platform/decision-log.md

@@ -0,0 +1,15 @@
+# Decision log
+
+## 2026-05-27
+
+### Decision: Lead with a portal-centric platform experience
+
+The first architecture pack centers on a developer portal so the consulting story starts with discoverability, ownership, and standardized workflows.
+
+### Decision: Keep infrastructure abstractions cloud-neutral at the architecture layer
+
+Cloud-specific assets belong in implementation packs. The architecture should describe control points and responsibilities before picking provider services.
+
+### Decision: Treat observability and governance as first-class platform capabilities
+
+Scorecards, audit evidence, and service health should be visible from the start rather than postponed until later phases.

docs/architecture/platform-system-context.md

@@ -0,0 +1,21 @@
+# Platform system context
+
+```mermaid
+flowchart LR
+    Developers[Product teams] --> Portal[Developer portal]
+    Portal --> Templates[Golden path templates]
+    Portal --> Catalog[Software catalog]
+    Templates --> CI[CI pipeline]
+    CI --> GitOps[GitOps delivery]
+    GitOps --> Runtime[Kubernetes runtime]
+    Runtime --> Observability[Observability platform]
+    Runtime --> Policies[Policy guardrails]
+    PlatformTeam[Platform team] --> Portal
+    PlatformTeam --> Policies
+    Security[Security and compliance] --> Policies
+    Leadership[Delivery leadership] --> Scorecards[Adoption scorecards]
+    Observability --> Scorecards
+    Catalog --> Scorecards
+```
+
+This diagram captures the default consulting narrative: product teams enter through the portal, delivery is standardized through templates and GitOps, and operating signals roll up to scorecards.

docs/meeting-minutes/2026-05-27-architecture-kickoff.md

@@ -0,0 +1,17 @@
+# Architecture kickoff notes - 2026-05-27
+
+## Purpose
+
+Seed the repository with a first reference pack that consulting teams can adapt for internal developer platform engagements.
+
+## Decisions
+
+- Start with an internal developer platform reference because it aligns with the broader platform engineering focus in the organization.
+- Keep the first pack tool-opinionated enough to be actionable while remaining adaptable across cloud providers.
+- Capture review criteria as a follow-on deliverable so future architecture packs follow the same approval flow.
+
+## Action items
+
+- Publish the first system context diagram and decision log.
+- Add an architecture review template tied to issue #2.
+- Expand the reference pack with security, data, and operating model appendices.