Skip to content

v1.0 — Governed Supply-Chain Decision Loop

Latest
Latest

Choose a tag to compare

View all tags
@falltwo falltwo released this 20 Jul 22:09
v1.0
f6142cb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

v1.0 — Governed Supply-Chain Decision Loop

v1.0 turns the governance harness established in v0.1 into an end-to-end supply-chain decision product.

The system can now move from external risk intelligence to an affected procurement line, create an AI-assisted alternative-sourcing Proposal, request a distinct human decision, and commit exactly one traceable ERP effect after approval.

Highlights

Three product tiers with real separation of duties

  • L1 Risk Observer — risk KPIs, heatmap, alerts, read-only CSV mapping, and notification preview. L1 cannot create proposals or modify ERP data.
  • L2 Intelligence & Decision — impact analysis, What-if simulation, alternative-supplier comparison, and durable Proposal submission. L2 cannot approve or execute ERP writes.
  • L3 Approval & Execution — immutable proposal evidence, approve/reject controls, governed Gateway execution, and an end-to-end audit timeline. The proposer cannot self-approve.

Durable Proposal-to-ERP workflow

  • Separate PurchaseProposal, ApprovalDecision, and PurchaseOrderExecutionRequest domain objects.
  • Exact binding to the affected PO line and selected supplier-price row.
  • Canonical payload digest and stable operation identity.
  • Live requester-capability and organization-scope revalidation at execution time.
  • One full replacement effect per source procurement line.

Atomic and idempotent execution

  • Protected purchase approval uses one SQLite transaction for CAS state transition, ERP write, effect claim, execution receipt, audit record, and terminal approval state.
  • Replaying the same approved operation returns the existing receipt without creating a second purchase order.
  • Cross-organization access, self-approval, stale permissions, and tampered evidence fail closed.

L1 workflow completion

  • Added recent-event alerts and read-only procurement CSV mapping.
  • Mapping and notification preview remain in memory and never create ERP or proposal records.
  • Demo seed data now guarantees that referenced purchase items exist in the product master.

Documentation and developer experience

  • New Traditional Chinese and English README files.
  • Clear v0.1-to-v1.0 comparison and honest PoC boundaries.
  • Improved local Demo Mode instructions and tier-account walkthrough.
  • Failed approval decisions remain visible instead of being erased by an immediate UI rerun.

From v0.1 to v1.0

Area v0.1 v1.0
Product focus Governance harness and bypass closure Governed supply-chain decision loop
Workflow Governed tools and generic approval Observe → Recommend → Propose → Approve → Execute
Supply-chain handoff Analysis and recommendations were separate from execution Affected PO lines become durable alternative-purchase Proposals
Approval evidence Generic action payload and status Source PO, supplier change, quantity, price, reason, digest, and timeline
Execution integrity Gateway, hash-chain audit, transaction baseline Exact source identity, live revalidation, effect uniqueness, idempotent receipt
Test suite 55 passing tests reported by the v0.1 release 327 passing tests in v1.0 release verification
Documentation Chinese README and diagrams Bilingual README, release comparison, and explicit limitations

The comparison is based on the v0.1 release record retained by the maintainer. That milestone remains the historical governance baseline for this release.

Verification

  • 327 automated tests passed locally before release.
  • Python compile verification completed successfully.
  • End-to-end browser walkthrough completed with the L1, L2, and L3 demo accounts.
  • L2 submission produced one Proposal and one pending approval with zero ERP effects.
  • L3 approval produced one purchase order, one proposal-effect claim, and one execution receipt.
  • Replaying the same approval kept all three effect counts at exactly one.

Upgrade notes

  • Proposal and effect-claim tables are added without deleting existing business data. However, an older non-demo database with users but no organization boundary now fails fast instead of silently locking out every principal.
  • Demo deployments automatically use organization demo-org.
  • For an existing non-demo database, set ERP_ORGANIZATION_ID, then provision user_organizations and organization_entitlements before startup.
  • Use a clean database when moving from local Demo Mode to a non-demo deployment; known demo credentials must never be exposed publicly.

Known limitations

  • v1.0 is a competition and research PoC, not a production authorization service.
  • One SQLite database maps to one organization; shared-database multi-tenancy is not implemented.
  • Audit records are tamper-evident at the application level, not tamper-proof against a host/database administrator.
  • SQLite transaction guarantees do not automatically extend to external ERP APIs; future integrations require an outbox, worker, and reconciliation design.

Documentation

Assets 2
Loading