11. Configurations

NOTE: For individual adoption, see SENAR Core — 8 rules, 2 quality gates, 2 metrics. This Standard defines three organizational configurations: Foundation, Team, and Enterprise.

11.1 SENAR Foundation (1–3 Pairs)

The bridge between Core and Team. For small teams that need more structure than Core but aren’t ready for full Team process.

Note: The Metrics row lists the four metrics Foundation collects and reports. Rule 10.9, one of the three named in the Rules row above, additionally requires a documented Knowledge Capture Rate target — a target and the tracking of it, not a reported metric of the set in Section 9.1. Where the two readings of this table diverge, 10.9 is the requirement and the Metrics row is the reporting obligation; an organization satisfies both by documenting a KCR target with its rationale (9.2) without adding KCR to its metric reporting. The four are not a superset of Core’s two: Core tracks FPSR and Dead End Rate (SENAR Core, Metrics), so the move to Foundation keeps FPSR, adds Throughput, Lead Time and Defect Escape Rate, and stops reporting Dead End Rate. Dead ends themselves continue to be recorded — Rule 10.4 requires it at Foundation — but their rate is not one of the four reported here. The same distinction covers Adversarial Detection Rate: 10.15(e) requires organizations to track ADR, and 10.15 requires L3 review of High-risk changes regardless of configuration, so a Foundation organization that makes such a change owes the ADR figure under 10.15 while the Metrics row here lists four without it. As with KCR, 10.15(e) is the requirement and the Metrics row is the reporting obligation; both are satisfied by holding the ADR figure for the L3 reviews that occurred without adding ADR to the four reported metrics.

Note: At Foundation, session duration monitoring (Rule 10.2) is the Supervisor’s responsibility, since Flow Manager is not a separate role at this configuration (Section 4.8).

Note: Core rules and Standard rules use different numbering, which is why the Rules row states two lists instead of one sum. Core Rule 8 (Capture Knowledge) expands into Standard Rules 10.4 (Dead End Documentation) and 10.9 (Knowledge Capture); Foundation states these explicitly alongside Standard Rule 10.2 (Session Duration). Two further Standard rules reach Foundation without appearing in that list, and both arrive through other rows of this table rather than through the Rules row: 10.5 (Periodic Audit) is what the monthly Quality Sweep in the Ceremonies row is, and 10.15 (AI Output Quality Verification) applies at L1 and L2, which its own table marks “All (SHALL)” — L3 additionally applies to High-risk changes regardless of configuration. Section 10 states its rules without a configuration qualifier and 10.16 summarizes them for Team and Enterprise only, so this table is where the Foundation set is settled.

Note: Section 6.4 (secrets detection in sessions) implicitly requires elements of Rule 10.6 (Version Control). Organizations adopting Foundation SHOULD also adopt Rule 10.6 to ensure atomic commits, automated secrets detection, and scope-creep review.

Adoption Path (week by week)

• Week 1 — Core habits + Session Start/End. All team members read SENAR Core and begin applying its 8 rules daily. Introduce Session Start (context load + goal declaration) and Session End (output summary + knowledge entry) as team ceremonies. Assign the 5 responsibility sets across the 2 people — roles may overlap.
• Week 2 — Dead End documentation + Knowledge capture. Activate Rule 4 (Dead End Documentation): every blocked path gets a knowledge entry before work pivots. Activate Rule 9 (Knowledge Capture): every significant decision and non-obvious finding goes into the shared KB. After two weeks the team has a working knowledge base, not an empty one.
• Week 3 — Quality Sweep (first monthly). Run the first Quality Sweep: review the session log, check which dead ends were documented, identify recurring friction points. This is a retrospective with output — concrete adjustments to thresholds, session duration, or task decomposition depth.
• Week 4 — Metrics baseline. Start measuring all 4 metrics: Throughput (tasks completed per week), Lead Time (task start to done), FPSR (first-pass success rate at QG-2), Defect Escape Rate (bugs found after done). Record baseline values — no targets yet, just calibration. Adjust thresholds to your domain.

Foundation vs Core — What’s Different

Core is individual discipline: one Supervisor, two quality gates, two metrics, all enforced at the personal level. Foundation adds team coordination layer:

• Shared knowledge base visible to all team members and AI sessions (not just the author’s local context)
• Session Start/End as team ceremonies — synchronization points, not just individual habits
• Monthly Quality Sweep — collective review of process health, not individual retrospection
• Throughput, Lead Time and Defect Escape Rate on top of the FPSR that Core already tracks — three numbers that only mean something once several people share a definition of “done”

The cognitive overhead is low. Foundation is designed to be adopted incrementally on top of Core habits already in place.

FAQ for Foundation Teams

When do we move to Team? When any of the following applies: the team reaches 3+ Pairs and coordination overhead is visible; you need cross-pair dependency tracking or knowledge federation; you want QG-1 (Requirements Gate) or QG-3 (Verification Gate); you want dedicated (non-overlapping) responsibilities.

Can we skip Foundation and go directly to Team? Yes. If the team already has process discipline — structured task decomposition, code review culture, retrospectives — start at Team. Foundation is a bridge, not a mandatory stop.

What if we’re exactly 3 pairs? Evaluate experience level. If everyone is experienced with structured AI-assisted development, go Team — the overhead is manageable. If the team has mixed experience or is just starting with AI workflows, stay Foundation for 4–8 weeks to build habits before adding federation and all 5 gates.

11.2 SENAR Team (3–10 Pairs)

NOTE — RATIFICATION PENDING. The Responsibilities row above changed in this revision. Revision 1.3 required “All 5 dedicated (SHALL)” across the whole configuration, which contradicted Section 4.8: the same configuration prescribes a minimum of 3 distinct role-holders at 3–5 Pairs and states that what is owed is coverage of the responsibility sets rather than dedication. The row now yields to 4.8, which is the single source for headcount, and two SHALL requirements no longer demand different things. What changed is what an organization must staff, so the status is stated where the requirement is and not only in the changelog: at the date of this revision the change has not been ratified by the co-author. The requirement stands and applies as written — what is undetermined is its ratification, not its obligation; its obligation level is the one the row above states. An organization holding a Team claim made under 1.3 reassesses under Section 13.6, which already requires reassessment against this revision; this note introduces no second procedure.

11.3 SENAR Enterprise (10+ Pairs)

All Team requirements, PLUS:

For scaling ratios and enterprise guidance, see SENAR Reference.

NOTE: Enterprise configuration describes target state for large-scale adoption. Organizations at this scale should validate ratios and adapt coordination mechanisms to their context.

11.4 Comparison

NOTE: The Core column of this table is comparative throughout; 13.3 states what that means and is the only place that states it. This Standard’s obligations begin at Foundation. The properties every Quality Gate is required to have, and the obligation level of each by configuration, are not a row of this table: they are stated once, in 8.6.

NOTE: The Tooling row above is the one the gate property scale of 8.6 follows, and it follows it deliberately: the level of each property is set by what the property costs to implement. 8.6 states the scale and the basis for each level.

11.5 Migration

SENAR Core ──► Foundation ──► Team ──► Enterprise
 + 3 roles (combined)  + dedicated roles    + portfolio management
 + 3 ceremonies        + federation         + value streams
 + 2 more metrics      + all gates          + compliance
 + session mgmt        + all metrics/rules  + governance

Each step is incremental. Pilot with a subset of Pairs first. Typical timelines:

• Core → Foundation: 2-4 weeks after team has internalized Core habits
• Foundation → Team: 2-3 months, when team reaches 3+ Pairs or needs federation
• Team → Enterprise: when organization has 10+ Pairs and needs portfolio governance