blencorp Login.gov Identity Design System
Build within the system's documented scope and delivery model.
Before editing
- Confirm the product owner and that this system is authorized for the target surface.
- Read references/implementation.md before installing or changing dependencies.
- Read references/sources.md when checking versions, provenance, license, or release state.
- Inspect the existing framework, package manager, asset pipeline, and accessibility tests. Preserve them unless the official integration requires a change.
Workflow
- Choose one documented delivery path; do not mix compiled, source, CDN, and framework-wrapper paths accidentally.
- Pin the dependency or downloaded asset version and keep upstream notices.
- Reuse official components, tokens, content guidance, and templates before adding custom UI.
- Extend through documented tokens, properties, slots, Sass settings, or composition. Do not edit vendored package files.
- Test semantic structure, keyboard operation, focus order and visibility, accessible names, error recovery, zoom/reflow, contrast, and target browsers.
- Report custom patterns, unsupported requirements, and upstream gaps explicitly.
Boundaries
- Scope: Login.gov-owned identity and authentication experiences. Do not apply Login.gov branding merely because a service uses authentication.
- Release: active official package and repository.
- Delivery: USWDS-compatible Sass, JavaScript, fonts, images, and component extensions.
- Do not invent component APIs, tokens, package names, or compliance claims.
- Do not import another jurisdiction's branding to fill a gap.
- A passing component example does not prove the completed service conforms to WCAG, Section 508, the ADA, or local policy.
References
- Implementation — packages, setup, and integration decisions
- Sources — authoritative URLs, snapshot versions, ownership, and license notes