The Provenance Ledger

A scored, role-gated pipeline that carries a Product Owner's requirement from a waiting queue, through Bedrock AgentCore drafting under your existing guardrails, to a pull request — with every hop hashed back to the original intent.

Worked example A Product Owner drops a requirement document — “add a Case Type picklist to Salesforce Case” — into the intake queue. This document follows that one change all the way to a governed PR, stage by stage.

Where this stands today

Three stages of this pipeline already run in the portal. The rest is designed against what you now have available — a live AWS Bedrock agent with a guardrail and inline policies already configured, and GitHub for the delivery end.

stages already built & tested

new stage ready to build now

stages waiting on your Bedrock config

validation gates to stand up after

The pipeline, stage by stage

Every stage after intake produces one artifact, is checked by an automated Governed Gate score, and needs one accountable role's sign-off before the next stage may start. A stage's status tells you what's already running, what's new this round, and what's simply waiting on a value only you have.

Proposal intakeBuilt

Trigger: PO or BA submits the requirement (document, paste, or Jira/Confluence link) — the /intake queue today; a dedicated S3 bucket is a drop-in replacement at the exact same enqueue call.
Owner: Business Analyst
Artifact: Governed source record, SHA-256 fingerprinted

Draft intent.mdBuilt

Trigger: Source captured and confirmed
Owner: Business Analyst
Checks: 18-point readiness assessment — business problem, scope, business rules, acceptance criteria, security & data considerations
Artifact: intent.md, SHA-256 pinned at human confirmation

Gate 1 — TriageBuilt

Trigger: Confirmed intent.md
Owner: Triage Lead
Checks: Human approve / reject / request clarification
Artifact: Gate 1 decision evidence

Context elaboration — context.mdNew · buildable now

Trigger: Gate 1 approval
Owner: Product Owner
Drafted by: Local rule-based drafting today — the exact seam Bedrock AgentCore fills in stage 4
Checks: Governed Gate score: design considerations, capability shape, impacted components, no open questions
Exit: Score reaches 100% and the Product Owner signs off
Artifact: context.md, hash-chained to intent.md

Design readinessNeeds your Bedrock config

Trigger: context.md at 100%
Owner: Architect
Drafted by: Bedrock AgentCore · Claude Sonnet 5, wrapped by your guardrail
Artifact: Design notes + component impact map, drafted for human review

AI artifact generationNeeds your Bedrock config

Trigger: Design readiness signed off
Owner: Developer
Produces: Code scaffold, unit test components, functional test components — all drafts on a review branch, never committed directly

6–13

Validation gatesFuture phase

Sequence: Code review → unit testing → functional testing → security & integration → performance → accessibility → release readiness → approver audit → E2E provenance
Owners: Team Lead Tester Security Approver Release Manager Audit Reviewer
Mechanism: Each is the same Governed Gate engine with a different check set — one new file and one new page per gate, not a new pattern

Branch, PR, mergeFuture phase

Trigger: E2E provenance at 100%
Owner: Team Lead
Mechanism: A draft PR opens via the GitHub CLI, carrying the full evidence chain in its description. Merge stays a human action — nothing here merges itself.

What “100%” means

One scoring engine runs at every gate. It doesn't exist anywhere in the portal today — every current readiness check only ever produces a pass/fail status. This is the piece every later stage inherits for free.

score = round( passed_weight ÷ applicable_weight × 100 )
if any BLOCKER check fails → cap at 94
if any CLARIFICATION check fails → cap at 99

Severity	Effect on score	Blocks the gate?
Blocker	Caps at 94%	Yes
Clarification	Caps at 99%	Yes
Information	Contributes weight only	No

A human veto always wins: one Block sign-off from the accountable role overrides a 100% automated score. The score earns the right to ask for sign-off — it never replaces it.

Live example — Case Type `context.md`

Design considerations recordedw6

Capability classified (new/modified)w6

Impacted components listedw6

Provenance links to confirmed intentw6

Open design questions resolvedw4

3 of 5 checks passing71%

One blocker present — the Product Owner's sign-off button stays disabled until impacted components are listed, however high the raw score climbs.

Where AWS and GitHub sit

The portal stays the system of record. AWS and GitHub are invoked from the server, never the browser, and every hop out carries a fingerprint back to the confirmed intent it started from.

The portal is the only system holding state. Bedrock AgentCore is called only once a gate's score reaches 100%, its guardrail intercepts the call before your model ever sees it, and every artifact it returns is chained by hash back to the human-confirmed intent.md it descended from. GitHub only ever receives a finished, evidence-complete draft PR — never a direct push.

What I need from you to wire it live

Everything below follows the pattern already used for the Jira and Confluence connectors in this repo: empty or missing values mean the feature reports itself unavailable, nothing fails silently.

AWS_REGIONRegion your Bedrock agent and guardrail are deployed in.

BEDROCK_MODEL_IDThe exact Claude Sonnet 5 model ID or cross-region inference profile ARN from your Bedrock console.

BEDROCK_GUARDRAIL_IDGuardrail identifier and version you've already configured — plus a short list of what it denies/redacts, so the portal can show a real message instead of a generic error when it intervenes.

AWS credentialsAccess key/secret for local development (matching the existing .env.server pattern), or an execution role ARN if the server runs inside AWS.

S3_PROPOSAL_BUCKETBucket + prefix for the waiting queue — only needed once we move the intake trigger off HTTP (Phase 2+).

GITHUB_REPOSITORYRepository the governed PR should open against, plus a token or GitHub App with pull-request-create scope.

Delivery order

Four phases. Each ships something usable on its own rather than waiting on the whole pipeline.

01no aws needed

Governed Gate foundation

The scoring engine, the Context Elaboration stage, and Product Owner sign-off — stage 3 above, fully working end to end in this repo today.

02your bedrock config

Live AgentCore drafting

Swap the rule-based drafting provider for a real Bedrock AgentCore call through your guardrail — Context Elaboration and Design Readiness both start producing real generated drafts.

03your bedrock config

Artifact generation + validation gates

Code/test scaffold generation, plus a page and check set per remaining gate (code review through E2E provenance) — each one reuses the Phase 01 engine.

04your github access

Governed delivery

Draft PR creation once E2E provenance hits 100%, carrying the full evidence chain in its description. Merge stays a human decision.