Technical Mission and Principles

Mission

AIC engineering exists to deliver secure, maintainable, testable and commercially controlled software at pace.

The technical mission is to make delivery repeatable. Each project should leave the company with better accelerators, stronger patterns, clearer evidence and fewer unknowns than when it started.

AIC does not optimise only for code completion. We optimise for the complete delivery lifecycle:

• discovery and feasibility

• solution architecture

• secure design

• implementation

• testing

• deployment

• assurance

• operations

• handover

• support

• reuse

Engineering Principles

1. Production code is evidence-backed

Every meaningful technical choice must be supported by evidence. Evidence may include a design note, ADR, test result, performance measurement, security review, code review, architecture diagram or customer approval.

2. Secure by design is a delivery behaviour, not a late gate

Security requirements are captured early, implemented in normal engineering work, tested continuously and evidenced before release.

3. Boring technology wins by default

Use proven, supported, well-understood technology unless the project has a clear reason to do otherwise. New technology is valuable only when it reduces risk or creates measurable value.

4. Modern .NET first

For new AIC software, modern .NET is the default platform. The production baseline is .NET 10 LTS and C# 14. .NET 11 and C# 15 are treated as innovation or preview technology until approved for production use.

5. APIs are contracts

Public and integration-facing APIs must be designed as stable contracts. They require versioning, compatibility thinking, OpenAPI documentation, defined error behaviour, security controls and tests.

6. Tests are part of the design

Testing is not a phase after development. TDD, test-first thinking and executable specifications shape the design and protect future change.

7. Automation is the default control

Formatting, static analysis, unit tests, security scans, package checks and builds should be automated. Manual checks should be reserved for judgement, design and risk decisions.

8. Observability is a feature

A service that cannot be diagnosed is not complete. Logs, metrics, traces, health checks and correlation identifiers are part of the Definition of Done.

9. Simplicity is a security and delivery control

Prefer simple designs, explicit dependencies, clear boundaries and small units of work. Complexity must be justified.

10. Reusable IP must remain controlled

Frameworks, templates, components, patterns and accelerators are AIC assets. Use them to move faster, but preserve ownership, licensing and customer separation.

What Good Looks Like

A good AIC engineering project has:

• a pinned SDK and supported target framework

• a clear solution structure

• automated build and test pipeline

• analyzers and ReSharper inspections configured

• warnings treated as errors for production code

• nullable reference types enabled

• secure configuration and secrets handling

• automated tests at appropriate levels

• OpenAPI documentation for APIs

• architecture decisions recorded

• security controls evidenced

• deployment and rollback approach defined

• operational telemetry available

• code review before merge

• release evidence for every deployable version

What Bad Looks Like

A poor engineering project has:

• unclear target framework or unsupported runtime

• inconsistent formatting and naming

• warnings ignored

• no automated tests

• fragile manual deployment

• unclear ownership of architecture decisions

• secrets in source code or configuration files

• business logic hidden in controllers, views or event handlers

• uncontrolled dependencies

• no audit trail for releases

• no acceptance evidence

Mandatory Rules

• Every production project MUST target a supported .NET version.

• Every repository MUST include an AIC-approved .editorconfig.

• Every solution MUST have a repeatable build command.

• Every production solution MUST have automated tests.

• Every merge to the main branch MUST pass the defined quality gate.

• Every exception MUST be recorded and time-bound.